Files
DarkflameServer/dGame/dComponents/Character/PlayerForcedMovementComponent.cpp
Aaron Kimbrell 1382606bd1 fix: constructions keep pending changes of five more components
The level, forced movement, possessable, possessor and combat AI parts
are each read behind a flag bit (LWOLevelProgressionComponent::
Deserialize 0x00c63bd0 and the others). DLU cleared their dirty flags
when it wrote a construction, which goes only to the client the object
came into range of, so a change waiting for the next update never
reached the clients already watching: a level up, a mount or dismount,
a rail ride.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-10 14:26:46 -06:00

25 lines
1.0 KiB
C++

#include "PlayerForcedMovementComponent.h"
#include "Entity.h"
#include "ObjectLoadState.h"
PlayerForcedMovementComponent::PlayerForcedMovementComponent(Entity* parent, const int32_t componentID) : Component(parent, componentID) {
m_Parent = parent;
}
PlayerForcedMovementComponent::~PlayerForcedMovementComponent() {}
void PlayerForcedMovementComponent::Serialize(RakNet::BitStream& outBitStream, bool bIsInitialUpdate) {
outBitStream.Write(m_DirtyInfo || bIsInitialUpdate);
if (m_DirtyInfo || bIsInitialUpdate) {
outBitStream.Write(m_PlayerOnRail);
outBitStream.Write(m_ShowBillboard);
}
if (!bIsInitialUpdate) m_DirtyInfo = false;
}
void PlayerForcedMovementComponent::Allocator(Entity& entity, ObjectLoadState& state) {
// From the registry, as the client makes it (a character got one with its character component)
const auto id = state.GetComponentID(eReplicaComponentType::PLAYER_FORCED_MOVEMENT, -1);
if (id > -1 && !entity.HasComponent(eReplicaComponentType::PLAYER_FORCED_MOVEMENT)) entity.AddComponent<PlayerForcedMovementComponent>(id);
}