dragonbane

Save Location (Adam Glitch)

Jan 1st, 2020
203
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 3.01 KB | None | 0 0
  1. Flow:
  2. 1. d_stage::dStage_playerInit (player spawned, always) ---> dStage_startStage_c::set ---> updates 0x8040afc0 = Current Stage Name
  3. 2. A d_a_kytag14 is injected into the map for each Savmem that exists
  4. 3. d_a_kytag14:daKytag14_Execute updates the current savefile location every frame via dSv_player_return_place_c::set
  5. 0x80406218 Save Stage = 0x8040afc0 Current Stage Name
  6. 0x80406221 Save Room ID = (d_a_kytag14 + 0x568) (loaded from d_a_kytag14 + 0xb0 >> 8, can be 0xFF)
  7. 0x80406220 Save Spawn ID = (d_a_kytag14 + 0x569) (loaded from d_a_kytag14 + 0xb0 casted to byte)
  8.  
  9. -d_a_kytag14 skips updating the save location entirely when the temporary event bit 1 at 0x80406FAB is true (only set to true by the fortune teller as of current knowledge) (resets after softreset)
  10. -d_a_kytag14 only updates when all of the conditions of the Savmem are met
  11. 2 permanently saved event bits can be compared (only when not 0xFFFF):
  12. d_a_kytag14 + 0x56a (short) (loaded from d_a_kytag14 + 0x4dc)
  13. d_a_kytag14 + 0x56c (short) (loaded from d_a_kytag14 + 0x4de)
  14. 2 permanently saved region switch bits can be compared (only when not 0xFF):
  15. d_a_kytag14 + 0x56e (byte) (loaded from d_a_kytag14 + 0x4e0 casted as byte)
  16. d_a_kytag14 + 0x56f (byte) (loaded from d_a_kytag14 + 0x4e0 >> 8)
  17.  
  18. Possible theories how Adam Glitch can happen:
  19. -Savmem failed to create due some flag (very unlikely)
  20. -Event/Region bits didn't get flushed inside the loading zones until switching stage to Areaflos or they were reset to 0 early during the load to areaflos skipping the small key Savmem (very unlikely)
  21. -The Fortune Teller temporary bit was set to true (no path how that could happen as of now besides Fortune Teller)
  22. -byte(d_a_kytag14 + 0x4ba) was != 0xFF (-1) which resulted in the Savmem Room ID being overwritten to d_a_kytag14 + 0x4ba during, which was 0 instead of -1 (spawn point of 0x03 suspiciously fits in both cases) (unlikely though as the origin 8040AFE4 is reset to -1 safely)
  23. -in City 2 Savmems are constantly overwriting each other, possibly load to areaflos was triggered with only the first executing? (would be an extreme race condition, hence unlikely)
  24. -Normal order: Initial Savmem lobby (flags 0xffff, perm event bit ON 0x010C, 0xff, 0xff), lobby after small key Savmem (flags: 0xffff, 0xffff, isSwitch ON 0x26, 0xff), small key savmem (flags: 0xffff, 0xffff, isSwitch ON 0x4D (enabled by tbox_sw), isSwitch OFF 0x18)
  25. -isSwitch OFF 0x18 got set to ON prematurely (and temporarily?) (not very likely)
  26.  
  27. Most likely:
  28. Extreme race condition or Fortune Teller flag got set or 8040AFE4 (stage room byte) was left at 0 and not -1 somehow
  29.  
  30. -0x80529b14 (dSv_player_return_place_c::set in daKytag14_Execute) + 0x30 = beginning of d_a_kytag14::daKytag14_Create
  31. -byte(d_a_kytag14 + 0x4ba) comes from 0x80019198 (fopAc_Create)
  32.  
  33. fopAcM_CreateAppend creates struct and initializes 0x21 (roomID) with -1
  34. d_stage::dStage_actorInit_always overwrites it with whatever is stored at r27 (8040afe0) + 0x04 = 8040AFE4
  35. 8040afe0 is a static ptr to the current stage data
Add Comment
Please, Sign In to add comment