Smoother piece attachment visuals (and even physical locations?)

[GoogleFrog]

The units in that gif are carrying structures via Spring.AttachUnit. They visibly lag quite a distance behind the underlying pieces, as the arms of the units move left and right as they walk. It would be a great improvement for modular unit games, or things such as big ship with constructable hardpoints, if units were a bit better at updating their position to the underlying pieces. I'm aware that things like frame interpolation are likely to make the problem not entirely solvable, but perhaps there is something cheap to try that would still be a noticeable improvement.

[saurtron]

Do you mean Spring.UnitAttach?

Also, if you could provide some explanation about how to replicate that, would be great. Like, if it's something z-k does, what's the fastest way to do it (what units to /give for example).

[Beherith]

Give a hat to the enemy team
/give cor_hat_viking 1
Capture the hat with your commander :D
Watch it bob.

[lhog]

This is going to be complicated to do right.

Ideally we want to:

1. Run unit scripts for normal units and transporters
2. Run the transporter -> transportees subordination logic to put transportees into the right position and orientation
3. Run unit scripts for transportees

Now since Lua unit scripting is controlled solely by Lua and can generally be executed from many different callins, I just don't see how we can line it all up to match the flow above.

What we perhaps can try to do is to run parts of CUnit::UpdateTransportees() code after the animation is played for the current frame, while it will fix bobbing, it's still a hack as transportees' unit scripts will receive wrong input about the object orientation.

@GoogleFrog send instructions how to reproduce Warrior + Storage attachment, BAR's hats bobbing is harder to track.

[GoogleFrog]

send instructions how to reproduce Warrior + Storage attachment, BAR's hats bobbing is harder to track.

Run this commit on this branch: ZeroK-RTS/Zero-K@0acf0bc

Spawn cloakriot. Drag select to select it rather than the storage, then move it around.

Ideally we want to:

1. Run unit scripts for normal units and transporters
2. Run the transporter -> transportees subordination logic to put transportees into the right position and orientation
3. Run unit scripts for transportees

Why would we need to run the unit scripts for transportees in their own step? It is highly uncommon for the position of a unit to impact how its script runs, especially when it is being transported rather than moving around by itself. I ask because unit attachment is recursive, and your three steps doesn't take that into account since all the transportees are being assigned a position regardless of their attachment-depth.

My current guess is that running all scripts, then recursively updating all positions would work. I could see this going wrong with things like aiming though, I don't know quite how the ordering there works.

[lhog]

Yeah the concerning parts would be aiming and any code that makes assumptions about the unit position (say precise legs placement)

[lhog]

The PR above reverts back the interpolation method spring/spring#460 introduced and while it fixes the attached units bobbing, it reintroduces unit jittering caused by inconsistency of future position and speed vector. Such inconsistencies happen during abrupt / artificial changes of unit position. Most prominent case is unit-unit or unit-feature collision avoidance: these will teleport unit to avoid objects clipping into each other.

So to avoid that spring/spring#460 introduced (X-1) --> (X) interpolation, while in fact drawing happens post sim frame (X). This causes any unit position to lag behind 1 sim frame the current synced position. In the same time piece positions are not interpolated and thus represent the state at frame (X), therefore you see inconsistency between the attached unit that is (X-1) sim frame based and catching up to frame (X) every draw frame between (X-1) and (X) and pieces position that are taken straight from frame X. This happens even if the transportee alignment happens after animation scripts (that was something I thought to be the root cause initially).

Long story short it's not possible to fix currently in a clean way, but moving on (and it's planned):

1. All draw interpolation should be changed to be (X-1) --> (X) based (currently only unit positions are interpolated like that)
2. Introduce animation interpolation and also base it on (X-1) --> (X) method

I think all of this will be done during 2025