acdream/docs/research/2026-08-04-retail-child-cell-ownership.md

# Retail child cell ownership — does a parent's cell change propagate to its children?

Date: 2026-08-04
Scope: Campaign C4 route 7 — settling whether the parented-child cell write
belongs in Runtime's `set_parent` analog.
Source: `docs/research/named-retail/acclient_2013_pseudo_c.txt` (Sept 2013 EoR
build, PDB-named) + `docs/research/named-retail/acclient.h` (verbatim retail
structs). Ghidra MCP was probed on 8080 and 8081 and was **not** live; the text
decomp is authoritative and was sufficient.

**Verdict up front: YES, retail propagates a parent's cell to its children, and
it does so from the physics update path — twice over, on two different branches.
Route 7's premise is sound; App's render-tick rebucket is a divergence, not the
mechanism.**

---

## 0. Struct offsets used below (verified, not assumed)

Binary Ninja renders several of the child writes as raw offset arithmetic
(`*(uint32_t*)((char*)eax_2 + 0x4c)`), so the offsets were resolved from
`acclient.h` rather than trusted from a heuristic field name.

`CPhysicsObj : LongHashData` (`acclient.h:30689`), `LongHashData :
HashBaseData<unsigned long>` (`acclient.h:30149`), `HashBaseData<unsigned long>
= { vfptr, hash_next, id }` = 12 bytes (`acclient.h:30135`).

| Offset | Field | Derivation |
|---|---|---|
| `0x0c` | `netblob_list` | base 12 |
| `0x10` | `part_array` | confirmed by use as `CPartArray*` at `0x005153c2` |
| `0x40` | `parent` | field order |
| `0x44` | `children` | field order |
| `0x48` | `m_position` | `Position : PackObj`, `PackObj` = `{ vfptr }` = 4 bytes (`acclient.h:26018`) |
| **`0x4c`** | **`m_position.objcell_id`** | `Position` = vfptr(4) + objcell_id(4) + `Frame`(64) = 72 (`acclient.h:30658`) |
| `0x90` | `cell` | `0x48 + 72` |
| `0xa8` | `state` | `cell`(4) + `num_shadow_objects`(4) + `DArray<CShadowObj>`(16); confirmed by the identical `[1] & 0x10` bit-test used against `this->state` in `enter_cell` |

`Frame` = `qw,qx,qy,qz`(16) + `m_fl2gv[9]`(36) + `m_fOrigin`(12) = 64
(`acclient.h:30647`). The chain closes exactly on `state == 0xa8`, so `+0x4c` is
`m_position.objcell_id` with no slack.

There is **no `CPhysicsObj::set_cell`**. `symbols.json` contains only
`CPhysicsObj::set_cell_id` and `CPhysicsObj::set_cell_id_recursive`. The
cell-transition entry point is `change_cell`.

---

## 1. Does a parent's cell change propagate to children?

**Yes. Two independent mechanisms, both on the physics path.**

### Mechanism A — the recursive cell walk (`change_cell` → `enter_cell`)

`CPhysicsObj::change_cell @0x00513390`:

```
0051339b  if (this->cell != 0)  leave_cell(this, 1)        @0x0051339f
005133aa  if (arg2 != 0)      { enter_cell(this, arg2); return; }  @0x005133af
005133c1  this->m_position.objcell_id = 0    // arg2 == 0 path only
005133d8  this->cell = nullptr
```

`change_cell` itself has no child loop. Both of its callees do.

`CPhysicsObj::enter_cell @0x00510ed0` — **recurses into children with the same
`CObjCell*`**:

```
00510ed8  if (this->part_array != 0) {
00510ee2      CObjCell::add_object(arg2, this)
00510eec      for (edi_1 = 0; edi_1 < children->num_objects; edi_1++)
00510f03          CPhysicsObj::enter_cell(this->children->objects.data[edi_1], arg2)   // RECURSION
00510f1b      id = arg2->m_DID.id
00510f1e      this->m_position.objcell_id = id                                          // WRITE
00510f2b      CPartArray::SetCellID(part_array, id)
00510f35      this->cell = arg2                                                          // WRITE
00510f3e      CPartArray::AddLightsToCell(part_array, arg2)
          }
```

