"Void Knowledge Archive, by the members of HallofOrigin"

[vowel]

It's just a little hard to look at is all, unless there's a way to get a horizontal scrollbar? (Assuming the new line of void prints on a new line? Yeah I guess it does.)

There's no way to make the window bigger, AFAICS. My intention was for someone to copy this into notepad/excel and then examine it from there.

Your script only increments to 65k, since that's a full 2 byte number so I don't see how it could reach 70k. I haven't run it extensively though, and in theory (so if it does wrap after 2 bytes) that'd show up near the end of your script since 70k North would be around 60k South, and you do horizontal first.

That's my point, at 65536 it should just have rolled around so 70k==4.5k. But there's a different map at 4.5k than at 70k, so something else must be going on.

I don't really get how both a 2 byte and 4 byte number can be mapped to the same thing which sounds like an issue (unless you've just got the small end of it?)
Maybe if you just change both it'll work.

The DS is little-endian, so a number '1234' would be stored in memory as '34 12'. So this is very much possible

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

This is something to keep in mind. 4 bytes gives us 4,294,967,295 possible values for each coordinate which is way too many. That takes too long to measure, too long to travel to manually and the game isn't stable enough it sounds like, so the search should probably be restricted... though hey if your method of virtually traveling doesn't suffer from instability maybe it'd be interesting to measure anyway? It'll take forever though.

I guess we'll have to see. Note that a BSOD is basically the result of interpreting data RAM as (invalid) instructions, so if I knew anything about debugging, this might eventually become a vector for ACE...

EDIT: well, this is concerning. The below does NOT reach Stickyman's HoO 

Code: [Select]

-- PoC: reach SFHoO
-- to be run when saved+reset @430N
-- 70kN,2912E
function SFHoO()
oldy=memory.readword(mapdata_ptr+0x24AF8)
for incr=0,70000,32
do
writefakey(oldy-incr)
emu.frameadvance()
end
writefakex(memory.readword(mapdata_ptr+0x24AF0)+2192)
end
SFHoO()I'm doing something right, because I do get different maps than the standard Floaromas and Veilstones above Jubilife (e.g. I get Victory Road now), but no fake HoOs... 

[vowel]

I'm sorry, I thought I had implemented your suggestion of treating the coordinates as 4-byte data rather than 2-byte but it seems I hadn't.

Changing the words to dwords gives different results - the previous script now puts me squarely at Route 205. This is still not the promised SFHoO, but it's different compared to the Mystery Zone (which becomes Oreburgh City when you save in it) that I got when I was reading and writing words.

Code: [Select]

aslr_data_ptr = memory.readdword(0x021C4D28)
mapdata_ptr = memory.readdword(aslr_data_ptr + 0x4)

mtxs = {0x22B2E,0x6791C,0x67A40}
ms   = {0x14A4,0x24BC0,0x24CE8}
xs   = {-0x61C5A,-0x61C72,0x14AC,0x24AE4,0x24AF0,0x24AFE}
ys   = {         -0x61C7A,0x14B0,0x24AEC,0x24AF8,0x24B06}
zs   = {         -0x61C76,       0x24B02,                0x6DE3E,0x994A6,0xC5F96,0xC5FBE}

function whereami()
m_pksv = memory.readword(mapdata_ptr + 0x14A4)
x_pksv = memory.readword(mapdata_ptr + 0x14A4 + 8)
y_pksv = memory.readword(mapdata_ptr + 0x14A4 + 12)
z_pksv = memory.readword(mapdata_ptr + 0x14A4 + 0x6C99A)
gui.text(0,174,string.format("matrix data starts at %X",mapdata_ptr+mtxs[1]))
gui.text(0,184,string.format("mtx: %d m: %d x: %d, y: %d, z: %d",memory.readword(mapdata_ptr+mtxs[1]),m_pksv,x_pksv,y_pksv,z_pksv))
end
gui.register(whereami)

-- The below functions don't really warp you (your real coords don't change), but do load the map header of the next section
function readmap()
return memory.readword(mapdata_ptr+0x14A4)
end
function writefakex(pos)
memory.writedword(mapdata_ptr+0x24AF0,pos)
end
function writefakey(pos)
memory.writedword(mapdata_ptr+0x24AF8,pos)
end

-- PoC: reach SFHoO
-- to be run when saved+reset @430N
-- 70kN,2912E
function SFHoO()
oldy=memory.readdword(mapdata_ptr+0x24AF8)
for incr=0,70000,32
do
writefakey(oldy-incr)
emu.frameadvance()
end
writefakex(memory.readdword(mapdata_ptr+0x24AF0)+2192)
end
SFHoO()
EDIT: Also tried this, but this BSODs me and then dumps me at the Sunyshore elevator right before it finishes walking 2912E after the 70kN

