Initial Findings

Initial Findings - Prospect Blob Structure

File Format

The prospect blob is base64-encoded, zlib-compressed binary data containing UE4 serialized properties. The format follows the standard UE4 GVAS property serialization convention.

Sample file: live-AAA-Icarus-Olympus.json - Compressed: 1.6 MB - Decompressed: 34.4 MB - SHA-1 hash is stored but does NOT match the compressed data (possibly hashed differently)

Top-Level Structure

The blob contains 6 top-level properties:

  1. StateRecorderBlobs (ArrayProperty) - 4,826 elements
  2. Version (IntProperty)
  3. LobbyPrivacy (EnumProperty)
  4. ProspectInfo (StructProperty) - duplicate of the JSON-level ProspectInfo
  5. ProspectMapName (StrProperty) - e.g., "Terrain_016"
  6. LastSavedDateTime (StructProperty/DateTime)

Actor/Component Types

Each element in StateRecorderBlobs is a "state recorder blob" representing a game entity. The 4,826 actors break down as:

Count Component Type Description
2,056 VoxelRecorderComponent Terrain modifications (mining, etc.)
898 DeployableRecorderComponent Placed items/deployables
644 ResourceDepositRecorderComponent Resource nodes
320 SplineRecorderComponent Spline-based structures
161 BuildingGridRecorderComponent Building grids
142 CaveAIRecorderComponent Cave creature AI state
128 CaveEntranceRecorderComponent Cave entrance state
125 SpawnedVoxelRecorderComponent Spawned terrain chunks
106 FLODTileRecorderComponent Level-of-detail tiles
69 CropPlotRecorderComponent Crop plots
30 IcarusMountCharacterRecorderComponent Tamed mounts!
28 BedRecorderComponent Beds/respawn points
21 EnzymeGeyserRecorderComponent Enzyme geysers
17 DrillRecorderComponent Mining drills
10 ActorStateRecorderComponent Generic actor state
9 SignRecorderComponent Signs
8 CharacterTrapRecorderComponent Traps
7 DynamicRocketSpawnRecorderComponent Rocket spawn points
7 RocketRecorderComponent Rockets
7 IcarusQuestRecorderComponent Quest state
6 PlayerRecorderComponent Player state
6 PlayerStateRecorderComponent Player state (alt)
5 PrebuiltStructureRecorderComponent Pre-built structures
4 PaintingRecorderComponent Paintings
1 InstancedLevelRecorderComponent Level instances
1 BaseLevelTeleportRecorderComponent Teleport points
1 GameModeStateRecorderComponent Game mode state
1 MapManagerRecorderComponent Map manager
1 WeatherForecastRecorderComponent Weather forecast
1 WeatherControllerRecorderComponent Weather controller
1 WorldBossManagerRecorderComponent World boss state
1 FLODRecorderComponent LOD system
1 IcarusContainerManagerRecorderComponent Container manager
1 IcarusQuestManagerRecorderComponent Quest manager
1 WorldTalentManagerRecorderComponent World talent state
1 PlayerHistoryRecorderComponent Player history

Per-Actor Structure

Each actor typically contains: - ComponentClassName (StrProperty) - e.g., "/Script/Icarus.VoxelRecorderComponent" - BinaryData (ArrayProperty) - sub-blob of raw bytes (the actual component-specific serialized state data) - Various game properties depending on the component type: - Completions, HordeDTKey, ActorStateRecorderVersion - ActorTransform (Transform with Rotation, Translation, Scale3D) - SavedInventories, FLODComponentData - ActorClassName, ActorPathName, OwnerResolvePolicy - And many more...

Key Observations

  1. The BinaryData fields within each actor are ANOTHER layer of binary data. These are raw byte arrays that likely need their own parsing (possibly more UE4 properties, or component-specific binary formats).

  2. Mount data (IcarusMountCharacterRecorderComponent) appears 30 times - this matches what we'd expect for tamed mounts on an outpost.

  3. The format is fully standard UE4 property serialization - no custom binary format, just nested properties all the way down.

  4. Voxel data dominates - 2,056 voxel records represent terrain modifications (mining, building on terrain, etc.).

Campaign / World State

The "irreversible" campaign changes are stored in three key components:

1. IcarusQuestManagerRecorderComponent (Actor 31)

The active campaign/faction mission: - FactionMissionName: "OLY_Glacier_Expedition" - Current campaign mission - bMissionComplete: False - Whether the mission is done - bRunQuests: True - Whether quests are active - DynamicMissionProspectName: "Tier2_Glacier_Expedition_0" - InitialQuestRecord.QuestActorName: "BPQ_Glacier_OLY_Expedition_C"

2. WorldTalentManagerRecorderComponent (Actor 32) ⭐

This is the key one. Contains WorldTalentRecords - persistent world buffs/changes that cannot be undone through normal gameplay:

Index RowName Rank Notes
0 GH_RG_A 1 Rock Golem talent A
1 GH_RG_B 1 Rock Golem talent B
2 GH_RG_C 1 Rock Golem talent C
3 GH_RG_C2 1 Rock Golem talent C2
4 GH_RG_O2 1 Rock Golem optional 2
5 GH_RG_O1 1 Rock Golem optional 1
6 GH_RG_Final 1 Rock Golem final

"GH_RG" likely = "Garrison Hub Rock Golem" - world talents from the Rock Golem world boss. The row names likely correspond to entries in a data table from data.pak.

3. IcarusQuestRecorderComponent (7 instances)

Individual quest state actors: - OLY_Glacier_Expedition - Main campaign quest - OLY_Glacier_Expedition_Collect_0/1/2 - Collection sub-quests - Common_Travel (×2) - Travel quests

4. PlayerHistoryRecorderComponent (Actor 33)

Tracks which players have visited this outpost (6 players recorded).

Modifying Campaign State

To "reset" irreversible changes, you would likely need to: 1. Clear or modify the WorldTalentRecords array in WorldTalentManagerRecorderComponent 2. Reset bMissionComplete and quest state in IcarusQuestManagerRecorderComponent 3. Remove completed quest actors (IcarusQuestRecorderComponent entries) 4. Recompress and re-encode the blob

Next Steps

  • [ ] Cross-reference GH_RG_* row names with data.pak data tables
  • [ ] Parse BinaryData blobs for other component types (mounts, deployables)
  • [ ] Test modifying WorldTalentRecords and reloading
  • [ ] Compare pre/post-campaign save files to confirm theory
  • [ ] Build a save file editor
Back to Docs