Sequence System (Devil Glitch)

Flow for event scene changes:

setNextStage called by dStage_changeScene4Event
dStage_changeScene4Event called by dEvt_control_c::sceneChange
dEvt_control_c::sceneChange called by 6 possible points from dEvent_manager_c::Sequencer
Sequencer can only call sceneChange when dEvDtEvent_c::finishCheck returns true, see: https://pastebin.com/1UkPrBUh (by default getting past finishCheck even with no additional flags set away from the default you get a sceneChange to the next event in the chain)
Sequencer called by dEvt_control_c::Step (every frame only when an event is active)
Step is executed every single frame at the end of d_s_play::dScnPly_Execute regardless if an event is active


Skip (Start twice pressed):

sceneChange is called from 0x800472f4 (3rd point in Sequencer) repeatedly until load starts


Normal End:
Abort (presumably due missing cutscene arc archive due wrong state):

sceneChange is called from 0x80047310 (4th point in Sequencer) repeatedly until load starts


Finish Check:
dEvDtEvent_c::finishCheck(), see: https://pastebin.com/39j0WAGS

finishCheck returns true if any of the 3 flag offsets stored at dEvDtEvent_c + 0x88-0x90 is -1 (not used?) when checked or if all the flags that are in use (g_dComIfG_gameInfo + 0x51B4 + (bit)flagOffset) are ON
dEvDtEvent_c address comes from (0x800474bc)getEventData(dEvent_manager_c,*(short *)(dEvent_manager_c + 0x1aa));

(0x80043efc)dEvDtEvent_c::forceFinish (only called from 0x80042c40 Step) is used to set all 3 flags at dEvDtEvent_c + 0x88-0x90 to true as long as they exist (not -1)
Cutscene skips (Start twice pressed) aka dEvt_control_c::skipper trigger forceFinish (unlikely Devil Glitch or anything else triggers it)

Event flags including finish flags are stored at 0x8040B374 (4 bytes) (e.g. bits 14-19 from right can be used as finish flags, starting at 0)

The abort due missing cutscene arc archive due wrong state is caused by the finish flag at 0x8040B374 (+ bit offset) being set to ON (by 0x80043dc8 dEvDtFlag_c::flagSet)
Error seemingly makes the event system "jump to the last cut" in the event which triggers the exit load to the next cutscene and thus sets the finish flag "naturally"

Demo Arc (STB data) load flow:
1. Loads Demo Arc Stb data: Step -> Experts -> specialStaffProc -> specialProc -> specialProcPackage -> dEvt_control_c::getStbDemoData
2. Check if current Stage has a Demo arc string set (0x80043340), fails on wrong state as it's not set to an arc name
3. Res is never loaded as a result, jumps to 0x80043378 (empty/removed debug message)
4. Function getStbDemoData returns with 0 instead of a valid arc archive ptr
5. d_demo::dDemo_c::start is triggered with the empty pointer and fails
6. As a result dDemo_c::m_mode is never set 1 (active) at 0x80039cb4
7. This causes a mode != 0 check in specialProcPackage at 0x80045abc to fail which triggers dEvent_manager_c::cutEnd using the staff ID of the PACKAGE chunk (ID 3 in ZD Meteor case) which cancels the cutscene early by jumping to the last cut
8. Orders Staff event: Step -> Sequencer -> advanceCut -> advanceCutLocal -> dEvDtStaff_c::advanceCut
9. Executes Staff event: Chain is Step -> Experts -> specialStaffProc -> specialProc -> specialProcPackage -> specialProc_WaitProc -> cutEnd -> flagSet

Leads:
-"Devil Glitch like cs skips" can likely only be caused by calling cutEnd from within specialProcPackage, several paths lead to it
-StageDemoArcName is always reset by d_stage::dStage_Create FIRST
-All broken cutscenes of Ben and Devil use State 8

Likely theory for Devil Glitch:
dEvt_control_c::getStbDemoData succeeds, but d_demo::dDemo_c::start still fails at the parse_next step for the Stb data blocks. Otherwise the cutscene would have started and you don't get the same visual with the camera behind Link. Except this time the failure is not because of the missing Stb data, but because parsing a specific Stb block failed. This could be due some other actor needed for the cutscene having failed to spawn or having an invalid property causing an abort. If any parsing step returns with false, parse_next fails as a whole immediately which in turn makes dDemo_c::start fail leading to the same abort as with a missing demo stb arc file.

Stb data block parsing:
One specific chain known to cause failure is that of a Stb block making use of a stage/room actor that hasn't spawned properly. Such as sequences trying to use the Horse (Epona) actor when Epona is locked. Stb block parsing also performs validation for some of the blocks.

