The three components were made from the registry and wrote nothing, so
the client read the next component's bits as theirs.
- LWOChestComponent::Deserialize (0x00c22010), construction only: the
player (u64) and the loot offer count (u32).
- LWOChoiceBuildComponent::Deserialize (0x00bf26d0): a flag, then the
state (u32, 0 waiting, 1 building), the built object and the user
(u64 each). Always in a construction.
- LWORollerComponent::Deserialize (0x00c15920), construction: the level's
activity_camera_pos and activity_camera_lookat_pos (3 floats each) and
the projectile skill (u32, the client starts at 1348); then the flag of
the block about its user, which is never set.
LWOGameObject::Deserialize (0x00f99690) reads the components in the order
of the object's component list, which ObjectLoader2::DoObjectComponentLoad
(0x0105ebb0) fills in the order of FillComponentOrder (0x0101f8e0): the
roller after the shooting gallery and before the moving platform, the
choice build after the moving platform and before the LUP exhibit and the
model, the chest after the zone control and before render. They are
placed against the components their objects have.
The gate rush control (103) is left out: its two registry entries have no
object, and there is no component for it.
Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
The client makes the trigger component of an object whose header sets
the trigger bit after all the others, and reads it last:
LWOTriggerComponent::Deserialize (0x00bd78c0) takes a flag bit and a
32-bit pick type. Every live construction of a trigger object ended with
the flag and -1 (4,533 of 4,533); DLU wrote nothing, which the client
read as no flag. Nothing changes for the player: -1 is the client's
default.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The client keeps an object's children as a set of ids
(LWOGameObject::childObjects). Every multi-child list in the live captures
(57) was in ascending id order. A child added twice is now kept once. The
child count also counted entries the loop then skipped.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LWOGameObject loads these itself: interactionDistance from its Objects row
(16 without one) and the level's interaction_distance over it,
CheckPrecondition and objectWorldState from the level config, before its
components load theirs. The quickbuild, the pet and the race instancer read
them from the object; the race instancer now uses the Objects row's
distance like the client does, instead of a fixed 16.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The parent info always said the object doesn't move with its parent. Live
sent true for objects a spawn behavior made with updatePositionWithParent
(all 70 Engineer Personal Fortress constructions in the captures, LOT 9479,
and the Summoner's Scratch, 9644); the client then moves them with the
player. Every other construction in the captures sent false, and none sent
an object world state, which stays unsent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Handlers sat in an unordered_multimap, whose order for one message is up to
the standard library: GCC ran them newest first, so the components loaded
last answered a RequestUse first, and Windows builds could differ. They are
now kept per message in registration order: the object's own handlers, then
its components' in load order (LWOGameObject::PassMessageToComponents).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
DoObjectComponentLoad walks the client's load order and calls the type's
allocator from a table, like ObjectLoader2, instead of one 76-case switch.
Components with rules of their own have a static Allocator (the client's
LWOxComponent::Allocator); the rest share a registry allocator. The load
state moves to ObjectLoadState.h so the allocators can take it.
Construction bytes are identical for all 15,962 LOTs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The client gives a character no mission offer component (LOT 1's registry
has none; DLU's had no missions) and never makes racing stats (74 is not in
its component load order). Same bytes for every LOT.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The client's script allocator adds them only for a script component it makes
(a registry script with a non-zero id, or a custom script in the config it is
sent). Characters and the registry-id-0 script LOTs no longer get them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LWOGameObject::MakeReadyForSerialization runs each component's
LoadConfigData and then a character's LoadFromSaveData, in the order the
components were made, once DoObjectComponentLoad has made them all; then
their Startup. Entity::Initialize now does the same with a component list in
creation order (the client's componentList); the walk's own save calls
(mission, physics, destroyable, level, character, skill, ghost) and the
destroyable's call into the buff go. A model's behaviors load in its
LoadConfigData; controllable physics places a non-character at
construction, as the client's physics takes the spawn position. A component
added later still loads at once. Same bytes for every LOT.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
As LWOControllablePhysComponent's and LWOPhantomPhysicsComponent's
allocators do (like the simple physics one already): the registry's physics
id is left to the model case, which makes the model's physics.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The client makes a BBB component (76) for a character (DoObjectPreLoad, LOT 1)
and for registry entries (none in the CDClient), and reads it last
(LWOBBBComponent::Deserialize: a metadata-source-item bit and the item).
DLU wrote a placeholder 0 bit at the end of every construction; now only a
character's BBBComponent writes it. Every other object sends one bit less,
which the client never read (live non-player constructions decode without
it; the zone control object stays byte for byte equal to live).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The destroyable slot makes only the registry's (with its buff); a
collectible's destroyable comes right after the collectible when there is
none, and a smashable object's (is_smashable) after the walk
(LWODestroyableComponent::Allocator), as in DoObjectComponentLoad. A
quickbuild or model with is_smashable now gets its own defaults first, as
the client's order gives it. Same bytes for every LOT.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ApplyMovementAiIfNeeded gives an object with a script (its registry's or a
custom script) or an attached_path a movement AI component (id 0); 1843 LOTs
gain one. It follows its attached path only when that is a movement path (a
moving platform's path stays the platform's). Not on spawner objects, which
the client never loads. Nothing sent changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.10.64's DoObjectComponentLoad has an EXHIBIT case that makes nothing;
DLU makes ExhibitComponent there, built like LWOExhibitComponent on the
spawner component: its ExhibitComponent row (model offset and size) and the
exhibit_* level keys. It sends nothing in a construction (the client's
Deserialize is empty), so the 12 exhibit LOTs keep their bytes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Entity::Initialize now runs DoObjectPreLoad (what the components will be:
the player's own components, markedAsPhantom, model behaviors, the
component whitelist) and DoObjectComponentLoad (the walk in the client's
order and what the client adds after it), as ObjectLoader2 does, with an
ObjectLoadState that answers the registry through the whitelist. Same
components and bytes for every LOT.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The client makes a script component for a registry script with a non-zero
id, or for a custom script in the config it is sent (LOT 176 never):
ApplyScriptComponentIfHasScript and LWOScriptComponent's allocator. A
character's script and a server-only custom_script_server stay on the
server and send nothing. The 5 LOTs whose registry script id is 0 (e.g. the
AG concert fan, LOT 3002: live sent no config and no script) lose the bit
the client never read.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
From ObjectLoader2 (DoObjectPreLoad / DoObjectComponentLoad):
- componentWhitelist N keeps only that whitelist's registry components
(ApplyComponentWhitelist; property models use 1).
- No pet component for an object in an inventory (LWOPetComponent::Factory).
- Havok vehicle physics: use_simple_physics makes simple physics instead,
objectWorldState 2 none.
- markedAsPhantom (any value) turns the registry's simple physics into
phantom physics with that row, and doesn't count when the registry has
phantom physics.
- Vendors get a proximity monitor first when they have none; a mission
offer's object gets one after the walk (113 LOTs gain one).
Same bytes for every LOT.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Where an object starts (where the level put it) moves into
ControllablePhysicsComponent::LoadConfigData, and where a character comes
into the world (its save, then its respawn point, the target scene or the
zone's spawn when it came from elsewhere) into LoadFromSaveData, out of
Entity::Initialize. Same placement.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The ScriptComponent row (server and client script) loads in
LoadDataFromTemplate and custom_script_server / custom_script_client in
LoadConfigData, out of Entity::Initialize, which only decides whether there
is one (a registry entry, a character or a custom script), as the client's
allocator does. Same scripts and bytes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Vendor (16), donation vendor (100) and achievement vendor (102) are separate
entries in the client's component walk; no LOT has two of them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The ProximityMonitorComponent row's radii and the MovementAIComponent row
(with the level's wanderRadius over it) move out of Entity::Initialize into
each component's LoadDataFromTemplate / LoadConfigData. Same components and
bytes for every LOT.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LWOCharacterComponent::Factory makes possession control, mount control, pet
creator, level progression and forced movement, then the character, all with
componentID -1; DLU now makes the same set in the same order (mount control
and pet creator are new, empty). The ghost is added after the component walk,
where the client adds it, for a character with physics. Nothing sent changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The client makes 106 from the registry; the only non-character LOT with it
(16684, a test skateboard mount) now has one and writes it between the pet
and the character, the client's place for it. A character still writes it
with its other parts.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Minigame control (50) is an activity component in the client
(LWOMinigameComponent) and is made from the registry, so the zone control
object (LOT 2365, registry id 0) has one; it sends what an activity sends
(dirty, no players), not a fixed 0x40000000 (which nothing sent: the old
id > 0 check never made it). The zone's script on that object is server
only: the client makes no script component for it, so it sends nothing.
DLU's zone control construction now equals live's byte for byte (209
captures, e.g. GruntMonkey world2); the decoder reads 50 as an activity.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
LWOQuickBuildComponent uses the activity component's functions; DLU's
QuickBuildComponent now derives ActivityComponent. Its RebuildComponent row
(the activity among it) loads in LoadDataFromTemplate and the level's
overrides in LoadConfigData, out of Entity::Initialize. It still writes its
own replica data (same construction and update bytes) and spawns its
activator as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ObjectLoader2::LoadModelBehaviorsComponent: a model without physics gets simple
physics 4247 (with behaviors: controllable 4246 for modelType 0, else simple,
or the registry's id, which the simple physics case leaves to it), and
modelType 0 gets pathfinding control. This replaces the BBB model (LOT 14)
special case, which now loads through the registry like any object (same
bytes as live LOT 14 constructions); the 17 other model LOTs without
physics in the registry now get the simple physics the client makes for them.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The DestructibleComponent row moves from Entity::Initialize into
LoadDataFromTemplate and the level keys into LoadConfigData; a character's
save loads after both. Like the client (LWODestroyableComponent::LoadConfigData
reads them for every destroyable), the destroyables added for models and
quickbuilds now also read set_faction, is_smashable and the level loot matrix;
their live defaults become their template. Nothing changes for objects without
those keys.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Components no longer have a virtual OnUse; each component that reacts to a
use registers a RequestUse handler, like the client's components. The entity
runs the INTERACT trigger and the script, then delivers a RequestUseEvent
(carrying the user) to the handlers. The mission choice of a multi-interact
use goes only to the mission offer, as before. Switches keep a direct
EnterIfResponding for touches and pets.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Components get the client's per-component functions: LoadDataFromTemplate,
PrepareConfigData, LoadConfigData, LoadFromSaveData, Startup, Run,
OnEnterScope, OnLeaveScope, Preshutdown and Shutdown, called by the entity in
the client's order. Update is renamed Run, LoadFromXml LoadFromSaveData and
UpdateXml WriteSaveData. Nothing sent changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
