7a0f836af5
Campaign P Slice P4 Opus review verdict: FIX-FIRST. RestrictionObjPrevalenceInspectionTests
(commit 3b5e0992) found 103,766 of 729,888 installed EnvCells (1,293 landblocks -
the whole housing estate) carry a baked RestrictionObj. The AP-71 gate's
unconditional fail-closed default (CanMoveInto unmodeled) would have locked
every apartment/cottage/villa interior for every player, including its own
owner - a live regression, not the "inert in dev content" the original
register row assumed.
Ports ACCWeenieObject::CanMoveInto (0x0058da40, pc:407982-408056) and
RestrictionDB::IsAllowedIn (0x005ae8f0, pc:444493-444516) verbatim into
ObjectInfo.CheckEntryRestrictions:
- owner_iid == 0 or == mover's own guid -> admit (open/owner)
- no RestrictionDB (retail _db == 0, i.e. never authored or not yet
received) -> admit
- present RestrictionDB -> IsAllowedIn: open-to-public flag, OR mover
shares the house's allegiance monarch, OR mover's own guid is a
guest-table member
- unresolved restriction object -> fails CLOSED, exactly retail's own
fallback when GetObjectA can't resolve it (pc:704-716)
Wire feed (Core.Net):
- CreateObject.cs: HouseOwner (WeenieHeaderFlag 0x02000000), HouseRestrictions
(0x04000000), and Monarch (0x40) PWD-tail fields were parsed-and-skipped;
now captured. Also fixes the HouseRestrictions PHashTable header
misconception: the wire is ONE packed u32 (low 24 bits = entry count),
not a separate count(u16)+numBuckets(u16) pair - verified against
Chorizite's RestrictionDB.generated.cs. The old skip's byte-count
happened to match for realistic guest-list sizes, but a future
numBuckets value >255 would have corrupted the parse; now correct
regardless.
- GameEvents.cs/GameEventWiring.cs: new House_UpdateRestrictions (0x0248)
parser + wiring - retail's live guest-list refresh, whole-unit replace.
No-ops if the house object hasn't arrived via CreateObject yet.
- ClientObject/WeenieData/ClientObjectTable: HouseOwnerId, MonarchId,
Restrictions (new HouseRestrictionRecord) fields + merge-preserving
Ingest + targeted UpdateHouseRestrictions.
Physics wiring:
- PhysicsEngine gains an Objects (ClientObjectTable?) property, mirroring
the existing DataCache pattern - acdream's GetObjectA equivalent, used
ONLY by the entry-restriction gate.
- RuntimeEntityObjectLifetime wires Physics.Engine.Objects = Objects in
all three constructors, right alongside the table's own construction -
the same canonical table every other subsystem borrows from, never a
second one. This is the production fix: without it the gate still fails
closed on every restricted cell (unresolvable object), so the wiring is
load-bearing, not cosmetic.
Register: AP-129 narrowed (not retired) to the genuine remaining residual -
House_UpdateRestrictions' Sequence byte isn't used for staleness/reordering
rejection (low-probability, self-correcting), and outdoor CLandCell
restriction (a separate DAT structure) remains unported and unaffected by
this fix.
Tests: 15 new/updated in Ap71EntryRestrictionGateTests.cs (resolved-unowned
admits, owner admits, present-list-excluded blocks, present-list-included
admits, open-to-public admits, shared-allegiance-monarch admits, unresolved
blocks via null and via an empty table, plus two new end-to-end
PhysicsEngine.Objects-wired scenarios); 2 new CreateObject parser tests +
2 new GameEventWiring tests for the wire feed.
AcDream.Core.Tests: 4049 passed, 2 skipped, 0 failed.
AcDream.Core.Net.Tests: 761 passed, 0 skipped, 0 failed.
Complete solution suite: 9,961 total, 9,956 passed, 5 skipped, 0 failed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
44 lines
2.2 KiB
C#
44 lines
2.2 KiB
C#
using System.Collections.Generic;
|
|
|
|
namespace AcDream.Core.Items;
|
|
|
|
/// <summary>
|
|
/// AP-129 (Campaign P Slice P4 review fix, 2026-07-30). Retail
|
|
/// <c>RestrictionDB</c> — the access-control list carried on a house/dwelling
|
|
/// object's <c>PublicWeenieDesc</c> (<c>WeenieHeaderFlag.HouseRestrictions</c>,
|
|
/// 0x04000000) and refreshed live via <c>House_UpdateRestrictions (0x0248)</c>.
|
|
/// Wire shape confirmed verbatim against
|
|
/// <c>references/Chorizite.ACProtocol/Chorizite.ACProtocol/Types/RestrictionDB.generated.cs</c>
|
|
/// and <c>protocol.xml:6270-6275</c>: <c>uint Version, uint Flags (0=private,
|
|
/// 1=open), ObjectId MonarchId, PHashTable<ObjectId,uint> Permissions</c>.
|
|
/// </summary>
|
|
/// <param name="OpenToPublic">Wire <c>Flags != 0</c> — retail's <c>_bitmask
|
|
/// & 1</c>. When true, every mover is admitted regardless of the guest
|
|
/// list.</param>
|
|
/// <param name="AllegianceMonarchId">Wire <c>MonarchId</c> — retail
|
|
/// <c>_monarch_iid</c>. A mover whose own monarch matches this id is admitted
|
|
/// (allegiance-wide access), independent of the guest list.</param>
|
|
/// <param name="Guests">Wire <c>Permissions</c> — guid to permission value
|
|
/// (0 = dwelling access only, 1 = storage access also). Retail's
|
|
/// <c>IsAllowedIn</c> only consults key membership for entry; the permission
|
|
/// value is preserved for wire fidelity but not consulted here.</param>
|
|
public sealed record HouseRestrictionRecord(
|
|
bool OpenToPublic,
|
|
uint AllegianceMonarchId,
|
|
IReadOnlyDictionary<uint, uint> Guests)
|
|
{
|
|
/// <summary>
|
|
/// Verbatim port of retail <c>RestrictionDB::IsAllowedIn</c>
|
|
/// (named-retail pc:444493-444516, 0x005ae8f0):
|
|
/// <c>if ((_bitmask & 1) == 0) { if (_monarch_iid == 0 || arg3 !=
|
|
/// _monarch_iid) { if (arg2 == 0) return 0; if (!table.find(arg2)) return
|
|
/// 0; } } return 1;</c> — open bit set, OR mover shares the house's
|
|
/// allegiance monarch, OR mover's own guid is a table member.
|
|
/// </summary>
|
|
public bool IsAllowedIn(uint moverId, uint moverMonarchId)
|
|
{
|
|
if (OpenToPublic) return true;
|
|
if (AllegianceMonarchId != 0 && moverMonarchId == AllegianceMonarchId) return true;
|
|
return moverId != 0 && Guests.ContainsKey(moverId);
|
|
}
|
|
}
|