Code: [Select]

function travel_x(steps,dir)
if dir == "E" then dir = 1 end
if dir == "W" then dir =-1 end
for incr=0,steps,1
do
writefakex(readfakex()+incr*dir)
if (incr % 100) == 0 then print(string.format("Took my %d'th step",incr)) end
if incr == 65536 then memory.writeword(mapdata_ptr+0x24AF0+2,memory.readword(mapdata_ptr+0x24AF0+2)+1) end
emu.frameadvance()
end
end
function travel_y(steps,dir)
if dir == "S" then dir = 1 end
if dir == "N" then dir =-1 end
for incr=0,steps,1
do
writefakey(readfakey()+incr*dir)
if (incr % 100) == 0 then print(string.format("Took my %d'th step",incr)) end
if incr == 65536 then memory.writeword(mapdata_ptr+0x24AF8+2,memory.readword(mapdata_ptr+0x24AF8+2)+1) end
emu.frameadvance()
end
end

-- PoC: reach SFHoO
-- to be run when saved+reset @430N
-- 70kN,2912E
-- Save+reset
-- 4894S, 2816W
travel_y(70000,"N")
travel_x(2912,"E")
--travel_y(4894,"S")
--travel_x(2816,"W")EDIT2: actually, this is wrong, because it's incrementing by incr*dir whereas it should be incrementing by just dir. But this dumps me into a MZ when I'm supposed to SR after 70kN, 2912E so that isn't right either.

[~Poke~]

There's no way to make the window bigger, AFAICS. My intention was for someone to copy this into notepad/excel and then examine it from there.

I've tried this, but it has a maximum amount of text. After too much is written the older data is deleted. So if it's possible to write a file that would be really useful. I also tried converting it to csv (find and replace spaces for commas with notepad) but Google docs didn't like it (no reason given) and libreoffice said it exceeded the maximum number of columns. So that's a shame. It also doesn't display properly in notepad with word wrap disabled, apparently it has a max line length.
Notepad++ shows it fine so that's one way to read it.

Looking at the first few lines, the script doesn't seem to give correct results though. When both x and y are very low in matrix 0 they should show the real layout of the overworld, right?

That's my point, at 65536 it should just have rolled around so 70k==4.5k. But there's a different map at 4.5k than at 70k, so something else must be going on.

I tried to test this, but at one point the player enters a warp and crashes. I wonder whether that's a problem with that spot, or it's because of how the script works. x:17792 y:5664 was where I got it, though idk if it's consistent.

I'm sorry, I thought I had implemented your suggestion of treating the coordinates as 4-byte data rather than 2-byte but it seems I hadn't.

Changing the words to dwords gives different results - the previous script now puts me squarely at Route 205. This is still not the promised SFHoO, but it's different compared to the Mystery Zone (which becomes Oreburgh City when you save in it) that I got when I was reading and writing words.



EDIT: Also tried this, but this BSODs me and then dumps me at the Sunyshore elevator right before it finishes walking 2912E after the 70kN

EDIT2: actually, this is wrong, because it's incrementing by incr*dir whereas it should be incrementing by just dir. But this dumps me into a MZ when I'm supposed to SR after 70kN, 2912E so that isn't right either.

I walked manually to the SPHoO to test if it was right, and it did show up. The top left coordinates are (B60,FFFEECE1) if that helps you, bottom right being (B7F,FFFEED00).
Also, apparently the script gets confused if I try to output the 4 byte x or y as decimal while they're negative? They get stuck at -2147483648 and won't change unless I make it positive/overflow to 0. There's probably something I'm misunderstanding but I blame lua.

While testing that I found something weird just to the west of real Sinnoh (when x underflows). It's basically... the opposite of Fake Sinnoh? No graphics load, but movement permissions still exist and you can find wild Pokemon.
This is really quick to reach so it probably is already known, but I can't find any videos about it. I think it should be called Invisible Sinnoh

[youtube]https://www.youtube.com/watch?v=loahWwUxymA[/youtube]

This video starts from 430N. I couldn't find any wild Pokemon without first turning on walk anywhere to get through the walls, so maybe no one ever realised how this place acts. Since some things are intact, I wonder if scripts load and etc... though no npcs are visible so they probably can't be interacted with if they are there.

[vowel]

