2025-07-03 18:22 CEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002886Spring engineGeneralpublic2011-12-29 16:542012-01-28 20:15
ReporterNemo 
Assigned ToKloot 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version85.0 
Target Version86.0Fixed in Version 
Summary0002886: MoveCtrl'd units displaying wildly different behavior in 85
DescriptionParatroopers and partisan supply drops in S44 aren't drifting to the ground (as they did in 83/84), but floating wildly into the cosmos.

To reproduce, use this game: http://spring1944.net/files/Build/S44v158_PreMorgenrote.sdz /cheat /give usradar /give us_sortie_paratrooper then order the sortie anywhere on the map and observe the behavior of the paratroopers in the air.

They seem to maintain the vector of the unit that drops them, rather than being affected by gravity on their own, resulting in paratroopers going flying wildly into the air. This breaks S44 in a rather nasty way :(

Additional InformationPrevious behavior looks like this: http://www.youtube.com/watch?v=3Zia8lv_aPg&feature=player_detailpage#t=88s

or this: http://www.youtube.com/watch?v=kqqGBGzLYMQ

Possibly related to this commit: https://github.com/spring/spring/commit/c03bc5096594fd478baa310b0a61a3b0d3c95ac9
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0008036

Google_Frog (reporter)

2011-12-30 00:41

 I found an change with jumpjet that was fixed by Spring.SetUnitVelocity(unitID,0,0,0) just after enabling movectrl for the unit. Try that. I don't think this particular thing is a bug because it is more general and the old behaviour is simple to preserve.

~0008037

FLOZi (reporter)

2011-12-30 01:27

Last edited: 2011-12-30 01:45

 It's a bug if you have to hack around it, and you frankly have no idea if its the same issue or not (and I doubt it, BTL uses jumpjet gadget and is just fine in 85).

Actually, I suspect the paratroops may be being hit by the plane, or each other ---> it could be the excessive bumping bug again.

~0008038

Google_Frog (reporter)

2011-12-30 02:24

 I think the old behaviour could be considered broken and my fix is not a hack. BTL will have the change too but you may not have noticed it yet.

The change was that velocity when movectrl was started is preserved and set when movectrl ends. Interrupting a thrown unit with jumping no longer works.

~0008039

Nemo (reporter)

2011-12-30 10:32

Last edited: 2011-12-30 10:39

 I added SetUnitVelocity(unitID, 0, 0, 0) right after movectrl clicks on, with little/no discernible effect. This should not have had any effect (to my mind), as we MoveCtrlSetVelocity of the unit immediately after moveCtrl turns on for that unit. Unless for some reason SetUnitVelocity and MoveCtrlSetVelocity are not both absolute, I believe they should have similar effects in terms of unintended unit movement.

Even if this isn't a bug, it is at least a major change in movectrl functionality for which some guidelines for updating should exist. It just doesn't seem to be an intended change by the engine folks (judging from recent commit log to LuaSyncedMoveCtrl.cpp - mostly small fixes and refactoring), hence reporting it as a bug.

~0008203

Nemo (reporter)

2012-01-22 15:18

 [17:58:03] <[S44]FLOZi> make a note that it was tested and fails in 85.0.1-67-g56f9479
[17:58:14] <[S44]FLOZi> and the problem is associated with Spring.MoveCtrl.SetRelativeVelocity


Reopening at flozi's request

~0008204

FLOZi (reporter)

2012-01-22 17:27

Last edited: 2012-01-22 20:49

 digging deeper down the rabbit hole, maybe caused by re-factoring of ScriptMoveType

Status needs to go back to assigned/open please.

edit2: According to KingRaptor both S44 paratroopers and Air Raid work correctly in 84.0. Ergo it's almost certainly one of these two commits:

https://github.com/spring/spring/commit/747e7e9e918a856ef0bc626da0bf9f5aaa5716d2#diff-3 or
https://github.com/spring/spring/commit/6125392ffb1c90b596a61eeca3c7a91f513b48d5#diff-7

~0008205

Kloot (developer)

2012-01-22 18:21

Last edited: 2012-01-22 19:16

 No, it does not.

ScriptMoveType behavior changed because of a _bug_ in SetRelativeVelocity which was fixed by my refactor, and now that it works as intended gadgets relying on the old broken logic _themselves_ need fixing. This is as simple as removing the SetRelativeVelocity calls, so I don't see any rabbit holes...

e: seems I actually turned relative velocity into relative acceleration, so that I will change back.

~0008206

FLOZi (reporter)

2012-01-22 21:12

Last edited: 2012-01-23 00:14

 What was the bug with relative velocity which was fixed?

If you could post a link to an engine build after fixing acceleration vs. velocity that would be useful, sounds like it may be the problem.

~0008207

Kloot (developer)

2012-01-23 00:10

 done, you want http://springrts.com/dl/buildbot/default/develop/85.0.1-68-gaa5d050/spring_85.0.1-68-gaa5d050.exe

~0008208

FLOZi (reporter)

2012-01-23 00:14

 Mmm, still not the same in aa5d0501b1...

I don't see simply removing the SetRelative calls from the gadget code as a viable solution, so can you describe how it has changed to address the original bug?

~0008209

Kloot (developer)

2012-01-23 04:18

 It's possible I misinterpreted the code, I looked at pre-refactor versions and those also (wrongly) treat relative velocity as acceleration. So that doesn't quite explain the "floating wildly into the cosmos" behavior prior to aa5d0501.

If you set the wind-factor to 0.0 (or some value much closer to 0 than the paratrooper gadget currently passes), does aa5d0501 behave the same as pre-85?

~0008211

FLOZi (reporter)

2012-01-23 17:59

Last edited: 2012-01-23 19:34

 Setting wind to 0 does result in much better behaviour in aa5d05 (Probably the same as 84.0 would with wind removed). A factor of about 1/5th to 1/6th seems to bring it back in line with 84 (Hard to tell accurately).

Setting wind to 0 in 85.0 doesn't show much improvement at all.

~0008217

Kloot (developer)

2012-01-24 15:18

 Is the average wind-strength on the map you tested in the range 5-6 maybe?

~0008218

FLOZi (reporter)

2012-01-24 16:53

 MinWind=5;
        MaxWind=15;

I'm now recalling jK making a change to wind, was that between 84 and 85? I thought it was prior.

~0008219

Kloot (developer)

2012-01-24 19:41

 http://springrts.com/dl/buildbot/default/develop/85.0.1-75-g6d8f065/spring_85.0.1-75-g6d8f065.exe should fix it fully.

~0008220

FLOZi (reporter)

2012-01-24 22:20

 Tested with 85.0.1-77-g26e98fa, appears to be restored to its former glory, thanks!

(_now_ the status can be changed to resolved ;)

~0008228

tvo (reporter)

2012-01-28 20:15

 <[S44]FLOZi> anyone wanna close http://springrts.com/mantis/view.php?id=2886 fixed for both s44 paras and Air Raid
+Notes

-Issue History
Date Modified Username Field Change
2011-12-29 16:54 Nemo New Issue
2011-12-30 00:41 Google_Frog Note Added: 0008036
2011-12-30 01:27 FLOZi Note Added: 0008037
2011-12-30 01:38 FLOZi Note Edited: 0008037
2011-12-30 01:40 FLOZi Note Edited: 0008037
2011-12-30 01:45 FLOZi Note Edited: 0008037
2011-12-30 02:24 Google_Frog Note Added: 0008038
2011-12-30 10:32 Nemo Note Added: 0008039
2011-12-30 10:39 Nemo Note Edited: 0008039
2012-01-09 23:09 abma Target Version => 86.0
2012-01-21 15:06 jK Status new => assigned
2012-01-21 15:06 jK Assigned To => Kloot
2012-01-21 15:07 jK Status assigned => resolved
2012-01-21 15:07 jK Resolution open => fixed
2012-01-22 15:18 Nemo Note Added: 0008203
2012-01-22 15:18 Nemo Status resolved => feedback
2012-01-22 15:18 Nemo Resolution fixed => reopened
2012-01-22 17:27 FLOZi Note Added: 0008204
2012-01-22 17:34 FLOZi Note Edited: 0008204
2012-01-22 18:21 Kloot Note Added: 0008205
2012-01-22 19:16 Kloot Note Edited: 0008205
2012-01-22 20:49 FLOZi Note Edited: 0008204
2012-01-22 21:12 FLOZi Note Added: 0008206
2012-01-22 21:18 FLOZi Note Edited: 0008206
2012-01-23 00:10 Kloot Note Added: 0008207
2012-01-23 00:13 FLOZi Note Edited: 0008206
2012-01-23 00:14 FLOZi Note Added: 0008208
2012-01-23 00:14 FLOZi Note Edited: 0008206
2012-01-23 04:18 Kloot Note Added: 0008209
2012-01-23 17:59 FLOZi Note Added: 0008211
2012-01-23 18:57 FLOZi Note Edited: 0008211
2012-01-23 18:58 FLOZi Note Edited: 0008211
2012-01-23 19:34 FLOZi Note Edited: 0008211
2012-01-24 15:18 Kloot Note Added: 0008217
2012-01-24 16:53 FLOZi Note Added: 0008218
2012-01-24 19:41 Kloot Note Added: 0008219
2012-01-24 22:20 FLOZi Note Added: 0008220
2012-01-28 20:15 tvo Note Added: 0008228
2012-01-28 20:15 tvo Status feedback => resolved
2012-01-28 20:15 tvo Resolution reopened => fixed
+Issue History