Because `arg2` is passed down unchanged, every descendant receives the parent's
**exact** cell object and therefore the identical `objcell_id`. Each descendant
is also individually registered into the cell via `CObjCell::add_object`
`@0x00510ee2` on its own recursion frame — children are real members of the
cell's object list, not merely nominally re-tagged.

`CPhysicsObj::leave_cell @0x00510f50` mirrors it:

```
00510f5e  CObjCell::remove_object(cell, this)
00510f84  for each child: CPhysicsObj::leave_cell(child, arg2)    // RECURSION
00510fa7  this->cell = nullptr
```

Note `leave_cell` clears `cell` but does **not** zero `objcell_id`, on the
parent or on children. The stale id survives until `enter_cell` overwrites it.

**Caveat, cited:** `enter_cell` is gated on `this->part_array != 0`
`@0x00510ed8`. A child with a null `part_array` receives no cell write and its
own children are not visited. `leave_cell` has no such gate.

### Mechanism B — the explicit child loop in the motion commit

`CPhysicsObj::SetPositionInternal(CPhysicsObj*, CTransition const*)
@0x00515330` is the per-commit position write. It branches on whether the
`CObjCell` pointer changed:

```
0051534a  curr_cell = arg2->sphere_path.curr_cell
0051536d  if (this->cell == curr_cell) {                       // BRANCH A: same cell object
00515385      this->m_position.objcell_id = arg2->sphere_path.curr_pos.objcell_id
00515392      CPartArray::SetCellID(part_array, objcell_id)
0051539c      for (ebx_1 = 0; ebx_1 < this->children->num_objects; ebx_1++) {
005153ae          eax_2       = this->children->objects.data[ebx_1]
005153ba          objcell_id_1 = arg2->sphere_path.curr_pos.objcell_id
005153bd          *(uint32_t*)((char*)eax_2 + 0x4c) = objcell_id_1     // child->m_position.objcell_id
005153cc          CPartArray::SetCellID(eax_3 /* child +0x10 */, objcell_id_1)
              }
          } else
00515372      CPhysicsObj::change_cell(this, curr_cell)          // BRANCH B: → Mechanism A
005153e0  CPhysicsObj::set_frame(this, &arg2->sphere_path.curr_pos.frame)
```

So the child's `objcell_id` is re-stamped with the parent's on **every position
commit**, whether or not the `CObjCell` pointer changed. Branch A writes it
unconditionally — it does not test whether the value differs.

**Two precise asymmetries between the branches, both citable:**
- Branch A's loop is **flat, depth-1 only** (`@0x005153ae`–`@0x005153d8` reads
  `this->children` and writes `+0x4c` directly, with no recursive call).
  Mechanism A's `enter_cell` is fully recursive. Grandchildren are therefore
  refreshed only on a genuine cell-object change.