SUCCESS! This script reaches Stickyman's HoO. The key was to treat everything as a dword, with proper overflow of the 65536 steps, as you had already suggested. I guess my previous implementation had a mistake.

Code: [Select]

function travel(steps,dir)
if dir == "E" then dir = 1; addr=mapdata_ptr+0x24AF0 end
if dir == "W" then dir =-1; addr=mapdata_ptr+0x24AF0 end
if dir == "S" then dir = 1; addr=mapdata_ptr+0x24AF8 end
if dir == "N" then dir =-1; addr=mapdata_ptr+0x24AF8 end
for incr=0,steps,1
do
memory.writedword(addr,memory.readdword(addr)+dir)
if (incr % 32) == 0 then emu.frameadvance() end
if (incr % 100) == 0 then print(string.format("Took my %d'th step",incr)) end
end
end

-- PoC: reach SFHoO
-- to be run when saved+reset @430N
-- 70kN,2912E
-- Save+reset
-- 4894S, 2816W
travel(70000,"N")
travel(2912,"E")
--travel(4894,"S")
--travel(2816,"W")
--travel(0,"N")
I also quickly wrote the below script, intended to be a VoidScanner(r)(tm)   
It walks 0xFFFFFFFF (i.e. something like 4 billion) steps north * as many steps west, and prints the map id plus coordinates to a file (as requested  ), named VoidScanner.txt, for every 32 steps taken.
I'm still testing to see if its results are correct. What I am already seeing is that the game consistently freezes at x = 0xFFFE5AB5 (as had been noted before: going too far into either cardinal direction causes a freeze). Not sure how I should deal with this - advice would be appreciated!

Code: [Select]

mapdata_ptr = memory.readdword(memory.readdword(0x021C4D28)+0x4)

