Kelsi 76bf48c874 feat(transport): animate transports on the server's route clock ...

A WotLK MO_TRANSPORT publishes where it is on its route: GAMEOBJECT_LEVEL is
the route's period in milliseconds, and the high int16 of GAMEOBJECT_DYNAMIC is
how far through that period the hull currently is, as a fraction of 65535.
Neither field was being read, so the client animated on a period it worked out
for itself from distance over speed — and when that came out shorter than the
server's, the ferry simply lapped its shore until the schedule caught up.

The phase is a fraction, so it maps onto whatever timeline the client's spline
has without the two periods needing to agree, and it keeps agreeing as the ride
goes on because it advances at the server's rate rather than a derived one.

Both fields are WotLK-only; nothing earlier published a transport's phase. On
those expansions fieldIndex returns 0xFFFF, the clock is never adopted, and the
existing local animation runs unchanged — covered by a test, along with the
wrap and a zero period, which is what every non-transport GameObject reports.

This syncs the cycle, not the position within it. The client still animates one
map's slice of a cross-continent route on its own geometry, so where the hull
sits at a given phase is still the client's own answer; what changes is that it
completes exactly one cycle per server cycle instead of several. Matching the
position too means mapping the phase onto the sub-interval of the full route
that belongs to this map, which is a larger change to how slices are built.

2026-07-31 20:57:24 -07:00

..

expansions

feat(transport): animate transports on the server's route clock

2026-07-31 20:57:24 -07:00

opcodes

refactor: derive turtle opcodes from classic

2026-03-15 02:55:05 -07:00