2025-07-22 07:51 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0004154Spring engineUnit Scriptingpublic2013-11-17 18:40
ReporterRafal99 
Assigned ToKloot 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version95.0.1+git 
Target VersionFixed in Version 
Summary0004154: Calling LUS AttachUnit(piece, unitID) causes following calls to Move(piece,...) to have no effect
DescriptionThis works:
 Move(piece, z_axis, pos, speed)
 AttachUnit(piece, unitID)
 WaitForMove(piece, z_axis)

But this doesn't:
 AttachUnit(piece, unitID)
 Move(piece, z_axis, pos, speed)
 WaitForMove(piece, z_axis)
 -- WaitForMove returns immediately, the piece doesn't move


IMPORTANT:
For some strange reason the bug only triggers when loading (attaching) MOVING unit and only when that unit uses LUS script.
Steps To ReproduceIts effects can be seen in ZK:test-12084 in the attached replay or when following these steps:
- start game on Ravaged_v2 map
- on start pick Support Comm (alternatively do "/give commsupport1")
- do "/give armtboat" in water
- now move the comm and the transport near the cliff so the comm is in transport range
- now give some short move order to the comm and while it moves load in into the transport
- the comm freezes in place, moving or rotating the transport moves and rotates the comm with it, which means the comm is attached but the attached piece didn't move to specified position despite Move() calls in the script.


In next commit (ZK:test-12085) Move() call gets moved before AttachUnit() and suddenly the bug no longer happens.


Wanted to test in BA too but was unable to do so, because BA doesn't any have LUS-using units.
Additional InformationI may make a test minimod if really necessary.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0012152

silentwings (reporter)

"BA doesn't any have LUS-using units."

Assuming lus are lua unit scripts, yes it does - precisely one, the coramph :p

~0012155

Rafal99 (reporter)

coramph also has bos/cob script so I wasn't sure which one is used.

~0012157

Kloot (developer)

"For some strange reason the bug only triggers when loading (attaching) MOVING unit..."

So the AttachUnit(...); Move(...) call order does work on a stationary unit?

~0012159

Rafal99 (reporter)

Last edited: 2013-11-17 11:47

View 3 revisions

Yes it works.
It works when loading non-moving unit or even when loading moving unit that uses COB.

Only breaks when the loaded unit is BOTH moving and has LUS script.

I tested on about 10 types of units, half of them LUS, and half COB. It breaks for all LUS ones and doesn't break for any of the COB ones.


It seems that AttachUnit indirectly calls CTransportUnit::AttachUnit which calls StopMoving
https://github.com/spring/spring/blob/develop/rts/Sim/Units/UnitTypes/TransportUnit.cpp#L342
So if I had to guess, I would say StopMoving() callin from loaded unit LUS, steals the LUS thread of the loading unit, or messes with its threads in some other way.

~0012160

Rafal99 (reporter)

Last edited: 2013-11-17 11:37

View 2 revisions

Note that only some callouts break when called after AttachUnit, so it is not like if the following code wasn't executed at all.

Spring.Echo() always gets called no matter where I place it (even at the end), while callouts like Move() or even second AttachUnit() seem to have no effect.

+Notes

-Issue History
Date Modified Username Field Change
2013-11-17 02:38 Rafal99 New Issue
2013-11-17 02:38 Rafal99 File Added: 20131116_221131_Ravaged_v2_95.0.1-69-g085ed98 develop.sdf
2013-11-17 02:52 silentwings Note Added: 0012152
2013-11-17 03:14 Rafal99 Note Added: 0012155
2013-11-17 03:23 Kloot Note Added: 0012157
2013-11-17 11:25 Rafal99 Note Added: 0012159
2013-11-17 11:35 Rafal99 Note Added: 0012160
2013-11-17 11:37 Rafal99 Note Edited: 0012160 View Revisions
2013-11-17 11:45 Rafal99 Note Edited: 0012159 View Revisions
2013-11-17 11:47 Rafal99 Note Edited: 0012159 View Revisions
2013-11-17 18:40 Kloot Changeset attached => spring develop 71d5386c
2013-11-17 18:40 Kloot Assigned To => Kloot
2013-11-17 18:40 Kloot Status new => resolved
2013-11-17 18:40 Kloot Resolution open => fixed
+Issue History