-- Scan the void: walk 0xFFFFFFFF in every god-forsaken direction...
-- (only try N and W since only these underflow x and y and we're not interested in mapping out real Sinnoh)
-- note: will be printed upside-down and flipped
file = io.open("VoidScan.txt","w")
for incry=0,0xFFFFFFFF,32
do
memory.writedword(mapdata_ptr+0x24AF8,memory.readdword(mapdata_ptr+0x24AF8)-32)
for incrx=0,0xFFFFFFFF,32
do
memory.writedword(mapdata_ptr+0x24AF0,memory.readdword(mapdata_ptr+0x24AF0)-32)
emu.frameadvance()
file:write(string.format("%05d[%08X,%08X] ",memory.readword(mapdata_ptr+0x14A4),memory.readword(mapdata_ptr+0x24AF0),memory.readword(mapdata_ptr+0x24AF8)))
file:flush()
end
file:write("\n")
file:flush()
end

Also, apparently the script gets confused if I try to output the 4 byte x or y as decimal while they're negative? They get stuck at -2147483648 and won't change unless I make it positive/overflow to 0. There's probably something I'm misunderstanding but I blame lua.

Probably some sort of overflow protection in lua itself. -2147483648 is the lowest value a 32-bit signed integer can have.

While testing that I found something weird just to the west of real Sinnoh (when x underflows). It's basically... the opposite of Fake Sinnoh? No graphics load, but movement permissions still exist and you can find wild Pokemon.
This is really quick to reach so it probably is already known, but I can't find any videos about it. I think it should be called Invisible Sinnoh

Interesting! This corroborates my earlier suspicions that graphics and collision data are loaded in different ways, i.e. are independent from one another: FS has correct graphics but bad collision, and now you've found FS's reverse counterpart 

[~Poke~]

Nice!
I'm getting an event that may be the same crash you're getting. The character walks 2 steps up, 2 steps down then goes through a warp.
While running the game at real time this causes a crash, but if I fast forward the warp works and I'm teleported to matrix 230 (apparently Vista Lighthouse). The script keeps running, but the results are now incorrect since it's the wrong matrix so it's still a problem.
Maybe if the script sets the matrix each time that would be a workaround, but since fast forward actually affects how the game behaves it might be safer to not use it, so we'd need to avoid this completely.

The problem area wouldn't be the lighthouse itself, but the area that warps you to it. The elevator at Map 516 Matrix 207 does this. The script is triggered the moment you enter, no interaction. The doc mentions this elevator and one in Hearthome causing problems under "I got kicked out of the void!"

This is an autorun event that can't be disabled, so the only way I see to completely avoid it is reverting to a saved state and skipping that area. Saving states on every loop of the script sounds slow, so you'd need to choose a reasonable interval and make sure the script can deal with being a little behind where it was up to.
That said, I may have found a sneakier solution... talk to someone. While their message is open, start the lua script. This seems to stop the warping script from running since you're busy. The textbox also bounces with the place name which is pretty silly to watch.

No guarantees it's a perfect solution. I'm up to FFF00000 so far without problems, but searching the output shows I haven't been to map 516 yet. That's a lot further than I got on other attempts so it might have solved something?

Just before hitting post my screen turned black at FFE?????. The script and game are still running, maps and music still changing, but this may be a limit for real exploration. I'll try to test it manually in another instance (which could take a while and/or be hard thanks to autowarps ). VoidScan.txt still says I haven't hit map 516 so it's not related to the warp... still could be related to having a textbox open though.

EDIT: I just ran some numbers and that would take something like 3 hours 40 minutes to ride to, at the rate of 10 spaces per second (which probably isn't completely accurate). I think I'll pass for now. Meanwhile the script is still going well, now just passed FFCD0000. Still doesn't say it's found map 516 (neither map 511).

EDIT again: Just crashed at FFC444AC. The last 7 maps it visited were map 0, but before that was 38. The Canalave Library.
Something I'm noticing is that every map it visits is repeated. Here I see three map 38s in a row. I don't think the void normally acts like this though, maps tend to be alone (long stretches of mystery zone or the various jubilifes being the very notable exceptions that make it seem otherwise). Is the script running too fast for the game to keep up maybe?

[vowel]

EDIT again: Just crashed at FFC444AC. The last 7 maps it visited were map 0, but before that was 38. The Canalave Library.
Something I'm noticing is that every map it visits is repeated. Here I see three map 38s in a row. I don't think the void normally acts like this though, maps tend to be alone (long stretches of mystery zone or the various jubilifes being the very notable exceptions that make it seem otherwise). Is the script running too fast for the game to keep up maybe?

Oh no, it's just that I'm printing a map every 32 steps. So if a map is bigger than 32 steps it will be printed multiple times.

I've actually already found a HoO (it's 510 btw, not 516), but I had sort of cheated while doing it... My starting point was the Floaroma Flower Shop, but before I began searching I warped myself to [0,0] on that map, hence the cheating bit. But with that starting point, I found a HoO somewhere in like WWWWWWWWFS or something.

I'm now seeing what happens if I limit the script to maximally five FSs in a row and then trying from various entry points. Because it's going to take aaaages to map all of the void, and just as many ages for a non-cheater to walk normally to WWWWWWWWWWWWWFS or something like that.

[~Poke~]

Oh no, it's just that I'm printing a map every 32 steps. So if a map is bigger than 32 steps it will be printed multiple times.

Usually if a map shows up it is only 32 steps across though - eg. Stickyman's HoO. This is only a 32x32 area in the void even though when the real map is visited it's 64x64. Sure it is possible for a map to show twice in a row, but in VoidScan.txt I don't see any single maps at all. Always 2, 3 or sometimes 4 of the same in a row.

I changed the script to wait 4 frames instead of 1 (just a guess, maybe less are fine) and I'm getting very few duplicates. Still some, but few enough that perhaps those duplicates are real? Of course this does slow the scanning down.

I've actually already found a HoO (it's 510 btw, not 516)

Nice! When I said 516 I was referring to the elevator that I suspect is causing the crash btw.

but I had sort of cheated while doing it... My starting point was the Floaroma Flower Shop, but before I began searching I warped myself to [0,0] on that map, hence the cheating bit. But with that starting point, I found a HoO somewhere in like WWWWWWWWFS or something.

Oh, does the script not set x and y to 0 before it starts? I guess it doesn't, I'll add that now. I've just been running it from the middle of Jubilife, oops. Well, I guess it doesn't really matter since it gives coordinates anyway.

I'm now seeing what happens if I limit the script to maximally five FSs in a row and then trying from various entry points. Because it's going to take aaaages to map all of the void, and just as many ages for a non-cheater to walk normally to WWWWWWWWWWWWWFS or something like that.

Yeah, limiting the search like that sounds good. Those 5x64k steps should give plenty of space for interesting things to show up.
Pawny mentioned earlier that the voids of many inside places are similar/less interesting, so the Overworld might give better results.


I just got another crash warp that sent me to map 113, matrix 210. That header is part of Hearthome, perhaps the department store so I guess I ran into the other elevator now. I got that when I started from 0,0 and didn't have someone to talk to, so all the more reason to use that sneaky trick which does seem to work.

