WebUI ships a 2019 static EBX dump that is mostly dead or superseded (13MB ui.vuic, ~105MB parsed at boot)

[Powback]

Measured on branch live-ebx. Filing to track — not started.

What we ship

WebUI/public/data.zip is 9.7 MB of a 13 MB ui.vuic, and FrostbiteDataManager._ExtractFiles JSON.parses every file in it at boot:

File	Size	Dated	Feeds	Actually used?
Bundles.json	53 MB	2019-08	scope.bundles	No — see below
Partitions.json	52 MB	2019-08	scope.partitions / partitionGuids (70,093 FBPartitions)	Largely superseded
AssetHashes.json	1.6 MB	2020-11	nothing (_HandleFile default:)	No
EventHashes.json	706 KB	2020-11	nothing (_HandleFile default:)	No — but we want it, see below
InterfaceIDs.json	362 KB	2020-11	field declared, never populated	No
SuperBundles.json	61 KB	2019-08	superBundles	Yes

That's ~105 MB of JSON parsed on startup, inside the 32-bit game process. Given the Gameface app already costs ~400-500 MB against a ~4 GB address-space ceiling, this is a plausible contributor to the memory pressure that ME_CONFIG.LAZY_WEBUI exists to work around.

Why most of it is redundant now

Blueprints already come from the live game, not the dump:

-- ext/Client/Editor.lua:182
WebUpdater:AddUpdate('RegisterBlueprints', json.encode(InstanceParser.m_Blueprints))

blueprintManager holds 1,733 blueprints (what's actually loaded) vs 70,093 partitions in the 2019 dump. InstanceParser already builds m_Blueprints, m_BlueprintInstances, m_PrimaryInstances, m_LevelDatas, m_Variations, m_ObjectVariations, m_Meshes, m_MeshVariationDatabases from Partition:Loaded.

Partition contents are live too since the server-side PartitionSerializer landed, and ReferenceProperty now registers + fetches partitions on demand, so the WebUI already creates entries the static catalog doesn't have.

Bundles.json (53 MB) appears entirely dead. Its only consumers in FrostbiteDataManager:

• getBundle — return this.bundles[path] on a Dictionary, i.e. always undefined
• getBundlesReferencedIn — body fully commented out
• getPartitions — body fully commented out

The one thing we should KEEP and wire up

EventHashes.json is the field-id hash -> name table the connection editor needs. It is already shipped and already parsed — and then discarded, because _HandleFile has no case for it. Spot-checked against real connection field ids from Venice-EBX:

838548383   -> Geometry
2099208964  -> OnCaptured
1043301209  -> CaptureRadius
-2001390482 -> AlternativeSpawnPoints

19,704 entries, 706 KB (0.7% of the payload). Wiring it into PartitionSerializer:_EncodeField (or resolving WebUI-side) turns unreadable connection rows like SourceFieldId 838548383 into Geometry. This closes gap G6 in docs/entity-wiring-and-networking.md at zero payload cost.

Suggested work

1. Wire up EventHashes (+ AssetHashes / InterfaceIDs if useful) — small, immediate UX win.
2. Delete Bundles.json and its dead accessors. Verify nothing regresses (the accessors are already no-ops).
3. Investigate dropping Partitions.json. The open question: it is currently the only source of partition names for partitions that aren't loaded, and the Explorer path tree is built from names. Need to determine whether VEXT can enumerate unloaded partitions/bundles; if not, decide whether "browse only what's loaded" is acceptable, or keep a much smaller name-only index.

Expected result: ui.vuic 13 MB -> ~3 MB, and ~105 MB less JSON parsed at boot.

Related: #387 (dependency modernisation), docs/entity-wiring-and-networking.md (G6).