Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistency between aircraft and mobile speed #16682

Open
matjaeck opened this issue Jun 10, 2019 · 8 comments

Comments

Projects
None yet
5 participants
@matjaeck
Copy link
Contributor

commented Jun 10, 2019

Noticed by @Orb370 on discord. Something is wrong with either mobile speed or aircraft speed because for some reason hinds (speed 112) are slower than mobile flaks (speed 0,8*128=102.4) which should not be the case. Tested on bleed and affects both planes and helicopters.

@matjaeck matjaeck changed the title Inconsistency between aircaft and mobile speed Inconsistency between aircraft and mobile speed Jun 10, 2019

@abcdefg30 abcdefg30 added the Bug label Jun 10, 2019

@reaperrr

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2019

I doubt that Mobile moves too fast, so my money is on Aircraft. Orca Bomber in TS also feels way too slow.

@netnazgul

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2019

https://cdn.discordapp.com/attachments/339126076204908544/587663951450603580/2019-06-10_11-25-25.mp4 by Orb with the video.

Mobile flak has "wheeled" locomotor and thus 80% modifier on its speed of 128.

@reaperrr reaperrr added this to the Next Release milestone Jun 14, 2019

@reaperrr

This comment has been minimized.

Copy link
Contributor

commented Jun 14, 2019

Since we're refactoring large parts of the aircraft code anyway, we should at least investigate before next release.

@reaperrr

This comment has been minimized.

Copy link
Contributor

commented Jun 14, 2019

I doubt that Mobile moves too fast

Yeah well, should have known better than to trust our ground movement code...

Some trial-and-error testing gave me the following results:

  • Aircraft with speed 1024 move exactly one cell per tick, as they should
  • A Flak Truck with base speed of 640 (effectively 512 on Clear terrain) moves half a cell on first tick and last tick, but a FULL cell on the ticks between... not 100% sure if my testcase is accurate, but assuming it is... oh boy, what a bug...
@reaperrr

This comment has been minimized.

Copy link
Contributor

commented Jun 14, 2019

OK, some more investigation has shown it's not that bad, but still bad.

What happens here is that if moveFraction exceeds MoveFractionTotal, OnComplete is triggered, which ignores the maximum movement speed and just sets the final position. As MoveFractionTotal is always 512 during straight vertical or horizontal movement, the faster a units' speed is, the higher the percentage of frames that exceed MoveFractionTotal and therefore trigger OnComplete.

The fix should be to ensure that OnComplete is only triggered when the remaining fraction is <= mobile.MovementSpeedForCell.

@pchote

This comment has been minimized.

Copy link
Member

commented Jun 20, 2019

I'm finding it difficult to interpret the comment above - this sounds like the correct behaviour to me. moveFraction > MoveFractionTotal means that the unit has finished (overshot) the requested movement for the activity, and so calling OnComplete is the correct thing to do.

Where I can see this going wrong is that the unit probably sees the activity completing and then ticks the next one in the same tick, causing a doubled move-step for each half-cell completed.

@reaperrr

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2019

Where I can see this going wrong is that the unit probably sees the activity completing and then ticks the next one in the same tick, causing a doubled move-step for each half-cell completed.

Yes, that's what actually happens.

Edit: Not sure how to best fix that, though. If we let the inner activity continue for one more tick, we might re-introduce a tick where the actor doesn't move at all, same if we disabled pre-ticking the MoveFirstHalf child.

@pchote

This comment has been minimized.

Copy link
Member

commented Jun 21, 2019

All the workarounds I can think of are going to be ugly. The least ugly will be to have MoveSecondHalf set a variable on the parent Move that specifies how much movement speed/fraction is left over for use in the next move, and then pass that as the starting fraction to the newly queued MoveFirstHalf.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.