2019-08-24 00:34 CEST

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0005372Spring engineGeneralpublic2017-07-07 12:21
Reporterraaar 
Assigned ToKloot 
PrioritynormalSeverityminorReproducibilitysometimes
StatusresolvedResolutionfixed 
Product Version103.0 
Target VersionFixed in Version103.0 +git 
Summary0005372: sometimes robots move without displaying walk cycle
Descriptionsometimes robots and units which have movement animations (walk cycle) don't display it after being ordered to move, even though they're moving.

This seems to happen when they're under fire from enemies.

I suspect that the StartMoving() animation callin isn't being triggered because they're considered to be already "moving" due to the impact.

stopping the unit, then reissuing the move order fixes the issue.

I think this happens on most TA-like games, namely MF.
Steps To Reproduce- spawn a bunch of robots (MF example : sphere_hanz) for yourself
- spawn units with high damage and high AOE weapon (MF example : claw_mega, but also spawn something like 20 claw_solar_collector and claw_energy_storage so it can fire) for an enemy team

- move your units into enemy firing range, let them stop, then order them to move while they're still being "moved" by the explosion or impact force


Additional Informationadded a replay which shows the issue.

Used engine 103.0, map intersection_v3, game metal factions v0.961
(https://springfiles.com/spring/games/metal-factions-12)

It's a test game against AI, at 8:00 I managed to reproduce the issue : two of my Hanz robots didn't start their move animation when ordered to move after being hit by enemy fire.



TagsNo tags attached.
Checked infolog.txt for lua Errors
Attached Files

-Relationships
+Relationships

-Notes

~0016761

Google_Frog (reporter)

Relevant https://springrts.com/mantis/view.php?id=4458

~0016784

raaar (reporter)

yep, it's the same issue.

does anyone know where's the code that handles this?

on the wiki, https://springrts.com/wiki/Animation-LuaCallins, there's this:
""""""""
script.StartMoving ( ) -> nil
script.StopMoving ( ) -> nil

These are called whenever the unit starts or stops moving. Typical use for them is to trigger wheels to start spinning, animate treads, or start/stop a walking animation. Since 95.0 they are only run when a unit transitions from zero to non-zero speed or vice versa, and no longer during in-place rotations.

""""""""


there could be an internal flag to indicate that the unit is trying to move using its internal power...let's call it tryMoving. Maybe it already exists.

In that case, the trigger for startMoving could be changed

FROM

"speed changed from 0 to > 0" AND "tryMoving changed from false to true"

TO

"speed changed from 0 to > 0" OR "tryMoving changed from false to true"

~0016785

raaar (reporter)

can't edit my note.

the last line should be
"speed changed from 0 to > 0" OR (speed > 0 AND "tryMoving changed from false to true")

~0016786

raaar (reporter)

the above would also trigger startmoving when the unit's being thrown around, which isn't intended.

maybe i'd just leave the startMoving trigger condition as
"speed > 0" AND "tryMoving changed from false to true"


sleepiness etc.

~0016862

raaar (reporter)

the right way to fix this would be to fix the engine.

other than that....is there any simple way to do it through a gadget?

I'm not in the mood to tweak hundreds of scripts.

~0016923

raaar (reporter)

this still happens on ZK. Saw it happen on the strike commander a few days ago.

~0016925

Google_Frog (reporter)

Did you read the previous ticket? According to the engine devs the current behaviour is correct.

Since you bring it up, you could try this: https://github.com/ZeroK-RTS/Zero-K/commit/32ab12a7039f21c39a8e9671abae49f2b8a53cc4

UnitPreDamaged doesn't seem to detect everything though, perhaps low velocity collisions don't count. I'm still going to stick with my speed check loop for Slasher and Crabe.

~0016930

raaar (reporter)

I read the previous ticket and disagree with Kloot.

From the wiki description and the way it has been used in practice for many years, StartMoving should be called in the situations described, even if not immediately when the unit is thrown into the air then after the unit "reconnects" with the ground if it keeps moving due to orders. There's some cases where it isn't and that's a bug.

if unit is moving along the ground (or wherever) by its own effort and StartMoving hasn't been called since the last time StopMoving was called, then engine bug.

Thanks for your gadget link, I'll try to do something like that.

~0016975

FLOZi (reporter)

Haven't seen this behaviour in MCL which suggests to me that it is possibly partially unit script at fault (i.e. poor use / lack of signals)

~0017045

raaar (reporter)

The goal was fixing the issue without having to modify hundreds of scripts.

The ZK workaround doesn't seem to work reliably. I've seen ZK commanders slide without animating legs on the latest versions.

The workaround i used was this:

https://github.com/springraaar/metal_factions/blob/master/LuaRules/Gadgets/unit_physics_handler.lua#L102

it works because on my scripts the startmoving/stopmoving callins only change a flag, which is checked periodically to control animation

~0017046

Google_Frog (reporter)

I only applied the ZK workaround for units which can break game mechanics by sliding. These are units which gain armour when stationary or which are unable to fire while moving.

~0017949

Kloot (developer)

the (LUS-only, quit using COB...) {Start,Stop}Skidding script callins added for 104.0 make this a non-issue.
+Notes

-Issue History
Date Modified Username Field Change
2016-10-10 05:05 raaar New Issue
2016-10-10 05:05 raaar File Added: 20161010_011307_Intersection_v3_103.sdfz
2016-10-10 05:09 Google_Frog Note Added: 0016761
2016-10-11 06:46 raaar Note Added: 0016784
2016-10-11 06:48 raaar Note Added: 0016785
2016-10-11 07:06 raaar Note Added: 0016786
2016-11-12 18:30 raaar Note Added: 0016862
2016-12-02 18:20 raaar Note Added: 0016923
2016-12-03 03:38 Google_Frog Note Added: 0016925
2016-12-05 06:03 raaar Note Added: 0016930
2016-12-16 23:34 FLOZi Note Added: 0016975
2017-01-14 21:01 raaar Note Added: 0017045
2017-01-15 02:00 Google_Frog Note Added: 0017046
2017-07-07 12:21 Kloot Assigned To => Kloot
2017-07-07 12:21 Kloot Status new => resolved
2017-07-07 12:21 Kloot Resolution open => fixed
2017-07-07 12:21 Kloot Fixed in Version => 103.0 +git
2017-07-07 12:21 Kloot Note Added: 0017949
+Issue History