destiny-2-Sunrise/MISSION_EMBER_PLAN.md

1AU / mission_ember implementation plan

Prepared 2026-09-04. Scope: restore the complete mission through Lua using the installed generated SDK, with package-backed identifiers and authored resources.

Evidence reviewed

• Reference video: https://www.youtube.com/watch?v=PqurUhqC2CE — The Videogame Library, “Destiny 2 (Xbox One) The Red War: Mission 16 - 1AU (No Commentary Longplay)”, duration 36:42. Reviewed all nine available storyboard sheets, sampling the timeline every ten seconds. This establishes broad visual order; it is not continuous playback or an audio review. Exact dialogue timing, brief interactions and damage timings remain to be verified. The recording begins in gameplay and includes subsequent story cinematics and a later mission launch; those are not all necessarily controlled by Ember.
• Generated mission: /home/millie/Games/Sunrise/bin/x64/Sunrise/sdk/lua/missions/mission_ember_80b3c09e.lua.
• Campaign activity: mission_ember_38f926b2.lua, display name 1AU, activity index 281. Daily Heroic variant: mission_ember_231dd291.lua, index 54. Both point to activity root 0x80B3C07D and scenario 0x80B3C09E.
• SDK manifest: schema sunrise-activity-sdk-v8, format 37, build ID sha256:26b80ec22191c2f87d9079ef1dc90707cf26b10e5299962304aac4e7a9e8c47a.
• Installed packages: /home/millie/Games/Sunrise/packages. Read package directories and checked 154 distinct content references from the mission's slot IDs and content-tag fields: all resolved to nonempty entries across nine package families. This verifies presence, not complete semantic decoding of each payload. Runtime schema constants were excluded from the content-reference check.
• Primary family: w64_cabal_ship_activities_019e_{0,1,2,3,5}.pkg, with 8,192 directory entries in the latest installed directory. Root entry: 72 bytes; scenario entry: 1,773 bytes.
• Scenario SDK pack: sdk/scenarios/80B3C09E-446ac6892dd45476cc8b91f8e3a654d92b14eaa6ed4d272f14e93cc43a927082.pack.
• Lua references: sibling SunriseMissions, especially lib/mission_lib.lua and the regional dispatch in tangled_shore_freeroam.lua. Its README describes the examples as WIP, so each pattern needs checking against this branch's runtime.

What the generated SDK already contains

Resource	Count / finding
State records	8; effective region indices 0, 1, 2, 40, 48, 49, 56, 64
Named slots	2,051
Squad sensors / richer squad definitions	162 / 31
Device sensors	69
Objective sensors / directive entries	28 / 26
Player trigger sensors / trigger volumes	127 / 211
Scenes / sequence sensors / cinematic sensors	10 / 9 / 3
Dialogue cue selectors	55; definition mappings exist for a subset
Task targets / performance states	Both generated tables are empty

Specific assets include sunburn_damage_object, security_placed_interceptor_object, bridge machinery, east/west reactor clamshell devices and damage sensors, the coffin damage sensor, reactor shield, explosion scenes, escape ship and three cinematic bookend sensors. Directive descriptions explicitly identify the grinder, solar-exposure cover mechanic, bridge controls, energy stream, Interceptor, cooling vents, fusion cell and escape.

These findings support an SDK-first implementation. They do not yet prove every required runtime operation works. In particular, the difference between squad sensors and richer squad definitions must be explained before choosing how each encounter is activated. An empty task table means we cannot assume an advance_task target exists for every objective.

Implementation sequence

1. Build the mission mapping and prove the SDK bindings.

   • Create a stage table mapping each encounter to its owning region/state, entry and exit triggers, squads, devices, objective/directive, dialogue cues, scenes and reset behavior.
   • Use stable generated identifiers. Distinguish identical display names with different slot identities. State values are all zero here: use their region-qualified identities rather than treating the values as global phase IDs.
   • Trace ambiguous mappings through the SDK catalog/scenario data and targeted package payloads. Determine whether squads absent from the richer table are scene-owned, activated through existing sensor state, or need an SDK export correction.
   • Verify the generated module, branch runtime and installed runtime agree. Exercise the existing APIs for state selection, squad placement, device transitions, triggers, directives, dialogue, cinematics and lifetime state.
   • Deliverable: an encounter map with confirmed bindings and an explicit list of unresolved operations.

