Previously movementInfo.fallTime was always 0 and jumpVelocity/jumpSinAngle/
jumpCosAngle/jumpXYSpeed were never populated. The server reads fallTime
unconditionally from every movement packet and uses it to compute fall damage
and anti-cheat heuristics; the jump fields are required when FALLING is set.
Changes:
- Add isFalling_ / fallStartMs_ to track fall state across packets
- MSG_MOVE_JUMP: set isFalling_=true, record fallStartMs_, populate jump fields
(jumpVelocity=7.96, direction from facing angle, jumpXYSpeed from server
run speed or walk speed when WALKING flag is set)
- MSG_MOVE_FALL_LAND: clear all fall/jump fields
- sendMovement: update movementInfo.fallTime = (time - fallStartMs_) each call
so every heartbeat and position packet carries the correct elapsed fall time
- World entry: reset all fall/jump fields alongside the flag reset
applyKnockBack() sets grounded=false and applies vertical velocity, but
the normal jump detection path (nowJump && !wasJumping && grounded) never
fires during a server-driven knockback because no jump key is pressed.
Without MSG_MOVE_JUMP the game_handler never sets MovementFlags::FALLING
in movementInfo.flags, so all subsequent heartbeat packets carry incorrect
flags — the server sees the player as grounded while airborne.
Fix: fire movementCallback(MSG_MOVE_JUMP) directly from applyKnockBack()
so the FALLING flag is set immediately. MSG_MOVE_FALL_LAND is already sent
when grounded becomes true again (the existing wasFalling && grounded path).
Previously the handler ACKed with current position and ignored the
velocity fields entirely (vcos/vsin/hspeed/vspeed were [[maybe_unused]]).
The server expects the client to fly through the air on knockback — without
simulation the player stays in place while the server models them as airborne,
causing position desync and rubberbanding.
Changes:
- CameraController: add applyKnockBack(vcos, vsin, hspeed, vspeed)
that sets knockbackHorizVel_ and launches verticalVelocity = -vspeed
(server sends vspeed as negative for upward launches, matching TrinityCore)
- Physics loop: each tick adds knockbackHorizVel_ to targetPos then applies
exponential drag (KNOCKBACK_HORIZ_DRAG=4.5/s) until velocity < 0.05 u/s
- GameHandler: parse all four fields, add KnockBackCallback, call it for
the local player so the camera controller receives the impulse
- Application: register the callback — routes server knockback to physics
The existing ACK path is unchanged; the server gets position confirmation
as before while the client now actually simulates the trajectory.
CMSG_LFG_SET_BOOT_VOTE was defined in the opcode table but never sent.
- Add GameHandler::lfgSetBootVote(bool) which sends the packet
- Fix handleLfgBootProposalUpdate() to set lfgState_=Boot while the
vote is in progress and return to InDungeon when it ends
- Add Yes/No vote buttons to the Dungeon Finder window when in Boot state
Extend the locomotion state-change detection to include the WALKING
movement flag. Previously a creature that switched from walking to
running (or vice versa) while staying in the moving state would keep
playing the wrong animation because only the moving/idle transition
was tracked.
Add creatureWasWalking_ alongside creatureWasSwimming_ and
creatureWasFlying_; guard the walking check with isMovingNow to avoid
spurious triggers when the flag flips while the creature is idle.
Clear and erase the new map at world reset and creature/player despawn.
Previously, the animation update for other entities (creatures, players)
was only triggered when the moving/idle state changed. This meant a
creature landing while still moving would stay in FlyForward instead of
switching to Run, and a flying-idle creature touching down would keep
the FlyIdle animation instead of returning to Stand.
Fix: track creatureWasSwimming_ and creatureWasFlying_ alongside
creatureWasMoving_, and fire the animation update whenever any of the
three locomotion flags change. Clean up the new maps on world reset and
on per-creature despawn.
Previously the move-flags callback only tracked SWIMMING and WALKING,
so flying players/mounts always played Run(5) or Stand(0) animations
instead of Fly(61)/FlyIdle(60).
Changes:
- Add creatureFlyingState_ (mirroring creatureSwimmingState_) set by
the FLYING flag (0x01000000) in unitMoveFlagsCallback_.
- Update animation selection: moving+flying → 61 (Fly/FlyForward),
idle+flying → 60 (FlyIdle/hover). Flying takes priority over swim
in the priority chain: fly > swim > walk > run.
- Clear creatureFlyingState_ on world reset.
isPortalVisible() was computing the world-space AABB by directly
transforming pMin/pMax with the model matrix. This is incorrect for
rotated WMOs — when the model matrix includes rotations, components can
be swapped or negated, yielding an inverted AABB (worldMin.x >
worldMax.x) that causes frustum.intersectsAABB() to fail.
Fix: transform all 8 corners of the portal bounding box and take the
component-wise min/max, which gives the correct world-space AABB for any
rotation/scale. This was the root cause of portals being incorrectly
culled in rotated WMO instances (e.g. many dungeon and city WMOs).
Also squash the earlier spline-speed no-op fix (parse guid + float
instead of consuming the full packet for SMSG_SPLINE_SET_FLIGHT_SPEED
and friends) into this commit.
These four movement-broadcast opcodes (server relaying another player's
movement packet) were not dispatched at all, causing nearby entity
positions to be silently dropped for pitch changes and gravity/fly state
broadcasts. Also add them to the kMoveOpcodes batch-parse table used by
SMSG_COMPRESSED_MOVES, and parse SMSG_SPLINE_SET_FLIGHT/WALK/etc. speeds
properly instead of consuming the whole packet.
Previously these four spline-move opcodes were silently consumed with
packet.setReadPos(getSize()), skipping even the packed-GUID read.
- SMSG_SPLINE_MOVE_UNSET_FLYING: now reads packed guid and fires
unitMoveFlagsCallback_(guid, 0) to clear the flying animation state on
nearby entities (counterpart to SMSG_SPLINE_MOVE_SET_FLYING).
- SMSG_SPLINE_MOVE_UNROOT, SMSG_SPLINE_MOVE_UNSET_HOVER,
SMSG_SPLINE_MOVE_WATER_WALK: now properly parse the packed guid instead
of consuming the full packet; no animation-state callback needed.
These three server-push opcodes were silently consumed without sending
the required client acks, causing the server to stall waiting for
confirmation before granting the capability.
- SMSG_MOVE_SET_CAN_TRANSITION_BETWEEN_SWIM_AND_FLY →
CMSG_MOVE_SET_CAN_TRANSITION_BETWEEN_SWIM_AND_FLY_ACK (via handleForceMoveFlagChange)
- SMSG_MOVE_UNSET_CAN_TRANSITION_BETWEEN_SWIM_AND_FLY →
same ack opcode (no separate unset ack exists in WotLK 3.3.5a)
- SMSG_MOVE_SET_COLLISION_HGT → CMSG_MOVE_SET_COLLISION_HGT_ACK via new
handleMoveSetCollisionHeight() which appends the float height after the
standard movement block (required by server-side ack validation)
These opcodes were inadvertently falling through to the LAND_WALK
handler (same case label), causing incorrect CMSG_MOVE_WATER_WALK_ACK
acks to be sent for gravity changes. Split into dedicated cases that
send CMSG_MOVE_GRAVITY_DISABLE_ACK and CMSG_MOVE_GRAVITY_ENABLE_ACK
respectively, as required by the server protocol.
These are the removal counterparts to SMSG_MOVE_WATER_WALK and
SMSG_MOVE_FEATHER_FALL. The server expects the matching ack with the
flag cleared; previously these packets were consumed silently which
could leave the server's state machine waiting for an acknowledgement.
SMSG_MOVE_SET_FLIGHT and SMSG_MOVE_UNSET_FLIGHT were previously consumed
silently without sending the required ack. Most server implementations
expect CMSG_MOVE_FLIGHT_ACK before toggling the FLYING movement flag on
the player; without it the server may not grant or revoke flight state.
Also updates movementInfo.flags so subsequent movement packets reflect
the FLYING flag correctly.
The complement to MSG_MOVE_START_ASCEND was missing from both the
main dispatch switch and the compressed-moves opcode table, causing
downward vertical movement of flying players to be dropped.
MSG_MOVE_START_PITCH_UP, MSG_MOVE_START_PITCH_DOWN, MSG_MOVE_STOP_PITCH,
MSG_MOVE_START_ASCEND, MSG_MOVE_STOP_ASCEND were defined in the opcode
table but never routed. The server relays these when another player
pitches or ascends/descends while flying. Without dispatch, position
updates embedded in these packets were silently dropped, causing flying
players to appear to not move vertically. Also adds these to the
compressed-moves opcode recognition array.
handleCompressedMoves uses a hardcoded opcode array to recognise which
sub-packets should be routed to handleOtherPlayerMovement. The two newly
dispatched opcodes were not in this list, so walk/run mode transitions
embedded in SMSG_COMPRESSED_MOVES / SMSG_MULTIPLE_MOVES batches were
silently dropped.
These two opcodes were defined in the opcode table but never routed to
handleOtherPlayerMovement. The server sends them when another player
explicitly toggles walk/run mode. Without dispatch, the WALKING flag
from these packets was never processed, so other players appeared to
always run even after switching to walk mode (until the next heartbeat).
Extends the cold-join fix (block.moveFlags) to the Classic and TBC
parseMovementBlock implementations so that SMSG_UPDATE_OBJECT CREATE
packets on Classic/TBC servers also initialise entity swim/walk state
from the spawn-time movement flags via unitMoveFlagsCallback_.
The previous fix added SWIMMING (0x00200000) correctly but kept 0x02000000
which is SPLINE_ELEVATION (smooth vertical spline offset), not the FLYING
flag. WotLK 3.3.5a FLYING = 0x01000000; pitch should be read when SWIMMING
or FLYING are active. This corrects the condition and updates the comment.
UpdateBlock now stores moveFlags from the LIVING movement block so the
cold-join problem is fixed: entities already swimming or walking when the
client joins get their animation state correctly initialised from the
SMSG_UPDATE_OBJECT CREATE_OBJECT packet rather than waiting for the next
MSG_MOVE_* heartbeat.
Additionally, SMSG_SPLINE_MOVE_START_SWIM, SMSG_SPLINE_MOVE_STOP_SWIM,
SMSG_SPLINE_MOVE_SET_WALK_MODE, SMSG_SPLINE_MOVE_SET_RUN_MODE, and
SMSG_SPLINE_MOVE_SET_FLYING now fire unitMoveFlagsCallback_ with
synthesised flags so explicit server-driven mode transitions update
animation state immediately without waiting for a heartbeat.
parseMovementBlock was checking moveFlags & 0x02000000 for the pitch
field, but SWIMMING is 0x00200000 in WotLK 3.3.5a. Swimming NPCs and
players in SMSG_UPDATE_OBJECT packets never triggered the pitch read,
so the fallTime/jumpData/splineElevation fields were read from the wrong
offsets, producing incorrect positions and orientations.
Fix: check both SWIMMING (0x00200000) and FLYING (0x02000000), matching
the WotLK format — same condition used in the write path.
Add UnitMoveFlagsCallback fired on every MSG_MOVE_* with the raw
movement flags field. Application.cpp uses it to update swimming
and walking state from any packet, not just explicit START_SWIM/
STOP_SWIM opcodes — fixing cold-join cases where a player is already
swimming when we enter the world.
Per-frame animation sync now selects Walk(4) when the WALKING flag is
set, Run(5) otherwise, and Swim(42)/SwimIdle(41) when swimming.
UnitAnimHintCallback is simplified to jump (38=JumpMid) only.
- Add creatureSwimmingState_ map to track which units are swimming
- unitAnimHintCallback with animId=42 (Swim): marks entity as swimming
- unitAnimHintCallback with animId=0 (MSG_MOVE_STOP_SWIM): clears swim state
- Per-frame sync: uses Swim(42)/SwimIdle(41) when swimming, Run(5)/Stand(0) otherwise
— creatures/players now show SwimIdle when standing still in water
- Clear creatureSwimmingState_ on creature/player despawn and world reset
- MSG_MOVE_STOP/STOP_STRAFE/STOP_TURN/STOP_SWIM/FALL_LAND: snap entity to
stop position (duration=0) and pass durationMs=0 to renderer so the
Run-animation flash is suppressed; per-frame sync plays Stand on next frame
- MSG_MOVE_JUMP: fire new UnitAnimHintCallback with anim 38 (JumpMid) so
other players and NPCs visually leave the ground during jumps
- MSG_MOVE_START_SWIM: fire UnitAnimHintCallback with anim 42 (Swim)
- Wire up UnitAnimHintCallback in application.cpp; skips Death (anim 1)
The renderer's CharAnimState machine already drives player character
animations (Run=5, Walk=4, Jump, Swim, etc.) — remove the conflicting
camera controller code added in the previous commit.
Fix creature movement animations to use the correct WoW M2 IDs:
4=Walk, 5=Run. Both the per-frame sync loop and the SMSG_MONSTER_MOVE
spline callback now use Run (5) for NPC movement.
CameraController now plays Walk (5) for backpedal/slow pace and Run (4)
for forward running (runPace), matching WoW's animation convention.
Also handles transitions between Walk and Run while already moving.
creatureMoveCallback now plays anim 4 (Run) when a spline move begins
(durationMs > 0), mirroring the per-frame sync logic so NPC/player
characters animate correctly during server-driven path moves as well
as position-sync moves.
CameraController now transitions the player character to Run (anim 4)
on movement start and back to Stand (anim 0) on stop, guarded by a
prevPlayerMoving_ flag so animation time is not reset every frame.
Death animation (anim 1) is never overridden.
Application creature sync similarly switches creature models to Run (4)
when they move between server positions and Stand (0) when they stop,
with per-guid creatureWasMoving_ tracking to avoid per-frame resets.
Add GhostStateCallback to GameHandler, fired when PLAYER_FLAGS_GHOST
transitions on or off in UPDATE_OBJECT / login detection. Add
setInstanceOpacity() to CharacterRenderer to directly set opacity
without disturbing fade-in state. Application wires the callback to
set opacity 0.5 on ghost entry and 1.0 on resurrect.
Add CameraController::setSitting() and call it from the StandStateCallback
so the camera blocks movement when the server confirms the player is
sitting or kneeling (stand states 1-6, 8). This prevents the player
from sliding across the ground after sitting.
Death (state 7) deliberately leaves sitting=false so the player can
still respawn/move after death without input being blocked.
Add StandStateCallback to GameHandler, fired when the server confirms
a stand state change (SMSG_STANDSTATE_UPDATE). Connect in Application
to map the WoW stand state (0-8) to M2 animation IDs on the player
character model:
- 0 = Stand → anim 0 (Stand)
- 1-6 = Sit variants → anim 27 (SitGround)
- 7 = Dead → anim 1 (Death)
- 8 = Kneel → anim 72 (Kneel)
Sit and Kneel animations are looped so the held-pose frame stays
visible; Death stays on the final frame.
Add SpellCastAnimCallback to GameHandler, triggered on SMSG_SPELL_START
(start=true) and cleared on SMSG_SPELL_GO / SMSG_SPELL_FAILURE
(start=false) for both the player and other units.
Connect the callback in Application to play animation 3 (SpellCast) on
the player character, NPCs, and other players when they begin a cast.
The cast animation is one-shot (loop=false) so it auto-returns to Stand
when complete via the existing return-to-idle logic.
Also fire stop-cast on spell failure to cancel any stuck cast pose.
When a non-looping animation (e.g. wave, cheer, laugh emote) reaches
its end, transition back to Stand (animation 0) rather than freezing
on the last frame. Death (animation 1) is excluded — it stays on the
final frame as expected.
Fixes NPCs and players getting stuck in emote poses after SMSG_EMOTE.
Remove active file-I/O debug block in character_renderer.cpp that
wrote composite textures as raw binary files to /tmp on every texture
composite generation. Remove the now-unused <fstream> include.
Remove the 10-shot hex dump of decompressed SMSG_MONSTER_MOVE payloads
in game_handler.cpp (dumpCount static); format has been confirmed.
SMSG_EMOTE packets for NPCs and other players were received but the
emoteAnimCallback_ was never wired to the rendering layer. Register
the callback in application.cpp so that when the server sends an emote
animation ID, the corresponding CharacterRenderer instance plays it as
a one-shot animation (loop=false), falling back to idle on completion.
Lookups check creatureInstances_ first, then playerInstances_ so both
NPCs and other online players respond to server emote packets.
Previously disabled because the per-frame raycast caused erratic zoom
snapping at doorway transitions. Re-enable using an asymmetrically-
smoothed collision limit: pull-in reacts quickly (τ≈60 ms) to prevent
the camera from ever visibly clipping through walls, while recovery is
slow (τ≈400 ms) so walking through a doorway zooms back out gradually
instead of snapping.
Uses wmoRenderer->raycastBoundingBoxes() which already has strict wall
filters (|normal.z|<0.20, surface-alignment check, ±0.9 height band)
to ignore floors, ramps, and arch geometry.
pendingCreatureQueries and pendingGameObjectQueries_ were never cleared on
disconnect. If a query was sent but the response lost (e.g. server
disconnect mid-flight), the entry would remain in the pending set after
reconnect, causing queryCreatureInfo/queryGameObjectInfo to silently skip
re-issuing the query — leaving NPC and GO names unpopulated for those
entries.
Clear both sets on disconnect so reconnect sees them as unqueried and
re-sends the queries as needed. creatureInfoCache/gameObjectInfoCache_ are
intentionally preserved across sessions to avoid re-querying entries whose
responses did arrive.
Every GameObject CREATE block was logged at WARNING level, spamming the
warning log with doors, chests, and other world objects. Demote to DEBUG
since this is routine spawn traffic; keep transport detection at INFO since
those are noteworthy.
After reconnect, `creaturePermanentFailureGuids_` and `deadCreatureGuids_`
could retain stale entries for GUIDs not tracked in `creatureInstances_`
(creatures that failed to load or died before being spawned). These stale
entries would silently block re-spawning or cause wrong death state on the
fresh CREATE_OBJECTs the server sends after reconnect.
Clear both caches in the reconnect-to-same-map path so server state is
authoritative after every reconnect.
The previous reconnect fix caused loadOnlineWorldTerrain to run, which
cleared and reloaded all terrain tiles — unnecessarily heavy for a
reconnect where the map hasn't changed.
New path: when isInitialEntry=true and mapId==loadedMapId_, despawn all
tracked creature/player/GO instances from the renderer (proper cleanup),
clear all pending spawn queues, update player position, and return — the
terrain stays loaded and the server's fresh CREATE_OBJECTs repopulate
entities normally.
Previously, if any single block in an SMSG_UPDATE_OBJECT packet failed
to parse (e.g. unusual spline flags), the entire packet was dropped and
all entities in it were lost. On busy zones with many CREATE_OBJECTs in
one packet, one bad NPC movement block would silently suppress all NPCs
that followed it in the same packet.
- parseUpdateObject: break instead of return false on block failure,
so already-parsed blocks are returned to the caller
- handleUpdateObject: fall through to process partial data when parsing
returns false but some blocks were successfully parsed
On disconnect/reconnect to the same map, entityManager was not cleared
and creatureInstances_ still held old entries from the previous session.
When the server re-sent CREATE_OBJECT for the same GUIDs, the spawn
callback's early-return guard (creatureInstances_.count(guid)) silently
dropped every NPC re-spawn, leaving the world empty.
Fixes:
- disconnect() now calls entityManager.clear() to purge stale entities
- WorldEntryCallback gains a bool isInitialEntry parameter (true on first
login or reconnect, false on in-world teleport/flight landing)
- Same-map optimization path skipped when isInitialEntry=true, so
loadOnlineWorldTerrain runs its full cleanup and properly despawns old
creature/player instances before the server refreshes them
- Load WorldMapArea.dbc lazily on first use to build areaId→name lookup
- /who results now show [Zone Name] alongside level: 'Name - Level 70 [Stormwind City]'
- SMSG_EXPLORATION_EXPERIENCE now shows 'Discovered Elwynn Forest! Gained X experience.'
instead of generic 'Discovered new area!' message when the zone name is available
- Cache is populated once per session and shared across both callsites
Quest kill count tracker in the HUD now resolves creature names from the
cached creature query results and displays them as "Name: x/y" instead
of bare "x/y". The system chat progress message on kill also includes
the creature name when available, matching retail client behavior.
Replace static-local firstSpecReceived with talentsInitialized_ member
variable, reset in handleLoginVerifyWorld alongside other per-session
state. Also clear learnedTalents_, unspentTalentPoints_, and
activeTalentSpec_ at world entry so reconnects and character switches
start from a clean talent state instead of carrying over stale data.
- Track PLAYER_REST_STATE_EXPERIENCE update field for all expansions
(WotLK=636, Classic=718, TBC=928, Turtle=718)
- Set isResting_ flag from SMSG_SET_REST_START packet
- XP bar shows rested bonus as a lighter purple overlay extending
beyond the current fill to (currentXp + restedXp) position
- Tooltip text changes to "%u / %u XP (+%u rested)" when bonus exists
- "zzz" indicator shown at bar right edge while resting
