LANTERN purge: delete the superseded base/expedition shell (audit H1/H3/M5)
The 2026-08-06 audit found the shipping scene was still the abandoned co-op-Hades game with LANTERN combat bolted on, and that a third of the codebase was live code for a direction abandoned on 2026-07-13. Operator chose deletion over freezing: "everything is saved in source control if needed. I want the project to be clean." DELETED (~140 source files, Scripts 335->231, Tests 77->43): - Enemy variants + boss (H3). ChargerAuthoring / SpitterAuthoring / SwarmerAuthoring were attached to ZERO prefabs, so LungeState / SpitterState / SwarmerTag were never baked: ~272 lines of Bursted AI passes, BossAISystem (261 lines) and the whole MixBands escalation curve could not match a single chunk at runtime, while 734 lines of green tests certified them. Both shipping enemy prefabs were already byte-identical in stats. - Run/room lifecycle: RunDirector FSM, RunInfo/RunMap/RoomPlan/RoomTag, route select, portal interact, ready-check, room field/teardown. - Meta shop, prep loadout, boons (incl. KillRewardSystem and DashTrailDamageSystem, which existed only to serve boon flags). - Build palette + structures, shared storage, inventory/equipment (already recorded PAUSED in CLAUDE.md). - The HUD panels driving all of the above (HudSystem 1168 -> 610). KEPT deliberately: BaseGridMath + BaseAnchor (8 systems use PlotCenter for spawn rings, respawn and dynamic light), the resource ledger + StorageMath, the save system, region/relevancy. Three of these were in the delete set until I checked their consumers — worth remembering that the file-level manifest was wrong about them. Also folds in audit finding M5: PlayerClass was a second, server-only copy of the byte FrameId already replicates. It existed for the meta shop; with that gone, FrameId is the single frame identity. Harvest is now single-sink (ledger). HarvestMath keeps its shape so LANTERN's carried-vs-banked cargo split lands in one place, not two. 295/295 EditMode green, zero compile errors. Subscene re-bake and Play validation follow in the next commit. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -1,12 +0,0 @@
|
||||
using Unity.Entities;
|
||||
|
||||
namespace ProjectM.Simulation
|
||||
{
|
||||
/// <summary>
|
||||
/// Tag marking the shared home-base storage container. All state lives in the entity's
|
||||
/// <see cref="StorageEntry"/> buffer. In M5 there is exactly one (server-spawned at a fixed base
|
||||
/// cell), so server systems resolve it as a singleton. Server-authoritative and world-resident, so
|
||||
/// its contents survive a player disconnect (no disk persistence yet).
|
||||
/// </summary>
|
||||
public struct SharedStorageContainer : IComponentData { }
|
||||
}
|
||||
@@ -1,2 +0,0 @@
|
||||
fileFormatVersion: 2
|
||||
guid: 8de8d91f5d8f0a64c87b0847ae85c564
|
||||
@@ -1,33 +0,0 @@
|
||||
using Unity.NetCode;
|
||||
|
||||
namespace ProjectM.Simulation
|
||||
{
|
||||
/// <summary>
|
||||
/// Client -> server request to deposit into or withdraw from the shared storage container. A one-off
|
||||
/// action, so it is an RPC (not a per-tick predicted input). Op is stored as a byte (see
|
||||
/// <see cref="StorageOp"/>) rather than an enum to keep the generated serializer trivial and avoid the
|
||||
/// cross-assembly enum-codegen hazard. No target entity is carried: M5 has a single shared container,
|
||||
/// which the server resolves as a singleton (entity refs are not stable across worlds).
|
||||
/// </summary>
|
||||
public struct StorageOpRequest : IRpcCommand
|
||||
{
|
||||
/// <summary>Operation code (see <see cref="StorageOp"/>): 0 = deposit, 1 = withdraw.</summary>
|
||||
public byte Op;
|
||||
|
||||
/// <summary>Item to deposit/withdraw.</summary>
|
||||
public ushort ItemId;
|
||||
|
||||
/// <summary>Quantity to deposit/withdraw (server clamps withdraw to available).</summary>
|
||||
public int Count;
|
||||
}
|
||||
|
||||
/// <summary>Operation codes for <see cref="StorageOpRequest.Op"/> (byte to keep RPC serialization trivial).</summary>
|
||||
public static class StorageOp
|
||||
{
|
||||
/// <summary>Add items to the shared container.</summary>
|
||||
public const byte Deposit = 0;
|
||||
|
||||
/// <summary>Remove items from the shared container.</summary>
|
||||
public const byte Withdraw = 1;
|
||||
}
|
||||
}
|
||||
@@ -1,2 +0,0 @@
|
||||
fileFormatVersion: 2
|
||||
guid: dc9ec88867d746e45b9204331b5bab51
|
||||
@@ -1,20 +0,0 @@
|
||||
using Unity.Entities;
|
||||
using Unity.Mathematics;
|
||||
|
||||
namespace ProjectM.Simulation
|
||||
{
|
||||
/// <summary>
|
||||
/// Singleton baked into the gameplay subscene, holding the baked storage-container ghost prefab and
|
||||
/// the base-grid cell to spawn it at. A one-shot server system instantiates the prefab at
|
||||
/// BaseGridMath.CellToWorld(anchor, Cell) and then destroys this singleton. Mirrors the
|
||||
/// UpgradePickupSpawner / PlayerSpawner pattern.
|
||||
/// </summary>
|
||||
public struct StorageSpawner : IComponentData
|
||||
{
|
||||
/// <summary>Baked storage-container ghost prefab to instantiate.</summary>
|
||||
public Entity Prefab;
|
||||
|
||||
/// <summary>Base-grid cell at which to place the container (cell center, on the base plane).</summary>
|
||||
public int2 Cell;
|
||||
}
|
||||
}
|
||||
@@ -1,2 +0,0 @@
|
||||
fileFormatVersion: 2
|
||||
guid: 6a2e4fad83fa03b4890d736b388a9917
|
||||
Reference in New Issue
Block a user