EDIT: It found a Hall of Origin in the overworld void at 00510[0000D8E0,0000FFE0]
So that's about 55,520 steps West and 400 steps South of 430N.
No wait, no it's not. Ok the script is only writing the small end of the coordinate to the file it looks like? Oops.

[vowel]

Usually if a map shows up it is only 32 steps across though - eg. Stickyman's HoO. This is only a 32x32 area in the void even though when the real map is visited it's 64x64. Sure it is possible for a map to show twice in a row, but in VoidScan.txt I don't see any single maps at all. Always 2, 3 or sometimes 4 of the same in a row.

I changed the script to wait 4 frames instead of 1 (just a guess, maybe less are fine) and I'm getting very few duplicates. Still some, but few enough that perhaps those duplicates are real? Of course this does slow the scanning down.

This is a very important observation, thank you. It is entirely possible that a single frame is not enough time for the game to update the map value. I've changed this to two frames now, let's see what happens to me. Also, I noticed a very stupid bug: I was not resetting the x value when I proceeded to the next line of y values, so what you would think is NFS would actually be NWWWWW...WWWFS etc. I've fixed that too in the below code, which now also appends to VoidScan.txt rather than clobbering it first:

Code: [Select]

file = io.open("VoidScan.txt","a")
file:write("\n-------------------------------------------------------------\n")
for incry=0,65536*4,32
do
oldx = memory.readdword(mapdata_ptr+0x24AF0)
for incrx=0,65536*4,32
do
emu.frameadvance()
emu.frameadvance()
emu.frameadvance()
file:write(string.format("%05d[%08X,%08X] ",memory.readword(mapdata_ptr+0x14A4),memory.readdword(mapdata_ptr+0x24AF0),memory.readdword(mapdata_ptr+0x24AF8)))
file:flush()
memory.writedword(mapdata_ptr+0x24AF0,memory.readdword(mapdata_ptr+0x24AF0)-32)
end
file:write("\n")
file:flush()
memory.writedword(mapdata_ptr+0x24AF0,oldx)
memory.writedword(mapdata_ptr+0x24AF8,memory.readdword(mapdata_ptr+0x24AF8)-32)
end

Oh, does the script not set x and y to 0 before it starts? I guess it doesn't, I'll add that now. I've just been running it from the middle of Jubilife, oops. Well, I guess it doesn't really matter since it gives coordinates anyway.

No, because I wanted to make it realistic for doing a real run later on, and if you enter a door from behind you're not at [0,0] but rather at [door.x,door.y+1] 

I just got another crash warp that sent me to map 113, matrix 210. That header is part of Hearthome, perhaps the department store so I guess I ran into the other elevator now. I got that when I started from 0,0 and didn't have someone to talk to, so all the more reason to use that sneaky trick which does seem to work.

I also seem to vaguely recall something about the beta areas of the Hearthome gym doing crashy things, I dunno 

EDIT: It found a Hall of Origin in the overworld void at 00510[0000D8E0,0000FFE0]
So that's about 55,520 steps West and 400 steps South of 430N.
No wait, no it's not. Ok the script is only writing the small end of the coordinate to the file it looks like? Oops.

see above - due to a mistake on my part this is actually 400/32*65536 further West than the log would have you believe - I'm so sorry 

EDIT: still seeing lots of duplicate maps with 2 emu.frameadvances()... trying 3 now

[~Poke~]

see above - due to a mistake on my part this is actually 400/32*65536 further West than the log would have you believe - I'm so sorry 

This was before any looping at all - it was still the version of the script that goes west until it crashes.
I'm looking at the outputs and seeing 00002[0000FFE0,0000FFE0] when the coordinates were actually [FFFFFFE0,FFFFFFE0]. None of them have the higher end set to anything but 0, so I think it's got the wrong address... but it's the same as the others? It's reading it wrong maybe? Are you getting this?

No, because I wanted to make it realistic for doing a real run later on, and if you enter a door from behind you're not at [0,0] but rather at [door.x,door.y+1]

Ah, that makes sense. For overworld I think I'll make it start at 430N from now on, instead of 0,0 (although, that does mean intentionally ignoring a Hall of Origin that I do know exists ~400 South and (something big) West of 430N... but hey there'll be plenty more where that came from.)

I'll just edit this reply in since I don't have anything new post worthy yet:

You mean it hadn't gone south at all yet?
No, I'm not. It's possible that it got the wrong address if you resetted without restarting the script (that would not update the mapdata_ptr value). That's the only explanation I can think of - everything seems fine on my end (I'm testing from behind the door inside the building on Iron Island, and a random excerpt of my log is '00000[FFFC71E4,FFFFFF69]').

