Custom Map #966: Cryz Bohz. By: Flabort

[AutoPost]

This topic is for discussion of map #966: Cryz Bohz


Author: Flabort
Size: 132x48

Desc:
As you approach the system center, you are stopped by an inhibitor. Credit to ParkourPenguin for mouse-over script and troubleshooting. #FlipEmiters #SlipEmiters #Void #Spores #AE #Inhibitor

[Flabort]

Again, thanks to ParkourPenguin for helping get the two new elements working.
I don't think I'll be using the pocket of rift space very often, it's pretty laggy, especially at larger sizes. This is probably the upper limit. During my tests I was working with one approximately 6 times this size - it was unbearable.

[stewbasic]

I found the lag was pretty unpleasant (my computer is a bit old though). Is it deliberate that a unit on a PZ gets left behind 1 cell when the PZ moves? Also the light blue AC, blue creeper and blue terrain made it hard to see what was going on sometimes.

I just realised I'm one of those people who only speaks up when they have gripes >.<. Erm... I liked your other maps? :3

[Flabort]

I just realised I'm one of those people who only speaks up when they have gripes >.<. Erm... I liked your other maps? :3

Eheh. That's fine.
I guess as one of those people who uses a different AC color I don't really notice when the defaults clash. I'll be color shifting later maps to a more green/yellow pattern anyways.

As for the PZ unit being left behind:
I noticed while playing that the moving terrain has an odd effect on units of all sorts. For example, I accidentally landed a cannon on top of a mortar. And relay connections stretch out a Loooooong ways. So, not deliberate that the unit gets left behind when the PZ moves.

And I feel I have a reletively low end computer (not terrible, though), but I'm well aware there are people running worse specs than I. I have to turn on a extra fan when playing to prevent my computer from burning my wrists, though, so I'd say I'm down there enough. The lag was... barely acceptable with my specs. I'm pretty sure that having an older computer like yours will make this map pretty uncomfortable, so yeah, not building those into my maps at such a large scale in the future.

[planetfall]

Your script is extremely laggy because of the constant calls of GetUnitAt, not SetTerrain -- if it were more complex, with more leading and trailing edges, SetTerrain would be more problematic, but it's smart enough to not do any redrawing when setting the terrain to what it already is.

Try commenting out the lines of your script that move units, and make an invisible core somewhere with this script (with variables adjusted of course) -- it seems to be about 60-70% faster. This script should also fix PZ's and units getting out of sync, though the PZ effect will only stay on units built before the PZ was created due to a technicality in moving units and the way GetAllUnitsInRange works. If you sorted all the units into "PZ" and "not a PZ" and moved all the PZ's first, that would work, but this was just a quick-and-dirty solution.

Code Select Expand


# UnitWarp.crpl
# Created on: 8/15/2014 5:21:30 PM
# ------------------------------------------

$x1:0
$y1:0
$x2:0
$y2:0
$Delay:5
$Direction:-1

once
self CONST_COUNTSFORVICTORY FALSE SetUnitAttribute
self CONST_CREATEPZ FALSE SetUnitAttribute
self CONST_NULLIFIERDAMAGES FALSE SetUnitAttribute
self CONST_TAKEMAPSPACE FALSE SetUnitAttribute
<-x1 <-x2 add asfloat 2 div ->xc
<-y1 <-y2 add asfloat 2 div ->yc
<-xc <-yc <-x1 <-y1 Distance 1 add ->range
endonce

<-Delay Delay
<-xc <-yc <-range 0 GetAllUnitsInRange 0 do
->uid
<-uid CONST_ISLANDED GetUnitAttribute if
<-uid CONST_COORDX GetUnitAttribute ->ux
<-ux <-x1 gte if
<-ux <-x2 lte if
<-uid CONST_COORDY GetUnitAttribute ->uy
<-uy <-y1 gte if
<-uy <-y2 lte if
<-uy <-y2 eq if
<-uid CONST_COORDY <-y1 SetUnitAttribute
else
<-uid CONST_COORDY <-uy <-Direction sub SetUnitAttribute
endif
endif
endif
endif
endif
endif
loop