Glitch City Laboratories Archives

Yeah. It's thanks to that we'd be able to enter Hall of Origin without walk-through-walls cheat in case we found it in the void. I don't remember if this is the exact coordinates but going something like 65536 steps east, 65536 north and then 65536 east again you should enter a Fake HoO in an HoO area, assuming you're starting from its initial area (the steps would vary according from where you'd start from).

Yeah. It's thanks to that we'd be able to enter Hall of Origin without walk-through-walls cheat in case we found it in the void. I don't remember if this is the exact coordinates but going something like 65536 steps east, 65536 north and then 65536 east again you should enter a Fake HoO in an HoO area, assuming you're starting from its initial area (the steps would vary according from where you'd start from).

But does said Hall of Origin area play the same theme as the actual real Hall (map ID 0x01FE or 510)? Or is it the Spear Pillar theme that the other Hall (map ID 0x01FF or 511) also uses?

The Hall of Origin loads script file 232, which is:
Script #1

CheckFlag 0x8E
CompareLastResultJump 0x1 Function_#1
End


Script #2

LockAll
SetVar 0x4118 0x0
Call Function_#2
Call Function_#3
PlayCry 0x1ED 0x0
WaitCry
Call Function_#8
PlayCry 0x1ED 0x0
Message 0x0
CloseMessageOnKeyPress
ClearFlag 0x8E
WildBattle2 0x1ED 0x50
SetFlag 0x8E
CheckLost 0x800C
If 0x800C 0x0
CompareLastResultJump 0x1 Function_#9
CheckWildBattle2 0x800C
If 0x800C 0x1
CompareLastResultJump 0x1 Function_#10
ClearFlag 0x11E
ReleaseAll
End


Script #3

End


Script #4

UseScript_#2
There are also functions and movements as part of this script file, but they're less telling so I'll leave them out.

As you can see script 2 involves playing a cry and starting a battle, this would be the Arceus fight. All script 4 does is call script 2, which is nice since it doubles our chances of making this work.
In the event viewer, the HoO has 2 events. One overworld (Arceus) who is set to script 0 and one trigger set to script 2. The trigger has a flag associated - this probably means it only appears when that flag is set, that flag being the event? It's 16664 if anyone knows.

Is this for Diamond and Pearl or Platinum? In Diamond and Pearl, the Arceus sprite will appear even if you don't have the Azure Flute (regardless of the state of the event flag) but this is not the case in Platinum, in which the Azure Flute is required to make the sprite appear.

Yeah. It's thanks to that we'd be able to enter Hall of Origin without walk-through-walls cheat in case we found it in the void. I don't remember if this is the exact coordinates but going something like 65536 steps east, 65536 north and then 65536 east again you should enter a Fake HoO in an HoO area, assuming you're starting from its initial area (the steps would vary according from where you'd start from).

If anyone can help debug why this doesn't work, it would be greatly appreciated  O_o

function whereami()
aslr_data_ptr = memory.readdword(0x021C4D28)
mapdata_ptr = memory.readdword(aslr_data_ptr + 0x4)
m = memory.readword(mapdata_ptr + 0x14A4)
x = memory.readword(mapdata_ptr + 0x14A4 + 8)
y = memory.readword(mapdata_ptr + 0x14A4 + 12)
z = memory.readword(mapdata_ptr + 0x14A4 + 0x6C99A)

all_x = {0x226E7AC, 0x2291DE4, 0x2291DF0, 0x2291DFE,0x2333286,0x2333292,0x23332BA,0x2333E0A4}
all_y = {0x226E7AC+4, 0x2291DE4+4, 0x2291DF0+4, 0x2291DFE+4,0x2333286+4,0x2333292+4,0x23332BA+4,0x2333E0A4+4}
all_z = {0x21CEF76,0x2291E02,0x22DB13E,0x23067A6,0x232460A,0x2333296,0x23332BE}
for i = 1,7 do
-- The values above were taken from my own save state of Pearl. As such, we need to subtract my own map_data_ptr from them, and add the current session's:
-- (skipping over the eighth one since this only appears for x (and consequently y) but not z; its lack of a clear effect suggests the eighth value to be a false positive)
all_x[i] = all_x[i] - 0x226D300 + mapdata_ptr
all_y[i] = all_y[i] - 0x226D300 + mapdata_ptr
all_z[i] = all_z[i] - 0x226D300 + mapdata_ptr
end

all_m = {0x226E7A4,0x2291EC0,0x2291FE8,0x22ABCB0}
for i = 1,4 do
-- If we modify m (= all_m[1]), the game freezes. Perhaps we also need to update the others? Note interesting change counts: walking in and out of a building twice yields the expected change count of 4 for items 1 and 4, but 8 for item 3 and 10 for item 2.
all_m[i] = all_m[i] - 0x226D300 + mapdata_ptr
end

--memory.writeword(all_x[1],force_x) -- if this one is different from the others, the save file will be corrupted; if it is forced during save loading, the game will immediately crash when the save is loaded. This seems to actually move you collision-wise, but not visually.
--memory.writeword(all_x[2],force_x) -- the same; also if this one is forced, the save load screen will display a glitched white block. Does nothing live - perhaps this is the saved x position only?
--memory.writeword(all_x[3],force_x) -- changes map ID!!! but only live, not when loading save. Can be used to save inside a MZ (open start menu, change value to warp you into MZ), with bizarre results.
--memory.writeword(all_x[4],force_x) -- immediately snaps you into place, but without changing map id. Is saved when you save the game only if forced DURING the save, otherwise your new position is NOT saved. Interestingly, THIS IS ONLY GRAPHICAL
--memory.writeword(all_x[5],force_x) -- seems related to graphics loading
--memory.writeword(all_x[6],force_x) -- this one...
--memory.writeword(all_x[7],force_x) -- ...and this one are related; if one of them is flipped, the screen goes black and the other one starts counting like a madman. Counting resets when reloading the graphics. When forcing these to be set and taking a step, the perspective twists, showing this is contorlling the camera.
--memory.writeword(all_x[8],force_x) -- unknown?

function force_m(pos)
memory.writeword(all_m[1],pos) -- name tag. but based on real x,y,z! (i.e. OW locations get their name based on your coordinates)
memory.writeword(all_m[2],pos) -- graphics, but only after reload
--memory.writeword(all_m[3],pos)
--memory.writeword(all_m[4],pos)
end
function force_x(pos)
memory.writeword(all_x[1],pos) -- collision
memory.writeword(all_x[3],pos) -- graphics
memory.writeword(all_x[4],pos) -- matrix
--memory.writeword(all_x[2],pos)
--memory.writeword(all_x[5],pos)
--memory.writeword(all_x[6],pos)
--memory.writeword(all_x[7],pos)
end
function force_y(pos)
memory.writeword(all_y[1],pos) -- collision
memory.writeword(all_y[3],pos) -- graphics
memory.writeword(all_y[4],pos) -- matrix
--memory.writeword(all_x[2],pos)
--memory.writeword(all_x[5],pos)
--memory.writeword(all_x[6],pos)
--memory.writeword(all_x[7],pos)
end
function force_z(pos)
memory.writeword(all_z[1],pos) -- collision
memory.writeword(all_z[3],pos) -- graphics
memory.writeword(all_z[4],pos) -- matrix
--memory.writeword(all_x[2],pos)
--memory.writeword(all_x[5],pos)
--memory.writeword(all_x[6],pos)
--memory.writeword(all_x[7],pos)
end

force_m(3) -- Jubilife city
force_x(180) -- Jubilife city
force_y(777) -- Jubilife city
force_z(2) -- Jubilife city

gui.text(0,144,string.format("ASLR data: 0x%X / map data: 0x%X",aslr_data_ptr,mapdata_ptr))
gui.text(1,154,string.format("Matrix: %d, X: %d, Y: %d, Z: %d",m,x,y,z))
gui.text(0,164,string.format("X: %d %d %d %d %d %d %d %d",memory.readword(all_x[1]),memory.readword(all_x[2]),memory.readword(all_x[3]),memory.readword(all_x[4]),memory.readword(all_x[5]),memory.readword(all_x[6]),memory.readword(all_x[7]),memory.readword(all_x[8])))
gui.text(0,174,string.format("Addrs: %X %X %X %X\n      %X %X %X %X",all_x[1],all_x[2],all_x[3],all_x[4],all_x[5],all_x[6],all_x[7],all_x[8]))
end
gui.register(whereami)

What is interesting is that it seems to warp correctly now, but that it still fails to load the next map on its own. That is, if you uncomment the line 'force(0,8,21,65505,0) – one step before SS', your new location will be correctly set to a few steps above Poketch Co such that, if you take one more step, you will enter the Floaroma Meadows. However, forcing the game to take that step by uncommenting the line after that does not do anything. Interestingly, you can't take that step yourself either - you're blocked by an invisible wall. If you save and reset, however, you can take that next step all of a sudden, and you will load Floaroma Meadows, but if you try to have the step walked automatically by uncommenting the _force(y,65504) line, it won't load Floaroma Meadows again. Unless, and this is the only scenario in which this works, you save one step before SS, load your save, and while at the journal pages activating the _force(y.. line; only in this case, you are correctly warped into Floaroma Meadows.

On your previous script I was able to walk after warping with a walk anywhere code, try that.

What I wouldn't give for a disassembly of the keypress handler or the map handler right now  ;D

That was Pearl. Yes, Arceus is always visible but does not have a script. The trigger (3x1 space that triggers a script when you stand in it) only exists when flag 16664 is set (0x4118 in hex).

In Platinum it all looks the same except that Arceus only appears when flag 590 (hex 0x24E) is set, and script 3 (empty in Pearl) changes some flags.
Script #3

028B 0x2 0x4000
If 0x4000 0x0
CompareLastResultJump 0x1 Function_#12
CheckFlag 0x11E
CompareLastResultJump 0x1 Function_#12
SetFlag 0x24E
End


Function #12

ClearFlag 0x24E
End

This script manages whether Arceus will appear, based on some other flags. Probably to make it appear on entering? Not completely sure without going through everything but that sounds like a safe bet. Scripts 2 and 4 are exactly the same except for the after battle checks, so calling them through another npc if possible will work just as well on Platinum as it would on Diamond/Pearl.

After battle in Pearl:
If you lost: go to Pokecenter & set flag 0x26C
If "WildBattle2" set flag 0x26C and say "ARCEUS disappeared from sight…" (is this if ran away? or defeated it?)
Else: clear flag 0x11E

After battle in Platinum:
If you lost: go to Pokecenter & set flag 0x24E
If "WildBattle2" set flag 0x24E and say the same
If 0x4056 = 0: set variable 0x4056 = 1 and clear flag 0x11E
Else: clear flag 0x11E

Another result to the battle was added. Is it for caught? Is Arceus not rebattleable in Diamond/Pearl? Or maybe it had to be reworked for some other reason. Either way it shouldn't cause problems.

What I wouldn't give for a disassembly of the keypress handler or the map handler right now  ;D

Then go set some conditional breakpoints and find them :D

What I wouldn't give for a disassembly of the keypress handler or the map handler right now  ;D

Then go set some conditional breakpoints and find them :D

Even if I had the skill, I can't manage - when I fire up gdb connected to my desmume and press Ctrl+C, desmume says 'Breaking execution', but it doesn't. That makes live debugging via the gdb stub kind of impossible…

would no$gba debug version work?

Note: this code still suffers a critical defect for being valid for void exploring: when walking through the void, the matrix sometimes changes. This will affect what map ids you will get next. However, since this script does not actually walk, these matrix changes are never triggered. Thus, once you cross a matrix boundary, the results from this script would no longer be valid. I don't have the knowledge to fix this - we'd need to know what exactly triggers a matrix change, and debugging this is just miles beyond me, I'm afraid.

Stickymans SPHoO void: 70,000 North, 2,912 East

By the way, I think it does show valid data as explained below, so maybe all that's needed now is an organised way to output it. Perhaps just .csv (basically plain text) so we can load it into google docs or excel or etc. Another approach would be to ignore most values and have it search for some specific ones, outputting their coordinates. I guess it depends whether we want a hard to look at map of the entire void or a way to search for specific places, both of which may differ between save files.

I don't think the matrix does change while exploring. I just did a short test, see this video (A little over double speed because I wanted to test quickly).

Edit: I got to North Fake Sinnoh. Matrix stayed 0 the whole way, but… I can't believe I forgot this? The headers don't line up with the world? So I guess there is something else to how they're loaded… :/
Apparently I need to go look over all the basics again haha. Saving in NFS should put me there in the real world right? Anyway, this script is a good start.

Stickymans SPHoO void: 70,000 North, 2,912 East

Maybe some coordinates are stored as 4 byte rather than 2 byte? I hope it isn't just that along the journey the good data is changed (though that sounds very possible) because if it's path specific I don't see any trustworthy way of faking it like this, we'd have to make the lua actually travel it properly. That would be so much slower and also means we don't avoid the Pt/HG/SS crashes that this script probably would? (not tested).

Edit again: Yes, I'm seeing three 4 byte x coordinates. They do underflow to full 4 byte numbers, so these must be why the headers are different.
They're at mapdata_ptr + 14AC,  24AE4,  24AF0

What it's doing right now (or at least, it should; I haven't tested it all the way) is printing a map to desume's stdout (the lua window). That it, for every 32 steps it takes to the right, it prints a zero-padded map id plus a space, and once it's reached x=65536 (which is the same as 0), it increments y by 32 and starts a new line. As such, when you let the script run, you will have a full map, and if there's a 510 in there all you can immediately see how you get to it.

Well, we know that all of FS is basically s**t due to not being loaded properly (e.g. lots of routes missing or not lining up correctly), but for our purposes, none of this is relevant - the only thing that matters is that we can walk anywhere (barring z issues) and that we have to find a way to reach a map that is of id 510. (And then hope that it's still going to be a 510 after we walk back to whereever our script #1/#2 npc is.)

Well, something must definitely be going on, since the FS at 70k N should be exactly the same as the FS at 5k-430 N otherwise, and this is evidently not the case. Does my script correctly reach the Stickyman HoO? If so, then data changes along the way, but my script manages to emulate that properly. If not, then either data does change along the way but my script's way of "walking" doesn't trigger that (so we'd need to reprogram it to also do stuff to these other RAM pointers you mention), or the data doesn't change but these RAM areas do change as a function of real walking and we will still need to do the same.

As a footnote I might add that going too far in either direction will lead to all areas acting like BSoD