Add adjustable delay to how fast QuickDrop fires

[clyfordv]

Saw enough talk both ways that I'd figured I'd bang this out as an option. Adds a minimum time for QuickDrop to fire.

Reasons:

• Provides a balance knob
• Current drop looks a little too sharp (units fly off at an odd velocity, transport isn't settled)

[lL1l1]

Forking a thread waits 1 tick but then WaitTicks correctly waits 10 ticks from before the thread was forked. e.g.:

LOG(GetGameTick()) -- tick 1
ForkThread(function ()
LOG(GetGameTick()) -- tick 2
WaitTicks(10)
LOG(GetGameTick()) -- tick 11

I don't really understand it but it works as long as QuickDropDelay >= 2 (1 delay ends up the same as 2).

[clyfordv]

Do you think that warrants a warning if the delay is too short? I don't see this number being changed too often.

[Garanas]

Waiting ticks is a bit strange - waiting 0 and 1 ticks is effectively the same tick! When we pass in 1 tack then we effectively tell the game to perform this function at the end of the current tick. When we wait 2 ticks, we tell the game to queue it for the next tick.

Effectively we also wait for the 'current' tick.

[lL1l1]

Do you think that warrants a warning if the delay is too short? I don't see this number being changed too often.

I think a comment saying that the minimum is 2 ticks is sufficient.

When we pass in 1 tack then we effectively tell the game to perform this function at the end of the current tick. When we wait 2 ticks, we tell the game to queue it for the next tick.

Is that why some waits have off by 1 error compensation?

fa/lua/EffectUtilitiesUEF.lua

Lines 24 to 29 in b29226f

	-- various delays in ticks + 1
	local BuildCubeGlowDuration = 2
	local BuildCubeDelay = 8
	local BuildCubeFirstSliceDelay = 3
	local BuildCubeSlicePeriod = 12
	local BuilderSlicePeriod = 6

fa/lua/sim/projectiles/components/TacticalMissileComponent.lua

Lines 132 to 135 in b29226f

	for t = 0.2, accelTime, 0.2 do
	self:SetMaxSpeed(maxSpeed - (maxSpeed - terminalSpeed) * t/accelTime)
	WaitTicks(3) -- This waits 2 ticks instead of 3 according to GetGameTick().
	end

fa/lua/sim/units/seraphim/SEnergyBallUnit.lua

Lines 82 to 84 in b29226f

	-- Wait a tick to let the target update awesomely.
	WaitTicks(2)
	self.timeAlive = self.timeAlive + .1

[Garanas]

I'm not sure if this pull request takes it in the right direction. I understand what it is trying to fix, but what if we'd just remove the quick drop functionality instead?

Since the transport changes loading and unloading was much faster than it was before to begin with. I may run a few simulations to verify how much quick drop actually makes everything drop faster.

[clyfordv]

The original motive was not even to make transports drop faster, but to untangle drop time from transport LiftFactor and K factors, given that:

1. Transports are pretty particular about how close they need to be to their drop point before releasing cargo.
2. Adjusting flight characteristics so that transports don't (as an example) descend from mountains at a glacially slow pace caused them to oscillate around their drop point, taking even longer.

If [1] has been fixed (through an engine patch?) I could see quick drop no longer being necessary, but as long as it remains [2] is going to apply.

I didn't see a huge need for the addition of this delay, but it was raised as an issue on the discord (not a majority opinion, perhaps) so I figured I'd bang it out.

(And a minor point, but the visuals of the transports taking a moment to level out are much better, which means we could undo the bank factor changes that came with the original QuickDrop because dropping at a steep bank looked rather jarring.)

[lL1l1]

When I was logging the tick timings I noticed that it drops without having to abort navigation when arriving to the drop location from a lower surface height (e.g. from water/land onto a cliff/plateau), and it does abort navigation when arriving to the drop location from an equal surface height.
So while it isn't a perfect balance knob because it doesn't handle cliff drops, it can be useful to make normal drops faster or slower.

[Garanas]

With these changes

transports-with.mp4

Without the quick drop feature

transports-without.mp4

There's not much difference in my opinion. Of course some maps have rather extreme cliffs, but there's a limit to what we can (not) support.