Problem with Units Returning to Creation Point

[Zeatherann]

When I use the function below to create units with and then I don't do anything with the unit via triggers the unit will after some time be ordered to move to the location they were created at, versus the point they were moved to via triggers. Why is this and what can I do to fix this?

globals
    constant player PLAYER_NEUTRAL_EXTRA=Player(bj_PLAYER_NEUTRAL_EXTRA) // This is the extra player in the game (not passive mobs, hostile creeps, or the victums of left players).
endglobals

function CreateUnitEx takes integer UnitTypeId,real X,real Y,real FacingAngle returns nothing
    local unit Unit=CreateUnit(PLAYER_NEUTRAL_EXTRA,UnitTypeId,0,0,FacingAngle)
    call SetUnitX(Unit,X)
    call SetUnitY(Unit,Y)
endfunction

 

[sethmachine]

Hmm this is a good question!

If anything I would have to say it's some kind of in built behavior for units to return to their origin. This is behavior that creeps / neutral hostile has (after some distance or time the unit will return to its origin, even if it's being attacked or fighting). So I suspect that may be at play.

Did you try using a normal computer player instead, e.g. Player 7? That may fix it.

If that fixes it then I would be inclined to say neutral extra has the same camping behavior from neutral hostile.

 

[IcemanBo]

1. You can change some gameplay constants that define how far neutral hostile units are allowed to go away from their destiniy location.

2. Or yes, you can try it what seth said, with change to a normal player instead of neutral.

3. Last but not least you can try natives, but I never tried them:

native RemoveGuardPosition takes unit hUnit returns nothing
native RemoveAllGuardPositions takes player num returns nothing

Using natives might be best if they work, but as I said idk. Maybe they don't work for neutral hostile.

 

[SanKakU]

1. You can change some gameplay constants that define how far neutral hostile units are allowed to go away from their destiniy location.

You can also change the range for the unit individually when you spawn it.

edit:
here is a sample

set u=CreateUnit(Player(PLAYER_NEUTRAL_AGGRESSIVE),'n059',-2425.00,-1525.00,0.0)
  call SetUnitAcquireRange(u, 200.0 )

the first line is just normal spawning of a unit.
SUAR function will require a unit variable. i replaced my variable name with u in order to make it more obvious to you. hope this helps.

anyway, 200 is gold mine protection range or close to it, you might try 22222.0 range or something else very large.

 

[chobibo]

@IcemanBo: #3 didn't work when I tested it years(maybe 2010?) ago.

 

[Zeatherann]

Tried those natives before starting thread, all natives that had to do with guard points. None worked, even tried the combinations of them.

 

[SanKakU]

I read your first post again, this time more carefully. Well you're moving the unit immediately after creating it. You're creating it at 0/0 with that function. Spawn them where you want them to spawn at and stop instantly relocating them. Input the coordinates inside of the CreateUnit function and stop using CreateUnitEx.

CreateUnit(Player(bj_PLAYER_NEUTRAL_EXTRA),UnitTypeId,x,y,f)

 

[Dr Super Good]

Units seem to have some form of memory where they were created (placed). Stuns and things can alter these positions at times.

 

[Vinz]

I read your first post again, this time more carefully. Well you're moving the unit immediately after creating it. You're creating it at 0/0 with that function. Spawn them where you want them to spawn at and stop instantly relocating them. Input the coordinates inside of the CreateUnit function and stop using CreateUnitEx.

CreateUnit(Player(bj_PLAYER_NEUTRAL_EXTRA),UnitTypeId,x,y,f)

wat. o.o

And he was talking about the fact that when units are moved, either immediately after creation, or a long time later, their guard position remains.

 

[Zeatherann]

I create then at0,0because it's a constant location (speed), versus a variable read, and because they don't spawn where I want them to (pathing limitations) and am required to useSetUnitX() and SetUnitY()regardless of the spawn coord. I will try creating them at the desired location though to see if it is within their range-of-not-moving-back.

 

[Ceday]

Easy solution is gameplay constants, if you can't use that,

To prevent units from going back to their spawning location, you need to catch their "move" order.When they received a move order, you move them with their current location with SetUnitPosition.Because as DSG said stuns and things can change their guard position.

 

[Zeatherann]

WillSetUnitPositition()function likeSetUnitX() and SetUnitY()for pathing placement? I want these units on top of other units most of the time.

 

[Ceday]

SetUnitPosition is just for fixing the returning problem.

 

[SanKakU]

I create then at0,0because it's a constant location (speed), versus a variable read, and because they don't spawn where I want them to (pathing limitations) and am required to useSetUnitX() and SetUnitY()regardless of the spawn coord. I will try creating them at the desired location though to see if it is within their range-of-not-moving-back.

You don't need a variable read. Just mouse over the area of the map you want coordinates for and read the coordinates given at the bottom left of the editor. 0,0 are coordinates just like any other part of the map.

 

[Dr Super Good]

Although SetUnitX/Y will bypass pathing tests, as soon as the unit moves they will be applied instead, so you are only deferring the problem.

SetUnitX/Y are also not compatible with buildings. They will move the model assets and I think the target point but the building pathing will still remain where it was last created. This is different from the other kind of move which will move the pathing as well (why it is more expensive).

 

[Zeatherann]

The unit is not supposed to move after creation. It isn't used on buildings either.

 

[Dr Super Good]

If you want the unit to ignore collision then turn collision off for it.

You could also use the other move to force it to the place (so it guards it) and then use setx/y to fine position it (ignoring collision).

 

[Zeatherann]

I guess I'll use the positioning one and suffer any offsets.