I tried modifying that data and nothing changed. Perhaps it's only used for debug screens, or something...

The overworld map layouts are dictated by the map model and its animation file (wX_move.nsbca). Try swapping some of those animation files around and see what happens.

Edit- one potential way of finding how level IDs are assigned, could be to trace changes to the tile numbers of OAMs 2 and 3 (those show the level number).

Also, I found several addresses that contain the current world ID: 2088BFC 2088C1C 21C5774 27E37B8 20EE3BC
Changing 2088BFC while the game is running causes the world transition to be done, but you stay in the same world.
Changing 2088C1C or 21C5774 has no effect.
27E37B8 can't be changed (the game reverts it instantly).
Changing 20EE3BC sends you to another world.

(world IDs start at 0 so for instance world 2 is ID 1)
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

w1.nsbmd probably contains references to the joints in w1_move.nsbca. IIRC those joints are used to determine where levels are etc...

But yeah, if you try to swap the files around, levels are still the same etc... a part of the data is in overlays.

To get an idea of what those RAM locations belong to, let's see what RAM addresses each overlay spans...
* overlay 0: 0x020986E0 - 0x020CC2E0
* overlay 8: 0x020CC2E0 - 0x020F1700
* overlay 11: 0x0212B160 - 0x0212F900
* overlay 54: 0x02152840 - 0x021726C0


I took overlay 8 and opened it in IDA. The data ELMario found (the thing with level pseudonames) is used by the function at 0x020E112C. It is computing a pointer to one of the entries, and then passes it to a function in main RAM...


Edit-
I attempted looking for certain values in RAM while navigating the world 1 map.
2085A9C and 2088C04 vary as you navigate the map:
* starting point: 13, 0 (hex)
* W1-1: 1, 1
* W1-2: 2, 2
* W1-3: 3, 3
* following node: 14, E
* W1-Tower: D, 4
* too lazy to continue

21C5748 varies in the same fashion as 2088C04.

Modifying 2085A9C changes what the WX-XX HUD elements say, but doesn't change the map node's destination. (for example if you change it from 3 to 2 the HUD will say W1-2 but you'll enter W1-3)
Modifying 2088C04 changes the map node's destination but has no effect on the HUD. (if you change it from 3 to 2 the HUD says W1-3 but you'll enter W1-2)
Modifying 21C5748 has no effect.

Finding how 2088C04 is used would be interesting. Probably it is used as an index into a table that describes the map's path nodes.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

I'm doing that research to find out where the level IDs and such are stored, and how the game maps path joint IDs (or whatever they are) to level IDs.

That 2088C04 is interesting. Its values are dependent on the map being navigated, which suggests that there is one different table per world.
Also, while on world 2, I tried changing it to 0x16 (out-of-bounds on purpose), and that led me to... W6-1. So those tables aren't stored sequentially.

R1 = [2088C04]
R0 = R1*0xC + R2 (R2 = 20E74D4)
R3 = halfword[R0 + 8]
store R3 somewhere
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij

The positions of the nodes are dictated by the model and its animation file.

Also, I wonder how the path on the bottom screen is determined. I'll be looking into that today... unless there are more sekrit docs?

I did some more research, and found some kind of master table at 0x020E79C4. There are 40 bytes per entry, one entry per world starting from world 1.
AA AA AA AA BB BB BB BB CC CC CC CC DD DD DD DD EE EE EE EE FF FF FF FF GG GG GG GG HH HH HH HH II II JJ JJ KK KK KK KK
A: pointer to node data. Affects nodes' destinations, the location of Mario on the minimap, and the colors of mushroom houses.
B: ??? 4 bytes per entry, modifying this can warp path animations weirdly. Possibly related to wX_move.nsbca
C: ??? 4 bytes
D: 24 bytes per entry, one entry per node. Affects the way path nodes are positioned visually. Has no effect on Mario's moves or the nodes' destinations or the minimap.
E: ??? seemingly 4 bytes per entry, one entry per path
F: ??? 48 bytes. Seems to affect castles/towers
G: ??? 4 bytes per entry. Affects the way mushroom houses are placed visually.
H: ??? points to other pointers and stuff, size unknown
I: number of nodes (entries in tables pointed by A and D)
J: number of entries in table pointed by B
K: always zero

I should scan overlay 8 to find out where code and data are, and if the overworld data can be expanded easily. If code has to be moved, expanding it is going to be tricky. Otherwise, we just have to make sure to not move the master table, as well as potential other data pointed externally. Also the data can't be expanded past the maximal size allowed by the overlay slot. If the limit is too small, we'll have to steal some RAM from the game to add an overlay slot. I did that for SM64DS. Actually SM64DSe does it automagically, but finding the offsets to patch can be tricky, let alone doing it for multiple ROM versions. One thing is that NSMB has a table that keeps track of which overlays are loaded. SM64DS has the same thing. And I found out that when you add an overlay slot, when all the original slots are busy, the table gets full and bad things happen. I had to move the table inside another table that I didn't need anymore, and patch some code to allow more overlays to be loaded. So yeah it isn't that easy.
_________________________
Kuribo64 - RH-fucking-cafe - Kafuka

zrghij