Yep. Sorry for the panic though, the current script is working... I don't see any difference in the script for file writing so I can't say what the problem was? Sorry, but it works now. I've been stopping the script, restarting the game and deleting the .txt between attempts. It probably was my error though, more likely to be mistakes than just a random occurence

[vowel]

This was before any looping at all - it was still the version of the script that goes west until it crashes.

You mean it hadn't gone south at all yet?

I'm looking at the outputs and seeing 00002[0000FFE0,0000FFE0] when the coordinates were actually [FFFFFFE0,FFFFFFE0]. None of them have the higher end set to anything but 0, so I think it's got the wrong address... but it's the same as the others? It's reading it wrong maybe? Are you getting this?

No, I'm not. It's possible that it got the wrong address if you resetted without restarting the script (that would not update the mapdata_ptr value). That's the only explanation I can think of - everything seems fine on my end (I'm testing from behind the door inside the building on Iron Island, and a random excerpt of my log is '00000[FFFC71E4,FFFFFF69]').

Ah, that makes sense. For overworld I think I'll make it start at 430N from now on, instead of 0,0 (although, that does mean intentionally ignoring a Hall of Origin that I do know exists ~400 South and (something big) West of 430N... but hey there'll be plenty more where that came from.)

Let's hope so, since if not we would have to break the news 'yeah, so, we found the HoO, but without cheats you'll be walking West for about a month straight'

[vowel]

I've been thinking. The script in its current form takes ages to run with no certainty of success. However, maybe it's possible to cut down on the runtime by not checking every 32x32 area.

The doc says that the void repeats diagonally. Is this always true? If so, we could change the algorithm to:

