Update mover handling

[thokkat]

Main implication for the game experience of this pr are that triggers for non-idle movers are properly handled, fishes move on curves now and speed can be non-constant.

• Update Speed to tick calculation: There are a few movers with extremely slow speed values. For example in Irdorath switch riddle room the gears which are triggered by the two levers have all the same measured movement speed besides speed values given are 0.2, 0.00068 and 0.00028. More values can be found in the commit message. Speed values for these rotation only movers are taken as rotations per second and scaled if value is irrationally low. First idea was to generally scale low values but that would break harbor boats.

• Handle repeated trigger events: MoverBehavior::SINGLE_KEYS and LOOP only react to trigger event in idle state. TOGGLE and OPEN_TIME always react. TRIGGER_CONTROL shows confusing behavior while testing where sometimes they behaved like TOGGLE type and sometimes wouldn't react at all when sending multiple trigger events. For now treat like SINGLE_KEY/LOOP.

• Support for MoverMessageType::NEXT: Just makes a mover move to the next keyframe in Open direction. There is only on mover of type MoverBehavior::SINGLE_KEYS in both G1/G2 in sleeper temple that requires this functionality. Other types are left out until there's something to test against.

• Rework mover advance calculation: This allows changing the state e.g. from Open to Close while moving and is necessary for repeated trigger events.

• Implement some more attributes: autoRotate: If true mover "looks" in motion direction. Used exclusively for fish speedType: defines the global speed behavior. Types are handled like in CsCamera. lerpType: defines the curve the mover is following. Type CURVE is similar to CsCamera Spline. CURVE type is only different to LINEAR for >3 keyframes which makes this exclusively to fish as well. sfxCloseStart: Sound to play once mover starts closing.

[Try]

On speed calculation topic:

Before PR, ticks per key-frame been calculated as maximum of ticks for translation and for rotation. It doesn't seem to be the case anymore. While both approaches are approximations, I do prefer previous, as it doesn't requires asset names.

[thokkat]

Hardcoded movers are like Irdorath door with super low speed:

    if(speed==0.001f) {
      // ring door in Halls of Irdorath. Possibly 0.001 is some magic value.
      ticksB = 1000;
      }

Because all have different speeds they need to be tracked individually. Looks ugly and requires per case add but I have no other solution. https://github.com/Try/OpenGothic/pull/777/commits/a00acf0f9058f030061338c361b02abd51267e74 commit message for detailed numbers.

[Try]

I've tested Irdorath and Adanos temple, so far (sorry, it took a while). There is a regression with circular half-plates, such as this one: When opens, animation looks weird, while quite good in the base-line.

https://github.com/Try/OpenGothic/commit/a00acf0f9058f030061338c361b02abd51267e74 commit message for detailed numbers.

If we will go with this solution, would need to add table as a comment to the code, so it can be easily tracked. Also will copy it here, for convenience:

first column:  time measured needed for one rotation in vanilla
second column: speed attribute
third column : tells us how much faster this mover is compared to a
mover that would take speed as rot/s.

                                   time    speed    1/(time*speed)
   newworld
   NW_MISC_WINDMILL_ROTOR_01        44.40  0.02       1.13
   NW_HARBOUR_BOAT_03              271.04  0.0005     7.38
   EVT_TROLL_GRAVE_MOVER_01         19.20  0.0001   520.83

   Irdorath
   EVT_RINGMAIN_LEFT_01              3.40  0.001    294.12
   EVT_RIGHT_WHEEL_01                5.00  0.00068  294.12
   EVT_RIGHT_WHEEL_02                5.00  0.2        1.00

   Adanos temple door addonworld
   EVT_ADDON_LSTTEMP_DOOR_LEFT_01   16.66  0.00028  214.42
   EVT_ADDON_LSTTEMP_DOOR_RIGHT_01  16.97  0.2        0.29

Those numbers makes me feel, that speed might not relevant to rotation movement. Adanos temple door is a good show-case.

[Try]

Also, experimenting now with alternation old/new methods to handle speed:

• Irdorath disk not affected - possible something off in handling actual movement
• EVT_ADDON_LSTTEMP_DOOR_LEFT_01 is fine if magic speed hack changed from speed==0.001f to speed<=0.001f

[thokkat]

With latest update state changes should now be decoupled from alpha calculation. I added more support for MoverBehavior::SINGLE_KEYS because the required tracking of target keyframe simplifies check if mover is finished for all other types.

speed might not relevant to rotation movement.

Multiplying speed with 10 resulted in 10 times faster rotation. Even the broken ones. I think speed multiplied by something is our best shot.

I bet when Irdorath gears EVT_RIGHT_WHEEL_02 and others were created all had 0.2 speed and spacer or the game somehow messed up the values but kept correct internal state. And why one side has a gear with 0.00068 but on the other side it's 0.00028. A mystery :)

magic speed hack changed from speed==0.001f to speed<=0.001f

Yeah I considered this but it breaks harbor boats where low speed is intentional.

When opens, animation looks weird

Can you check if it's ok now?

[thokkat]

fine if magic speed hack changed from speed==0.001f to speed<=0.001f

After some back and forth I took this approach and created and exception for boats to avoid name juggling.

I did some test where I added a third keyframe to Irdorath gears. Translation of left gear is then as slow as suggested by speed attribute.

https://github.com/user-attachments/assets/13b7bc5a-2449-4fe1-ac6b-be13840bfba6

.

[Try]

Merged, thanks!