December 10, 2019, 01:07:48 am
0 Members and 1 Guest are viewing this topic.
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.)
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.
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.
Quote from: docAs a footnote I might add that going too far in either direction will lead to all areas acting like BSoDThis 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.
As a footnote I might add that going too far in either direction will lead to all areas acting like BSoD
-- PoC: reach SFHoO-- to be run when saved+reset @430N-- 70kN,2912Efunction 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)endSFHoO()
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))endgui.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 sectionfunction readmap() return memory.readword(mapdata_ptr+0x14A4)endfunction writefakex(pos) memory.writedword(mapdata_ptr+0x24AF0,pos)endfunction writefakey(pos) memory.writedword(mapdata_ptr+0x24AF8,pos)end-- PoC: reach SFHoO-- to be run when saved+reset @430N-- 70kN,2912Efunction 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)endSFHoO()
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() endendfunction 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() endend-- PoC: reach SFHoO-- to be run when saved+reset @430N-- 70kN,2912E-- Save+reset-- 4894S, 2816Wtravel_y(70000,"N")travel_x(2912,"E")--travel_y(4894,"S")--travel_x(2816,"W")
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.
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'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 70kNEDIT2: 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.
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 endend-- PoC: reach SFHoO-- to be run when saved+reset @430N-- 70kN,2912E-- Save+reset-- 4894S, 2816Wtravel(70000,"N")travel(2912,"E")--travel(4894,"S")--travel(2816,"W")--travel(0,"N")
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 flippedfile = io.open("VoidScan.txt","w")for incry=0,0xFFFFFFFF,32do 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.
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
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.
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.
file = io.open("VoidScan.txt","a")file:write("\n-------------------------------------------------------------\n")for incry=0,65536*4,32do 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.
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.
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
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]
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]').
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?
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'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:
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?
Wow, you two seem to be very tech-savvy about this. I feel a bit overwhelmed by your posts
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 Hall of Origin has been found!00510[FFFFFF60,FFFF8720]30,528 steps North and 180 steps West of 430N.That's really close.
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.
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.
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.
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 )
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)
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 script never went south and/or east, but I'll include those directions in a future iteration nonetheless.