• scan a single horizontal line of 32-step wide x areas
• from the same point, scan a single vertical line of 32-step wide y areas
• scan not 4 FSs (as I'm doing now), but rather 4*4=16; if we then find a HoO at, say, [Wx16]FS, we will be able to walk there by going to [Nx4][Wx4]FS

(by 'FS' I mean a 65536-step wide chunk, even if this does not necessarily lead to Sinnoh-with-graphics-but-without-collisions)

The big question: is this right? That is, does the correlation hold that the void repeats diagonally within the whole 65536-step continuum? And does it also hold across it, i.e. after the step counter has underflown more than once?

I'm asking both from a mathematical perspective (is my reasoning correct, i.e. if the void repeats diagonally, will scanning 16 FSs be equivalent to scanning 4 in multiple directions?) as well as from a game-technical perspective (does the void really repeat diagonally to such an extent that we may rely on it in the way I propose?).

(Oh, by the way, if this is indeed correct, then the HoO I found at [Wx??]FS of the Floaroma Flower Shop might suddenly have halved its infeasibility of being reached )

EDIT: also, I was thinking maybe I was wrong to exclude SFS and EFS from consideration. My reasoning was that they would just be mirrors of real Sinnoh, but this is only the case if starting (a) from [0,0], and (b) from the overworld; on top of that, real Sinnoh is not 65536x65536 tiles in size so it might still hold some secret HoOs? Though on the other hand, their coords will obviously not underflow, so they might not load the improper maps from before the beginning of the real matrix data (I'm assuming that's what's happening) that we rely on?

[SatoMew]

Wow, you two seem to be very tech-savvy about this. I feel a bit overwhelmed by your posts

[~Poke~]

I've been thinking. The script in its current form takes ages to run with no certainty of success. However, maybe it's possible to cut down on the runtime by not checking every 32x32 area.

The doc says that the void repeats diagonally. Is this always true? If so, we could change the algorithm to:

Correct. For indoor areas the repetition is directly diagonal - 32 steps up and 32 east will lead you to the exact same area.
It's different for the overworld though. "Sinnoh requires 960 steps east before you reach the same area while indoor areas require 32."
If you have a way to run the big numbers and want to confirm this, I have a scan of the overworld that's up to Y: FFFFE000. Yeah, it's been running for a while (I have no clue how long, since it seems to pause when the screen turns off).
It sadly hasn't found a Hall of Origin yet (If areas do repeat at 32N 960E then I would expect to see my really far away one... Eventually? Apparently not yet.)

My preferred way to visualise this would have been with a spreadsheet, and fill in all the Mystery Zones and Fake Jubilifes with a dark grey. Then zooming out would make it easy to see any other maps.
As it stands, the only thing that'll open this without crashing is Notepad++ and even that's getting slow, so I have no idea how to go about visualising it. At least I can still search it.

The scan (47mb) is here. I'll stop this scan now since we're figuring out more efficient ways to do it
https://mega.nz/#!vphD2CYb!V-XbRrZUap0iIakg_-yGBAVLsp3FhCjo5WF4jHpJetw

Maybe next for the overworld I'll do (960/32 =)30 spaces West, infinitely North. That'll fit within a spreadsheet and should eliminate the repetition.

I was thinking maybe I was wrong to exclude SFS and EFS from consideration. My reasoning was that they would just be mirrors of real Sinnoh, but this is only the case if starting (a) from [0,0], and (b) from the overworld; on top of that, real Sinnoh is not 65536x65536 tiles in size so it might still hold some secret HoOs? Though on the other hand, their coords will obviously not underflow, so they might not load the improper maps from before the beginning of the real matrix data (I'm assuming that's what's happening) that we rely on?

There are more things down there, since your script that went to 65k had results. Even if they load data from after the matrix rather than before, that still sounds useful.

Wow, you two seem to be very tech-savvy about this. I feel a bit overwhelmed by your posts

Well we're nearly through making this script work, maybe we'll make a bit more sense after that
The other puzzle is how to use the Hall of Origin once we get there, and I don't have any ideas for that yet.


EDIT:
The Hall of Origin has been found!
00510[FFFFFF60,FFFF8720]
30,528 steps North and 180 steps West of 430N.
That's really close.
I just made the trip manually and it is there! Correct music and everything! (This also confirms that scanning with the script is accurate).
Now to check a fresh save file, to see if it's consistent.

[vowel]

Correct. For indoor areas the repetition is directly diagonal - 32 steps up and 32 east will lead you to the exact same area.
It's different for the overworld though. "Sinnoh requires 960 steps east before you reach the same area while indoor areas require 32."

The other puzzle is how to use the Hall of Origin once we get there, and I don't have any ideas for that yet.

The overworld is useless for us, since they won't contain the npcs from indoors we'll use to trigger the Arceus script.

My observation was the following: if I save+reset in a pokemon center and then change my coordinates using pokesav, the npcs from the pokemon center are still there at their original coordinates and can be talked to to trigger the Arceus script. This means that if we want to battle Arceus we must:

• (save and reset inside an indoor area?)
• find a way from there to the HoO without having to save and reset again (at all or just in the OW?)

(I really really hope this 'npcs are stored separately from map location and hence will still appear if you've underflowed x/y as long as you haven't entered a warp' holds though if we've walked there ourselves, rather than haxed it. If not, then we're screwed and won't be able to trigger the script after all  )

The Hall of Origin has been found!
00510[FFFFFF60,FFFF8720]
30,528 steps North and 180 steps West of 430N.
That's really close.

You saved and reset at 430N, didn't you? I don't know why, but that seems to wipe the npcs from your save, meaning you won't have those npcs anymore to trigger the script...
(I do hope very much I'm wrong though, in which case you should be able to walk to [0,0] and see the npcs from Poketch Co, and if you're then still in a HoO - you should be given that you're in the HoO matrix - you can talk to two of those npcs to trigger the battle)

If you have a way to run the big numbers and want to confirm this, I have a scan of the overworld that's up to Y: FFFFE000.

Thanks, this is helpful. I'll write a quick script later today to see whether it indeed repeats.

My preferred way to visualise this would have been with a spreadsheet, and fill in all the Mystery Zones and Fake Jubilifes with a dark grey. Then zooming out would make it easy to see any other maps.
As it stands, the only thing that'll open this without crashing is Notepad++ and even that's getting slow, so I have no idea how to go about visualising it. At least I can still search it.

Why don't you simply use 'find' (assuming Windows)? Open a command prompt, cd to the folder containing the script, enter command '<VoidScan.txt find "00510"'. If a blank line is returned, you haven't found a HoO yet. If a massive line is returned, you got it. If you have 'grep' available (not standard Windows) you can use '<VoidScan.txt grep -Po "00510\[[,0-9AF]\]"' to then print the exact coordinates.

There are more things down there, since your script that went to 65k had results. Even if they load data from after the matrix rather than before, that still sounds useful.

That script never went south and/or east, but I'll include those directions in a future iteration nonetheless.

[~Poke~]

The overworld is useless for us, since they won't contain the npcs from indoors we'll use to trigger the Arceus script.

My observation was the following: if I save+reset in a pokemon center and then change my coordinates using pokesav, the npcs from the pokemon center are still there at their original coordinates and can be talked to to trigger the Arceus script. This means that if we want to battle Arceus we must:

• (save and reset inside an indoor area?)
• find a way from there to the HoO without having to save and reset again (at all or just in the OW?)

(I really really hope this 'npcs are stored separately from map location and hence will still appear if you've underflowed x/y as long as you haven't entered a warp' holds though if we've walked there ourselves, rather than haxed it. If not, then we're screwed and won't be able to trigger the script after all  )

Hm, the main problem with that I'm seeing is the NPCs have the specific map coordinates they're set to, so you would need to move the Hall of Origin to those coordinates. The only way to do that I know of is save and reset there? Maybe some kind of key item could do something? Another option is going to Fake (your place), which I think will only show the NPCs if you're in the right header (as happens with Jubilife in Fake Sinnoh) but I've never tested with an indoor area so perhaps it's different.

I do suspect that NPCs are reloaded just by travelling - you can ride all over the overworld without going through warps via walk anywhere codes and all the NPCs work fine. That may only be for the Overworld though, since indoor areas don't have much reason to dynamically load NPCs and there are some exceptions in the Overworld (I just looked. On Route 201 you can still see the head of a Twinleaf guy, but if there's no inbounds place to see a neighbouring NPC then you can see it unload when switching areas. One example is Canalave city.)

With a bit of quick testing, visiting a Mystery Zone from inside a building has no affect at all on the NPCs. Visiting a different header (in this case Floaroma Meadows) will make them invisible. Sometimes they can still be talked to (people in Poketch Co.) but sometimes they can't until the graphics are reloaded (Your mum at home). I don't really see what difference leads to this, but I notice your mum's shadow is in the wrong place so maybe it's a Z thing? Why do buildings have different Zs?
I hope this doesn't mean walking from the building to the HoO entirely in Mystery Zones, that sounds tedious

I feel like I might be on to something there, except for the slight detail of needing to be in the HoO for the right scripts to load and needing to not enter anything so the right events don't unload... Perhaps there's some distinction between scripts and events/NPCs that will let us abuse this?

What if the NPCs that follow you could be brought there? They're only meant to go to specific areas, so they probably call specific scripts that are within them, right? That does potentially mean starting a new game to get the one that runs the correct script, if the repeatable ones (only Amity Square off the top of my head?) don't do it.

You saved and reset at 430N, didn't you? I don't know why, but that seems to wipe the npcs from your save, meaning you won't have those npcs anymore to trigger the script...
(I do hope very much I'm wrong though, in which case you should be able to walk to [0,0] and see the npcs from Poketch Co, and if you're then still in a HoO - you should be given that you're in the HoO matrix - you can talk to two of those npcs to trigger the battle)

Yep, I'm using the standard 430N tactics. Even if this one isn't useful for catching Arceus, it's still cool to be able to travel there since it hasn't been found before.

Fake Jubilifes (including the one at 430N) are set to the same scripts, events and therefore NPCs as real Jubilife by the way. This doesn't really help since they're all the way over at the coordinates of Jubilife City.

Another idea: Void areas repeat. In Fake Sinnoh, if the visible Jubilife City overlaps with a Jubilife header the NPCs will appear (in theory this goes for any other city or route, though you're incredibly unlikely to find the header)
If there's an area where the Hall of Origin overlaps with Fake Jubilife City, well it turns out that the HoO I found is surrounded by Jubilifes so we can make the NPCs appear. They would disappear again on entering the HoO but maybe that can lead to something? *shrug*

Why don't you simply use 'find' (assuming Windows)? Open a command prompt, cd to the folder containing the script, enter command '<VoidScan.txt find "00510"'. If a blank line is returned, you haven't found a HoO yet. If a massive line is returned, you got it. If you have 'grep' available (not standard Windows) you can use '<VoidScan.txt grep -Po "00510\[[,0-9AF]\]"' to then print the exact coordinates.

That... sounds a lot more convenient. I'll do that next time files get too big

That script never went south and/or east, but I'll include those directions in a future iteration nonetheless.

The script you wrote to try travel to the SPHoO treated the coordinates as 2 byte, so when it underflowed it only went to 65k. So after seeming to travel 70k north, it had effectively traveled 60k South. You mentioned Victory roads being either there or on the way

Since the scan is still running, I just found another overworld void HoO. This is a different one rather than a repetition, because it's next to a Mystery Zone instead of Jubilifes.
00510[FFFFFC60,FFFD7E80]
Unless the neighbouring Mystery Zone is useful in some way I don't see any reason to actually travel out to this one