discussion about startmoving, stopmoving bug

[smoth]

In spring, when a unit aims, the startmoving and stopmoving unit function are immediately called. This allows units to trigger a move animation should they need to turn around. Now, this behavior is NEVER seen in BA due to the 360 fire arc all ba units have. This thread is ONLY applicable to projects using fire arc limitations.

For my project and any other with move animations and limited arcs. The unit will turn it's body to aim. However, stop moving is not called when this bodily rotation completes, it is instead called instantly. This creates 2 possible issues. One issue is that the move animation can instantly stop as stopmoving() is used to set the move flag used in animation scripts. OR the unit will try and do it's move animation at each new target acquisition, regardless of it needing to turn it's body.

I feel this is a bug in the engine, I am not entirely sure what part of the aim code is triggering the start/stop moving. My cursory search in the source code has yielded little in the way of information. Can someone point me to the code so that I can better investigate this behavior

[Silentwings]

For the record, not all BA units have a 360 firing arc. But I can't help with your search in the code, sorry.

[Kloot]

GroundMoveType::KeepPointingTo + GroundMoveType::SetMainHeading

[smoth]

thanks kloot!

[smoth]

yeah I am seeing possibly the code responsible but

Code: Select all

owner->heading != heading

is unit movement heading right?

Code: Select all

weapons.front()

I have not looked into this

Code: Select all

TryTarget(mainHeadingPos, true, 0) 

or this

I still have read up on these two but feel they are important.

[jK]

1) yes it's unit heading
2) weapons.front() is the first weapon (can be NOWEAPON)
3) TryTarget() checks if shooting a position/unit is technically possible w/o energy,stockpile,movement,... checks

[knorke]

for this unit http://pastebin.com/WNJMDBDt script.StartMoving gets called when it aims at new target (shooting at ground)
the unit can shot has unlimited fire thing.
with

Code: Select all

function script.StartMoving()
	Spring.Echo ("StartMoving jeep " .. Spring.GetGameFrame ())

function script.StopMoving()
	Spring.Echo ("StopMoving jeep" .. Spring.GetGameFrame ())

I noticed startmoving and stopmoving get called the same frame.
guess same scripts could be fixed if script wait one frame before starting/stopping animation.

[smoth]

I noticed startmoving and stopmoving get called the same frame.
guess same scripts could be fixed if script wait one frame before starting/stopping animation.

Same. So I did this at the top of my move script

Code: Select all

		-- cover odd micro move calls of spring
		-- I should not have to do this but meh
		if(isMoving ~= true) then
			return
		end

but then I found something odd, The unit would no longer do any animation. Which lead me to believe it doesn't wait for the unit to resolve the heading change before calling stop. No matter how long it takes to turn the unit. Stop moving is ALWAYS called instantly. Which is where it became something I cannot (cleanly)work around. I also used spring echos to verify this.

so essentially you have a choice. Either have the unit slide around while turning or have it animate every time it aquires a new target at a different heading(even if the new heading is within the fire arc).

To me this seems undesireable and probably wasn't caught at the time because BA(which was the primary vehicle for testing) didn't have limited arc units. That was only gundam and s44 at the time. S44 opts for the slide in place script option, like MW:S.(whether or not they realized it was bugged at the time I have no idea)

[Nemo]

The reason S44 infantry animations are so often bugged is due to this, I think. The thing I struggled with most was dealing with start/stop moving being called at times that often didn't correlate to the unit movement state. Minor disclaimer: I was a terrible, terrible coder when I wrote them, so it's more likely just bad code.

[smoth]

yeah I noticed those and handled them fine. The last remaining one is the aiming triggered issue. If you ever feel interested I'd love to chat with you about what I have learned.

[smoth]

Ok, I believe my tests have proven conclusive. This is backed by what I found in the source.

each time a unit changes heading, even if they are moving, even if they are NOT moving, start and stop moving is triggered instantly. This can create some seriously bad script behaviors. I am not sure what to do about it just yet but I am making notes.

Give a unit a patrol path. At each turn the unit changes heading. start and stop moving are INSTANTLY triggered. Did the unit stop moving? no. A velocity check should probably be added.

of course that creates a new problem, so when stationary a unit turns, this reasonably could trigger start and stop moving but stop moving is not triggered when the unit stops turning. Instead stop moving triggers instantly after start moving is triggered


So ideally if the unit is still moving, don't trigger stop moving. Only trigger this if the unit's velocity is ZERO and it is not turning.

Is it hard to trigger stop moving when a unit actually stops moving? dunno. Is it hard to determine if a turn has completed? dunno.


nemo? Knorke? thoughts?

[yuritch]

I used velocity checks script-side to emulate start/stop moving (all amphib and boat units in S44 do that for emitting wakes), because I found engine callins unreliable.

Does the engine also call start/stop moving on script-caused heading changes (like set HEADING)?

[smoth]

I used velocity checks script-side to emulate start/stop moving (all amphib and boat units in S44 do that for emitting wakes), because I found engine callins unreliable.

yeah, that is less than optimal.

Does the engine also call start/stop moving on script-caused heading changes (like set HEADING)?

Probably. From what I can tell in the code any heading change should trigger it.

[FLOZi]

https://github.com/spring/spring/commit ... e595154652

[smoth]

wonderful news! I look forward to trying this!

[FLOZi]

https://github.com/spring/spring/commit ... ced882c911

[smoth]

that vibrating shit was a pretty funny bug. I still have about 21 days before I can test any of this stuff though

[smoth]

were these 2 in 94.1 or no?

[jK]

no

[smoth]

if I get latest dev I should be able to test them though right?