2. Implement and test the opening encounter as a complete slice.

   • Add scripts/mission_ember.lua and focused modules under scripts/mission_ember/; include the required shared helpers in the same deployable tree.
   • Bind the campaign activity first. Resolve the correct entry state, publish its entities, activate its encounter and show its authored directive.
   • Prove an actual player trigger, a combat completion condition, the first gate transition and the following region load.
   • Handle duplicate events, death/reset and region re-entry before expanding the controller.
   • Exit criterion: launch, play the first encounter, progress, reset and replay without manual entity spawning or forced phase advancement.

3. Implement the traversal and combat sequence in order.

| Section | Required behavior | | --- | --- | | Opening / mineral processing | Correct combat groups, entrances/exits, navigation, objectives and dialogue; determine any launch bookend from package ownership. | | Ore tunnels and grinder | Investigation and activation interaction, defend while clearing the obstruction, completion gate and onward route. | | Sunlit deck | Enable the authored solar hazard and cover behavior; activate the correct encounters and remove section-specific effects on exit/reset. | | Interior chambers and machinery | Encounter waves, moving devices, doors, bridge controls and region transitions. Confirm the exact placement of each bridge against trigger ownership. | | Fuel stream and Interceptor route | Energy-stream traversal, vehicle availability/boarding, enemy placement and the transition into the reactor section. | | Reactor sabotage | East/west vent exposure and destruction, linked objectives and scenes, subsequent core/fusion-cell interaction, shield and route changes. Confirm authored ordering and thresholds from data. | | Escape | Explosion sequence, navigation to the getaway ship, escape trigger, terminal mission state and the relevant cinematic handoff. |

• Progress from actual trigger, interaction, damage, squad and scene events. Use timers where supported by authored behavior; do not copy this player's video duration into encounter gates.
• Distinguish stage entry from stage resume. Only activate entities belonging to the appropriate loaded region.
• Exit criterion for each section: it can be reached naturally, completed and replayed after failure.

1. Complete presentation and mission lifecycle behavior.

   • Pair each directive and dialogue cue with its actual event; handle alternate cues and avoid repeating one-shot lines on re-entry.
   • Restore sequences, music transitions, destruction scenes and cinematic start/termination handling using existing SDK surfaces.
   • Establish which ending scenes belong to Ember and which belong to campaign progression. Do not launch the later mission merely because it appears at the end of the video.
   • Verify completion is recorded by the supported activity/campaign path, with expected rewards and subsequent progression where applicable. A final Lua phase or a cinematic alone is not proof of completion.

2. Make recovery and repeated play reliable.

   • Implement the authored checkpoint/wipe behavior using the available runtime state and sensors; first confirm which state survives death, region transit and script reload.
   • Reset devices, hazards, damage targets, objectives, vehicles, encounter state and timers to the checkpoint's expected state.
   • Guard one-shot actions against duplicate/stale events. Keep regional timers and callbacks tied to the region that owns them.
   • Test backtracking, rapid trigger crossings, repeated interaction, death during animations, vehicle loss and escape failure.
   • Verify fireteam synchronization and late joins if supported by the mission's intended play mode. Test the Daily Heroic binding after campaign behavior is stable.

3. Validate the complete mission.

   • Check Lua loading and every referenced SDK symbol before deployment.
   • Add focused event-sequence checks for progression, duplicate events, reset and terminal completion where the available harness supports them.
   • Play from a fresh launch through the ending, with no developer intervention. Compare encounters, objectives, hazards, vehicle section and cinematics with the reference.
   • Repeat with checkpoint deaths and a fresh second launch. Review runtime logs for unresolved references, rejected operations, stale handles and missed transitions.
   • Record any remaining behavior differences explicitly. Completion requires functional gameplay and lifecycle behavior, not just reaching the final room.

Working approach

Keep authored Lua in the mission-ember branch and use the installed SDK as generated input. Start with its existing capabilities. Make a targeted runtime/export fix only after a concrete required operation is shown to be unavailable or broken. Initial work should produce the encounter map and playable opening; the full mission then grows section by section using that verified approach.

No gameplay code, installed game files or runtime settings were changed during this planning pass.