- Branch A writes only `objcell_id` (and the part array's copy), never the
  child's `cell` pointer. It does not need to: the parent's `CObjCell` is
  unchanged in that branch, and the children were already registered into it by
  `enter_cell`.

### The driving tick

`CPhysics::UseTime @0x00509950` → `CPhysicsObj::update_object @0x005099e5`
(`@0x00515d10`) → `CPhysicsObj::UpdateObjectInternal @0x005156b0` →
`SetPositionInternal(this, transition) @0x00515914`.

The decisive guard is the first thing `update_object` does:

```
00515d40  if (this->parent != 0 || this->cell == 0 || (this->state & 0x1000000) != 0) {
00515eeb      this->transient_state &= 0xffffff7f
00515ef5      return
          }
```

**A parented object is never independently simulated.** Its cell — and its frame
— come exclusively from its parent's tick. This is the structural reason the
propagation in Mechanism A/B must exist and must be unconditional.

---

## 2. What is a child's `objcell_id` while parented?

**The parent's, maintained eagerly and redundantly. Not zero, not independent.**

Write sites that set a child's `objcell_id` to the parent's value:

| Site | Address | Value written |
|---|---|---|
| `enter_cell` recursion frame | `@0x00510f1e` | `arg2->m_DID.id` — the parent's `CObjCell` id |
| `SetPositionInternal` branch A loop | `@0x005153bd` | `arg2->sphere_path.curr_pos.objcell_id` — the parent's committed id |
| `set_cell_id_recursive` | `@0x00510db1` | `arg2`, recursed to children `@0x00510de3` |

The child's copy is a genuine maintained mirror, not a derived read-through:
`CPhysicsObj` has exactly one `m_position` and the child's is written with the
parent's id at the sites above.

**`set_cell_id_recursive @0x00510da0` is not part of the parenting path.** A
whole-file grep for callers returns exactly one, `@0x00506eba`, which is sky
object handling (`this->sky_obj.m_data[i]`). It is cited here only to close it
out as a candidate — it is not the mechanism.

---

## 3. Where is a child's cell written?

**In `change_cell`/`enter_cell` and in the `SetPositionInternal` commit — i.e.
the physics path. `set_parent` participates only by calling `change_cell`; it
contains no cell write of its own.**

`CPhysicsObj::set_parent(CPhysicsObj*, uint32_t) @0x00515a90`, complete body:

```
00515a9d  if (edi != 0 && add_child(edi, this, arg3) != 0) {
00515aba      unset_parent(this)
00515ac1      leave_world(this)
00515ac6      this->parent = edi
00515ac9      cell = edi->cell
00515ad1      if (cell != 0) {
00515ad6          change_cell(this, cell)                       // <-- the only cell write, delegated
00515ae0          if (children_1 != 0 && CHILDLIST::FindChildIndex(children_1, this, &arg2) != 0) {
00515b0e              UpdateChild(edi, this, children->part_numbers.data[ecx_4], &children->frames.data[ecx_4])
00515b15              recalc_cross_cells(this)
                  }
              }
00515b26      if (this->parent->state[1] & 0x40) {
00515b28          this->state |= 0x20
00515b38          CPartArray::SetNoDrawInternal(part_array, 1)
              }
00515b45      return 1
          }
00515b4d  return 0
```

The four-arg overload `set_parent(CPhysicsObj*, uint32_t, Frame const*)
@0x00515b50` is identical in shape: `unset_parent @0x00515b7e`, `leave_world
@0x00515b85`, `this->parent = arg2 @0x00515b8a`, `change_cell(this, cell)
@0x00515b9a`, `UpdateChild @0x00515ba4`, `recalc_cross_cells @0x00515bab`, plus
`m_bExaminationObject` propagation `@0x00515b7b`.

Supporting facts:

- `CPhysicsObj::add_child @0x0050f870` (and the 4-arg form `@0x0050f8f0`) is
  pure list management — `CSetup::GetHoldingLocation @0x0050f896`, allocate
  `CHILDLIST` `@0x0050f8aa`, `CHILDLIST::add_child @0x0050f8d1`. **No cell or
  `objcell_id` write.**
- `CPhysicsObj::recalc_cross_cells @0x00515a30` recurses into children
  `@0x00515a79` but only calls `calc_cross_cells @0x00515a5c` (shadow/cross-cell
  registration) — it **reads** `this->m_position.objcell_id` as a guard
  `@0x00515a3f` and never writes it.
- **Prior finding CONFIRMED, not refuted:** `CPhysicsObj::UpdateChild
  @0x00512d50` composes a frame (`Frame::combine @0x00512d7d`) and calls
  `set_frame(arg2, &var_40) @0x00512d8d`, then ticks particles/scripts.
  `CPhysicsObj::set_frame @0x00514090` writes `m_position.frame` `@0x005140e9`,
  `CPartArray::SetFrame @0x00514101`, and `UpdateChildrenInternal @0x00514108`.
  **Neither touches `objcell_id` or `cell`.** The frame-only claim holds.

Per-commit ordering inside `SetPositionInternal`, worth having explicit:
cell propagation (branch A loop, or branch B `change_cell` → recursive
`enter_cell`) **first** `@0x00515372`/`@0x00515385`, then `set_frame`
`@0x005153e0` → `UpdateChildrenInternal @0x00514108` → per-child `UpdateChild`
→ `set_frame(child)`. Cell before frame, every commit.

---

## 4. What happens on `unset_parent`?

**The child gets no cell back. `unset_parent` performs zero cell work.**

`CPhysicsObj::unset_parent @0x00513470`, complete body:

```
00513473  parent = this->parent;  if (parent == 0) return              @0x00513478
00513484  CHILDLIST::remove_child(parent->children, this)
00513495  if (this->parent->state[1] & 0x40) {
00513497      this->state &= 0xffffffdf
005134a7      CPartArray::SetNoDrawInternal(part_array, 0)
          }
005134ac  this->parent = nullptr
005134bf  this->update_time = Timer::cur_time
005134ce  return CPhysicsObj::clear_transient_states(this)
```

No `cell`, no `objcell_id`, no `leave_cell`.
`CPhysicsObj::clear_transient_states @0x00511bf0` was read in full — it touches
only `transient_state`, `calc_acceleration @0x00511bfa`/`@0x00511c2b`, and
`MovementManager::LeaveGround @0x00511c24`. **No cell write.**

Consequently, immediately after `unset_parent` the child still holds the
parent's `objcell_id` **and** is still in that `CObjCell`'s object list. Every
call site resolves this itself, in one of two ways:

| Call site | Address | Resolution |
|---|---|---|
| `CPhysicsObj::set_parent` (both overloads) | `@0x00515aba`, `@0x00515b7e` | followed by `leave_world @0x00515ac1`/`@0x00515b85`, then `change_cell` to the new parent's cell |
| `SmartBox::DoPickupEvent @0x00452240` | `@0x0045227f` | followed by `leave_world @0x00452286` — leaves the world |
| `SmartBox::HandleReceivedPosition @0x00453fd0` | `@0x00454129` | followed by `SetPlacementFrame @0x00454142` and `MoveOrTeleport @0x00454254` — server-driven re-placement assigns a cell |
| `CObjectMaint::DeleteObject @0x00508460` | `@0x005084b2` | `exit_world @0x0050846b` + `leave_world @0x00508472` ran **before**; then `unparent_children @0x005084b9`, then destructor |
| `CObjectMaint::DestroyObjects @0x00508c30` | `@0x00508dd7` | same pattern, then `unparent_children @0x00508dde`, destructor |
| `ParticleEmitter::Destroy @0x0051cdb0` | `@0x0051cdbd` | followed by `leave_world @0x0051cdc5` |

`CPhysicsObj::leave_world @0x005155a0` is where a detaching child is actually
scrubbed: `remove_shadows_from_cells @0x005155dd`, `leave_cell(this, 0)
@0x005155e6` (which recurses children `@0x00510f84`), then
`this->m_position.objcell_id = 0 @0x005155f4` and `CPartArray::SetCellID(...,
0) @0x00515606`.

**One precise gap, stated as such:** `leave_world` zeroes only **its own**
`objcell_id` `@0x005155f4`. Its recursive `leave_cell` clears each descendant's
`cell` pointer `@0x00510fa7` but leaves each descendant's `objcell_id` at its
stale value. So a grandchild of a world-leaving object retains a stale
`objcell_id` with a null `cell` until the next `enter_cell`. This is retail's
actual behavior, not an artifact of the decomp — the write at `@0x005155f4` is
plainly on `this` and the recursion at `@0x00510f84` plainly does not carry an
id-clearing write.

---

## 5. Does retail have anything resembling acdream's per-render-tick child rebucket?

**Retail has a per-commit child cell re-stamp, but it is on the physics path,
not a render path, and it is unconditional.**

- **Name:** the child loop in `CPhysicsObj::SetPositionInternal(CPhysicsObj*,
  CTransition const*) @0x00515330`, at `@0x0051539c`–`@0x005153d8`.
- **Cadence:** once per position commit, driven by `CPhysics::UseTime
  @0x00509950` → `update_object @0x005099e5` → `UpdateObjectInternal
  @0x005156b0` → `SetPositionInternal @0x00515914`. Same tick that runs
  collision and movement — it is not tied to drawing, to pose composition, or to
  mesh/part availability.
- **The comparable acdream code** is
  `src/AcDream.App/Rendering/EquippedChildRenderController.cs:373` `TickChild`,
  whose `_liveEntities.RebucketLiveEntity(child.ChildGuid, parentCellId)` at
  line 407 writes the same **value** retail writes (child cell := parent cell),
  but reaches it only after `TryResolveExactAttachment`,
  `TryGetRootPose`, `TryGetPartPoseSnapshot`, and
  `EquippedChildAttachment.TryComposePoseInto` all succeed, and only after
  `ApplyParentWorldPose` returns true. Retail's equivalent write has no such
  predicates.

So retail's cell propagation is **gated on nothing except `part_array != 0`**
(Mechanism A) or **nothing at all** (Mechanism B), whereas acdream's is gated on
successful render-side pose composition. That gating is the divergence, and it
is exactly why headless — which never constructs
`EquippedChildRenderController` — leaves parented children cell-less forever.

---

## Direct consequence for route 7

The child cell write **belongs in Runtime**, and specifically it belongs in
*both* the `set_parent` analog *and* the position-commit analog — retail writes
it in both places, and `set_parent` is the lesser of the two.

Three consequences follow directly from the citations above:

1. **`set_parent` alone is insufficient.** Retail's `set_parent` performs no
   cell write of its own; it delegates one-shot placement to `change_cell
   @0x00515ad6`. The *sustaining* write — the one that keeps a child correct as
   its parent walks around — is `SetPositionInternal`'s child loop
   `@0x005153bd` and the recursive `enter_cell` `@0x00510f1e`, both on the
   physics commit. A Runtime `set_parent` analog that writes the cell once at
   attach time will be correct at attach and stale on the first parent cell
   crossing thereafter.

2. **The write is unconditional in retail and must be unconditional in
   Runtime.** Because `update_object @0x00515d10` early-returns on `parent != 0`
   `@0x00515d40`, a parented child has no tick of its own; the parent's commit
   is its only source of truth. Predicating the write on pose/mesh readiness —
   as `TickChild` does — has no retail counterpart.

3. **App's render-tick rebucket can be safely demoted**, because it writes a
   value Runtime already has at commit time (the parent's committed
   `objcell_id`) and needs none of the pose data it currently waits for. Its
   sole retail-justified residue is presentation
   (`child.Entity.ParentCellId`/`PublishChildPose`), not membership.

**One-line verdict:** route 7 can safely demote App's render-tick rebucket to
presentation-only, provided the Runtime replacement writes the child's cell at
*both* the `set_parent` analog and the per-commit position analog — retail does
both, and the per-commit one is the load-bearing half.

---

## NOT ESTABLISHED

Nothing in the five questions is unresolved. Two adjacent facts are deliberately
not claimed:

- **When branch A of `SetPositionInternal` can observe `curr_pos.objcell_id !=
  this->cell->m_DID.id`** (i.e. when the same `CObjCell` legitimately carries a
  changing `objcell_id`) is not established. It does not affect the answer —
  retail writes the child's id there unconditionally regardless — but if it
  matters later, the settling read is `CTransition`/`CSphere` `curr_cell`
  maintenance in `SPHEREPATH::set_curr_cell` plus outdoor `CObjCell` id
  assignment, or a cdb breakpoint on `CPhysicsObj::SetPositionInternal
  @0x00515330` logging `@ecx->cell->m_DID.id` against
  `arg2->sphere_path.curr_pos.objcell_id`.
- **Whether any parented child in practice has children of its own** (the case
  where branch A's depth-1 loop would leave a grandchild stale) is not
  established from the decomp. Settling it is a live-data question, not a code
  question: a cdb breakpoint on `CPhysicsObj::set_parent @0x00515a90` logging
  `@ecx->children` non-null at attach time would answer it.