SetUnitX/Y + TriggerRegisterEnterRegion = evil

I will explain short the reason.
for example we have several regions on the map with this event and it does do something on enter (or leave) so...

we need to insta move some unit to some point.
so we usually call

and here is allready the epic fail ! cause after we called call SetUnitX(u,x) unit will be moved.
and keep it's current Y position. so in some cases this unit may be "in wrong place" and trigger. (or what ever)
and well yeah after this we call to SetUnitY and unit is arriving to it's destination.

i post this here cause i spend today a half day fixing a very weird issue with a custom blink spell in my AOS (it does use custom 3D pathing which is based on regions) so i was very shocked sometimes than i was not blinked at all or moved not to the right place.

and now the most important. the fix is using the lame -_- SetUnitPostion() function cause it moves the unit "at once" and it can't be at wrong place for some time frame. (also it account pathing etc.)

well it's not very important (for most maps) but i think you should know this.

...And SetUnitPosition is lame because...? And if it would be offset by improper pathing (which for a blink spell would be avoided anyways through checks), you could just call SetUnitX/Y afterwards, since it'd only be moving a fractional amount and shouldn't end up in a random spot.

Hmnn SetUnitX/Y is useful for movement because it is fast and pathing-less. Another use is for dummy units that pretend to be missiles.

Catch: As it is for movement, the new position is very close to the last one, so stuff should work ok. Dummy units are also not supposed to be even considered by events, so it works for them as well.

For long distances, It seems you are right and SetUnitPosition all the way, any speed increase or defense against pathing seems irrelevant in comparison to that bug.

You could like... disable the trigger before doing SetUnitX/Y , not like it improves stuff that much.

the interesting... if i called

call SetUnitPosition
call SetUnitX
call SetUnitY

it screwed the movement =\ anyway so idk (maybe SetUnitPosition is applied on current thread queue end ?) need to check this...

yes exactly.
well
1) i need to keep the check (otherwise i don't the pathing system :P)
2) i have 700+ triggers xD
2a) constant native GetTriggeringRegion takes nothing returns region hmmm. i think precreate region will be the same. a fuck dilemma >.< .... i think i will keep it for the first how it's now.

. it's slow. and it takes in account pathing.

btw ... tga texture can be used as war3map.wpm really handly to draw own pathing map in Photoshop xD

Congratulations, you don't plan code correctly.


Well, but yeah disable won't work...

Are your bunch of regions a grid?, I think you could do better than using regions, still perhaps we could pray for an atomic SetUnitX/Y alternative to come... Until then I guess you'll have to use SetUnitPosition.

Well, I have experienced that SetUnitX and SetUnitY does NOT stop orders in any way, it simply moves the unit in the field. The SetUnitPosition also seems to have special handling to wc3, meaning its calling an OrderStopCheck aswell as pathing check. To not hang out on this bug, I suggest only move the units a little each time. The bigger the distance is, the more you will get unseen problems.


What are you doing exactly?

Thats quite alot, are you GUIing? :P
Anyway, I am having less, but more complicated ones. I prefer a good mix of difficulty and amount.
Everytime you move a unit with SetUnit(X/Y) you should run an additionally check which checks if a unit is in region or not to prevent enter region bugs.

I would never suggest using SetUnitPosition...
Didn't knew that, any link?

I can see this being a bitch of a bug. How about leaving a little sliver of map edge region free, then

pipedream's fix sounds good. you could even move the unit outside of the normal map boundaries rather than leaving an edge free.

another method would be to incrementally move the unit by smaller x/y values toward the desired position.

no it's simple...
i have doodads placed on map.
after i create own slk with data for these doodads. dimensions in X/Y/Z
after i place into folder the war3map.doo and run my tool. after i get an
calls like this (it also scale the sizes depending on the doodad size)
it creates an rect with Z width. when on enter\leave events i do needed actions.

lol xD.

? it's simple.

your map dimensions (for example 128x128*4=512x512)
so you need an 512x512 32bit Tga (with a black alpha channel !) after simply messing with needed colors (! very important don't to use not allowed colors so use pencile instead of a brush) well then save it. and import as war3map.wpm (the import manager will overwrite the generated map with yours) well thats all works fine. and i use only black and white colors and... full size of the file is 1.6mb after mpq compression ~30kb =) or even less.

i will check and confirm if it's save as SetUnitPosition (in my relative hard case.)

I think this is going to work, unless you depend of region leave events as well as enter events.

If your problem is the fact that you can only move the X or Y one at a time, why not just move the x a short distance, then the y a short distance, and repeat until you achieve the wanted distance?

Or would the problem still occur under these circumstances?

it wouldnt matter that much, but since this would decrease performance drastically it would be better to just use SetUnitPosition (maybe followed by a SetUnitX/SetUnitY) or Pipedreams Solution.

you'd have to do it like 20 times to get as slow as SetUnitPosition

Hence why I bothered suggesting what i did.

yes works fine. but you need to be sure what the map edges also don't have some regions...
but the SetUnitPosition() is the bullet proved method. but in 99.9% of cases PipeDream's method will be the best solution.