Ilya cs in the Ordon spring fails when Epona isn't available. The chain that leads to failure is:
1. dDemo_c::start
2. JGadget::binary::TParse_header_block::parse_next. Parses header successfully, then loop parses the blocks
3. JStudio::stb::TParse::parseBlock_next (8028978c) ---> JStudio::TParse::parseBlock_block (802857e4) ---> Branches to...
4. Studio::stb::TParse::parseBlock_block (802897e8) ---> JStudio::stb::TParse::parseBlock_object (80289820). Object = stb object
5. JStudio::TFactory::create (802855ac). Tries to create a new memory stb object from a stb data block which ends up failing. First call goes to...
6. JStudio_JStage::TCreateObject::create (80289b60). First function called from TFactory:create which already fails. Attempts to create a reference to an existing Stage/Room actor (Horse in this case). A JSG object is created first, then the actor is looked up to connect it. Other TFactory::create functions afterwards fail too as a result (e.g. JAudio2, JParticle and d_demo::jstudio_tCreateObject_message::create)
7. d_demo::dDemo_system_c::JSGFindObject (80039528). Fails looking up Epona via fopAcM_searchFromName("Horse") since she was never spawned. This results in final failure and returning 1. In the case of a demo specific actor shipped with the demo arc file, e.g. "d_actX", this failure is handled/expected and the actor is spawned in return. Failing to spawn it however would also result in an abort
8. JStudio_JStage::TCreateObject::create fails as a result returning 0. This causes an abort chain and eventual cutscene abort

There are likely many other ways a block parse can fail. Devil Glitch most likely is caused by a block that relies on outside data to work, as the stb data should be consistent and static. Perhaps some of the JSG functions are the cause.

Currently known failure routes:
-STB file wasn't loaded due wrong state for the cutscene (mDemoArcName wasn't set to the right arc file or was empty)
-STB file wasn't loaded due not enough memory
-An actor referenced by the STB from the stage/room (e.g. Link/Midna/Horse) wasn't spawned properly (e.g. due not enough memory or a specific flag or because the actor got unloaded before)
-A demo specific actor "d_actX" couldn't get spawned (with fopAcM_fastCreate) due not enough memory (maybe they can be unloaded too?)

Actors needed for starting Meteor cutscene (inside) (failed):
Link, Midna, d_act0-d_act4

Actors needed for starting the second Meteor cutscene (outside) (worked):
d_act0-d_act2, d_act4, d_act5

Actors needed for starting the final Meteor cutscene (inside) (worked):
Link, Midna, d_act0-d_act1

Actors needed for starting Ilya cutscene in Ordon Spring (failed):
Link, Horse, d_act0-d_act14

Actors needed for starting the Zelda 1 cutscene (worked):
Link, Midna, d_act0-d_act1, 15

Actors needed for starting Hyrule Castle overtaken cutscene (failed):
Link, d_act0-d_act4, d_act7, 8, 9, 10, 12, 13, 14, 15, 16, 17, 18, 19, 28

Conclusion:
A permanent break of d_act3 could result in Devil/Ben glitch, even if unlikely to happen

Theory 2 (unlikely): For some reason d_s_room::loadDemoArchive didn't get called or failed to load arc res. Or dRes_control_c::syncRes in objectSetCheck failed. Or dEvent_manager_c::demoInit failed
This failure state is logged in the Event System via OSReport (maybe hook it so we can see those logs in real time?)

Other unlikely theories:
-The area state wasn't 8 as it should be (highly unlikely due state override)
-Event Some State ID at 0x8040B16C (1 byte) was set to 0 for 1 frame when the cs started, then set back to 2 properly. This would cause dEvent_manager_c::getMyStaffId and getIsAddvance to fail and the cs to skip ahead (unlikely)
-Event Manager IsAdvance1 at 0x8040B362 (2 bytes) was set to -1 which could cause failure in getIsAddvance (unlikely)
-Event Manager IsAdvance2 at 0x8040B36C (4 bytes) was set wrong so getIsAddvance would return 0 for 1 frame (unlikely)
-specialProcPackage gets never called with a PLAY instruction, resulting in no Stb data being loaded (unlikely)
-A memory allocation fail during parse_next in dDemo_c::start (unlikely)
-dDemo_c::m_mode was somehow 2 at some point (unlikely)
-dEvent_manager_c::getMySubstanceP at 0x8004595c returned a bad FileName for getStbDemoData (very unlikely)
-dRes_control_c::getRes in getStbDemoData failed (very unlikely, unless actor was previously unloaded)


Aborts like Devil Glitch could also get caused by all 3 flag offsets stored at dEvDtEvent_c + 0x88-0x90 to start out at -1 due corruption/error (rather unlikely)