| View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
| ID | Project | Category | View Status | Date Submitted | Last Update | ||||
|---|---|---|---|---|---|---|---|---|---|
| 0005372 | Spring engine | General | public | 2016-10-10 05:05 | 2017-07-07 12:21 | ||||
| Reporter | raaar | ||||||||
| Assigned To | Kloot | ||||||||
| Priority | normal | Severity | minor | Reproducibility | sometimes | ||||
| Status | resolved | Resolution | fixed | ||||||
| Product Version | 103.0 | ||||||||
| Target Version | Fixed in Version | 103.0 +git | |||||||
| Summary | 0005372: sometimes robots move without displaying walk cycle | ||||||||
| Description | sometimes 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 Information | added 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. | ||||||||
| Tags | No tags attached. | ||||||||
| Checked infolog.txt for Errors | |||||||||
| Attached Files |
| ||||||||
 Relationships |
|
 Relationships |
| Notes |
|
|
Google_Frog (reporter) 2016-10-10 05:09 |
Relevant https://springrts.com/mantis/view.php?id=4458 |
|
raaar (reporter) 2016-10-11 06:46 |
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" |
|
raaar (reporter) 2016-10-11 06:48 |
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") |
|
raaar (reporter) 2016-10-11 07:06 |
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. |
|
raaar (reporter) 2016-11-12 18:30 |
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. |
|
raaar (reporter) 2016-12-02 18:20 |
this still happens on ZK. Saw it happen on the strike commander a few days ago. |
|
Google_Frog (reporter) 2016-12-03 03:38 |
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. |
|
raaar (reporter) 2016-12-05 06:03 |
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. |
|
FLOZi (reporter) 2016-12-16 23:34 |
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) |
|
raaar (reporter) 2017-01-14 21:01 |
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 |
|
Google_Frog (reporter) 2017-01-15 02:00 |
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. |
|
Kloot (developer) 2017-07-07 12:21 |
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 |