Bug with moving units in CRPL, map is not updated

Started by st00pid_n00b, June 25, 2017, 02:07:56 PM

Previous topic - Next topic

st00pid_n00b

I think I found a bug by using SetUnitAttribute and CONST_COORDX or CONST_COORDY to move units.

I do something like this with a unit present at (1, 1):

1 1 GetUnitAt CONST_COORDY 4 SetUnitAttribute


Under some circumstances, the previous unit position is still considered occupied (can't land/build units) and the new position is not (can stack units).

More specifically, after some testing, it's mostly a problem when moving other units:

  • When the core moves itself, the bug is fixed after unpausing.
  • When the core moves another unit, the bug remains after unpausing.
  • If the code is in the awake function, the bug affects the core only. It's fixed when unpausing.
  • If the code is in once...endonce, the bug affects other units but not the core.
  • If the awake function sets OperateWhilePaused to TRUE, and the code is in once...endonce, other units and the core are both affected.
  • If a unit is created by the core then moved, the bug is not present. It has to be there already.
  • Using CellToPixel on the destination coordinates and then setting CONST_PIXELCOORDX and CONST_PIXELCOORDY still gives the bug.
  • If the core moves itself with SetCurrentCoords or SetCurrentX or SetCurrentY the bug is still present.
  • If the unit can be moved by the player, the map is then correctly updated.
  • Saving and reloading fixes the map.

I've used this to move things around while making a map, so save and reload fixed the problem for me. It would be problematic if a core moves other units in realtime during gameplay though.

GoodMorning

Interesting. It is unlikely to be fixed at this point, but knowing is better than not.

Note that code running in a once block only executes on update, while code in :awake is called on load or on AddScriptToUnit.

Cores only tend to move themselves, but most moves are conducted over several frames.

Also note that CRPL movements can easily move onto pre-placed units, s the difference is not as startling as one might imagine.

I commend you on the number of cases tested. It might be worth attaching your testing code.
A narrative is a lightly-marked path to another reality.

st00pid_n00b

Quote from: GoodMorning on June 25, 2017, 07:35:26 PM
Also note that CRPL movements can easily move onto pre-placed units, s the difference is not as startling as one might imagine.

I don't understand this part. Do you mean CRPL can stack units? Yes, this bug doesn't prevent scripts from working, but it can cause trouble for player actions.

Quote
I commend you on the number of cases tested. It might be worth attaching your testing code.

Thank you. I noticed this problem with the MapMove.crpl script I just posted in the forum. Then I wanted to make a unit test but kept changing to test the different combinations. It was throwaway code, and I ended up posting the list above instead.

I just threw a little test together that illustrates some of the points, see attachment.

Unpause to execute. You'll see the place above the pulse cannon and the totem is unavailable to build/land. The core and mortar are not affected. If you move the cannon, it fixes it, but for the totem you need to save and reload.


once
# Test 1: bug
1 1 GetUnitAt CONST_COORDY 4 SetUnitAttribute

# Test 2: bug
4 4 CellToPixel ->y ->x
4 1 GetUnitAt CONST_PIXELCOORDY <-y SetUnitAttribute

# Test 3: move core - no bug
7 1 GetUnitAt CONST_COORDY 4 SetUnitAttribute

# Test 4: move created unit - no bug
"MORTAR" 10 1 CreateUnit ->id
10 1 GetUnitAt CONST_COORDY 4 SetUnitAttribute
endonce