mirror of
https://github.com/Kelsidavis/WoWee.git
synced 2026-08-01 10:21:34 -04:00
6ccc2656a5
Two of the three merge-blocking issues Kelsidavis flagged in review of PR #96 (taxi flight-path/landing/dismount fixes): 1. Activation race (the actual merge blocker). activateTaxi() set onTaxiFlight_, mounted, and started the client spline immediately after sending CMSG_ACTIVATETAXI, before SMSG_ACTIVATETAXIREPLY confirmed the server accepted it. Making updateClientTaxi() run unconditionally (this session's earlier fix) meant a rejection reply now arrived while onTaxiFlight_/taxiClientActive_ were already true, so handleActivateTaxiReply() treated it as a stale duplicate and ignored it - the client kept flying an unauthorized route. startClientTaxiPath() now only builds taxiClientPath_ as pending data; the actual activation (mount, onTaxiFlight_, taxiClientActive_) moved into a new beginTaxiFlightMotion(), called only from handleActivateTaxiReply()'s success branch. The failure branch explicitly clears the pending path data. 2. SMSG_DISMOUNT / UNIT_FIELD_MOUNTDISPLAYID=0 guards were too broad. Both unconditionally ignored the signal whenever the client's own taxi simulation was active, which fixed CMaNGOS's early-completion- estimate quirk but could make the client fly past a genuine server-side landing on cores (e.g. AzerothCore) that finalize taxi flights authoritatively. Both call sites now check the server's own UNIT_FLAG_TAXI_FLIGHT: still set means premature (ignore, let the client spline finish naturally); already cleared means the server considers the flight over. Extracted the finishTaxiFlight lambda into MovementHandler::finishClientTaxiFlight(snapToFinalWaypoint) so both the natural-completion path and these authoritative-signal handlers share one landing/cleanup implementation - the authoritative case passes false, since the server's actual stop point may not match our path's precomputed final waypoint.