• Our software update is now concluded. You will need to reset your password to log in. In order to do this, you will have to click "Log in" in the top right corner and then "Forgot your password?".
  • Forum moderator applications are now open! Click here for details.
  • Welcome to PokéCommunity! Register now and join one of the best fan communities on the 'net to talk Pokémon and more! We are not affiliated with The Pokémon Company or Nintendo.

Development: New map names in FR

62
Posts
14
Years
  • Seen Oct 24, 2013
I am currently trying to add new map names without the need of deleting the old ones. Fire Red as exactly 108 map names.

Using A-Map's World Editor, I found the offset for the map names. I went to Hex Workshop, reversed the offset and found it. It is at address 0x003F1CAC. Names are stored with 3 bytes, followed by a 08. For Pallet Town, it's FCEC3E. Reversing that, it's 3EECFC. That's the offset for the name. If you look that offset using HackMew's Poke Adv Hex table, it will say PALLET.TOWN

I compiled some text using XSE so I could make a new name. This is where I stop. I don't know where to add the reversed offset. This is the normal offset for my text: 80407C, reversed: 7C4080. So in Hex Workshop it should be 7C 40 80 08 but IDK if I could put it right next to the CELADON DEPT. which is 0x003F1E5C and it's stored at 3EF22E.

I hope someone finds a way to add new names for the maps.

PS: Sorry for my english.
 

Giga Universe

Working on a tool.
121
Posts
16
Years
The data at 0x3F1CAC appears to be a table. You can repoint it. Split it up and reverse it, you get AC 1C 3F 08. Search that in a your hex editor. Then find some free space (For an example lets use 800000), and reverse it. In my example that would give you 00 00 80 08. Replace AC 1C 3F 08 with 00 00 80 08. And you have your new table. Copy the old data from 0x3F1CAC to your free space, then add your own offsets. That SHOULD work. I haven't tried it, but it is the general way of repointing...
 
62
Posts
14
Years
  • Seen Oct 24, 2013
I think I tried that but I gonna try again.


EDIT: Didn't seem to work. It ruined my rom's palletes and didn't add the needed names.

I searched for 864 bytes (the double the original tables uses) in FSF then, I pasted it twice so it could have the same names twice. But it didn't work. Lucky me I made a backup.
 
Last edited:

Pokepal17

More cowbell~
1,519
Posts
15
Years
Repoitning won't work because it's not just a name. It's a lot of data with each map name including a value which places it on the worldmap. This is gonna take a lot of ASM to work out.
 

Full Metal

C(++) Developer.
810
Posts
16
Years
err...has anyone even began to listen to what Lu-Ho is saying? Really though, he's said it about a million times (sorry for having you repeat it again for me a while back...lol?) and he's even said he's looking into a way around it i think but that could be my memory playing tricks on me again...
 
62
Posts
14
Years
  • Seen Oct 24, 2013
I found a temp. way of doing it. I went to A-Map general INI. It said AnzMapNamen=109 in BPR. My german isn't very good but I think that means number of map names. I changed it to 110 to test it. Once I open a FR Rom it showed a error. It said '$3F1E60 isn't a valid pointer!' I went to Hex WS and went to that address. It's right after the names table. I thought I could try it out, so I inputed a free offset and wrote text in that same offset. It went all good, I have the new name. The problems are:

In A-Map's World Map Editor, the value C5, which was before to the Empty/Don't display now belongs to the new name.

You can't choose Empty/Don't Display.

If you make a map with the newly created name and put its name to appear when you enter, the name box will be blank.
 
Last edited:

LU-HO

Author of AdvanceMap
243
Posts
19
Years
As i say mani times bevor.
this value "C5" is used on many ASM Routines to limit the number of names.
it check if number is smaller then c5 than do ASM work, else exit...

so you have to change this C5 -Check on each ASM routine that use name-Indexes.
and also you have to change the whole C5's on worldmaps and other data.

i do not find all ASM routines, and all Data using these namepindex, so i cannot finish a insert routine for it...
 
62
Posts
14
Years
  • Seen Oct 24, 2013
Thanks for that information. How many routines did you found?

I went a little deeper, and found some logical information xD, that C5 is the limit and 58 is the beggining. C5-58=6D=109, those 109 map names, and so if we could change the C5 to 132 (the double) maybe and then, as LU-HO said, we would change the C5 value on the worldmap to 132. Maybe that should work. All we need is find the missing routines. Maybe I can follow a tutorial somewhere about ASM routines, 'cause, like I said before, I s**k at ASM.
 
Last edited:

NarutoActor

The rocks cry out to me
1,974
Posts
15
Years
No, it's not about space with hex. It's about the amount. There are multiply asm routines that check the amount, and if the amount is not correct the game crashes.
 

Darthatron

巨大なトロール。
1,152
Posts
18
Years
I sat and looked at this post for forever, and BAM!

The ASM routine(s):
As you said, when it checks the amount of map names, if that amount doesn't match up to what's in the routine/routines, the game will crash, right? Well, what if you change the amount of names that ASM routine(s) looks for? That way, you can expand the table, and the routine(s) will match it properly. I wouldn't know where to look, but do you think that ASM routine/ those ASM routines could be modified?

EXAMPLE (note, I'm making an example, NOT writing out an entire ASM routine, as I don't know ASM)
Code:
Amount to look for: 9F:Map Name 128
Change the routine to do this:
Amount to look for: AA: Map Name 138.
Wouldn't that work?
Of course that will work. It's finding (ALL of) the routines that we are having trouble with.
 

Full Metal

C(++) Developer.
810
Posts
16
Years
so....
here's an idea
cmp rx , #0xC5
blt : PTR @i think that's "branch if less than, but i have no honest clue, but that is what it's supposed to be in my mind of crazy...
assemble that into a binary file
remove the : PTR part from the end (which should be only 2 bytes) since thumb uses shorts for it's commands/arguments afaik.
then in HW continuously search for those matching values and then debug at that area and see if it's accessed at all when messed around with the world-map or map-loading procedure. I honestly have no idea if thats possible, or which register to check though. lol i'm blubbering again, but i'm trying to contribute :D
 

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
BIG EDIT: The limiting byte for the routine is located at 0x080C4D8A! The byte stored at this location is 0x6C. The sharper minded of us with have deduced that 0x6C = 0xC4 - 0x58. (Where 0xC4 is the highest allowed header in A-Map and 0x58 is the difference between Pallet Town's A-Map header, and it's "true" header in the FR rom.)

(Side note - All FR maps were created relative to the RSE maps, so as not to cause confusion between the games when traded Pokémon are viewed. The Relative map header number for Pallet Town is 0x58, but it is treated by the game as map header 0x0 - and as such, all maps are read following that order).

The actual routine itself is as follows (There's obviously much more to it than that, but it isn't relevant for this as far as I can tell):
Code:
cmp r5, #0x6C
bhi $080C4D40

This leaves us with a slight problem. Without a rewrite (OK, I could do it, but it'd take a while) there is no way to support more than 0xFE (254) map headers at any time. This means that we will NOT be able to have multi-region hacks.
My idea for having more than that is to use something similar to the following code to do the work for us:

Code:
push {r5}
cmp r5, #0xFF
bhi greater
pop {r5}
[Rest of Original Routine...]
 
greater: mov r0, #0x1
lsl r0, r0, #0x8
sub r5, r5, r0
lsl r0, r5, #0x2
cmp r5, #0xFE
bhi return
pop {r5}
[Rest of Original Routine...]
 
return: pop {r5}
[Return to Original Routine]

This would allow support for 0x1FE (510) map headers, which should be more than enough. Obviously, the cmp r5, #0xFE in the greater routine now contains the limiting byte, so it could still be limited to as few as you like.
This has NOT been tested, and I wouldn't suggest trying it yet without backing up your rom as I still need to do some serious research to see if it'll work.

However, this only takes into account the actual names, and not the positions on the map and such, so this still needs a LOT of research. There are at the very least 8 routines which will need modified to support extra maps.
Name Reading (2 versions of), Position Reading (Layer 1), Position Reading (Layer 2), Map Flags (Layer 1), Map Flags (Layer 2), "Map number on World Map" and "Head Moving on Map", which means there's a lot of work to go yet XD.

Theoretically, they should all be simple enough to actually track down, going backwards from the reading of a piece of data in the rom, but these are only the ones we ACTUALLY KNOW ABOUT! Who's to say there isn't more data which is read from somewhere that we can't find. All of the routines mentioned above can be found by looking at the World Map Editor on A-Map, and tracking the read of the data on A-Map back to the limiting byte.

On the plus side, they are designed exactly the same way as all other limited routines in FireRed, with a simple byte controlling how many we can have, so in theory, with some repointing and some rewriting, we can have as many map headers as we like (well, up to 0xFFFFFFFF - as if the rom has enough free space for that XD).

Incidentally, the layer 2 map flags are the problem behind the red text with white background on most hacks for secondary locations, as for some reason, that's how they're displayed unless they have a flag associated with them.

I'm really struggling to find the limiting bytes for the layer reading routines. Maybe I could contact Lu-Ho for some information, or read the A-Map inis?

The following bytes are only read while either accessing the world map or accessing the map names for display. Game Freak have consistently used R0 throughout here making compares with 0xC5 or 0xC4 (etc) relatively easy to find. For the first one, a "better" way to make it work is to change the bytes preceding the check to this:

Code:
0D 0C 58 3D 09 0C C4 29
At 0x080C4D84. This changes the map name reader into the same format as the rest of the routine, making it more compatible with the rest of the routine, and any extra map names we manage to add.

FOUND LIMITING BYTES:
Name Reader: 0x080C4D8A (0x6C)
Map Header on World Map (For Sevii Islands): 0x080C0080 (0xC5)
Map Header on World Map (For Sevii Islands): 0x080C00CC (0xC5)
Name on World Map: 0x080C0B32 (0xC5)
Name on World Map 2: 0x080C067A (0xC5)
 
Last edited:

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
So, are you saying here that we cannot have more than FF (255) maps or map names unless it can be expanded?
Without rewriting the routine in a fashion similar to what I have above (Obviously, that's just a small example of what we'd need to do, not a full routine), we cannot have more than 0xFE (254) maps (as there needs to be a null map for the routine to work).

I forgot this when I posted that info last night, will modify momentarily.

We CAN have more than that, but it'd require substantially more work.

EDIT: First test, modified the limiting byte at 0x080C4D8A to 0x6D and repointed the various tables. On entering a map with 0xC5 as it's header (the previous upper limit) it correctly loaded a tester name. However, the world map simply crashes upon an attempt to load it, so I've clearly missed something important out. (Obviously, I also upped the limiting bytes for the world map routine too).
 
Last edited:

linkandzelda

Ex-rom hacker turned indie game developer
777
Posts
17
Years
I'm not sure if this is anything not note but, I was able to add 1 extra map name and get it to display and work in-game. This was by changing 1 or 2 limiter bytes and repointing the 3 tables. That was just to get it to display, hadn't even thought of the World Map yet...
 

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
I'm not sure if this is anything not note but, I was able to add 1 extra map name and get it to display and work in-game. This was by changing 1 or 2 limiter bytes and repointing the 3 tables. That was just to get it to display, hadn't even thought of the World Map yet...

Yeah, that's what I did, but I clearly missed something important in the world map loading routine because it just crashes upon an attempt to access it. Music continues to play, but it doesn't actually load the world map. I think it gets stuck in an infinite loop, so I probably made a mistake. It's hard to repoint a table when it's not immediately obvious when it ends (like the world map position bytes, as the table ends in a bunch of 0's which may or may not actually be connected to it).
 

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
couldn't you just use the emty headers e.i. route 4, route 10, tanoby key etc.

P.s that means some 108+ map names in emerald

They're used for flight spots in FR. So sadly that isn't an option without sacrificing those particular flight spots, and even then, only gives us an extra 2 or 3 map names to play with. What if someone needs something of the order of 20 or 30? Currently impossible... :(
 
94
Posts
13
Years
  • Seen Nov 2, 2016
Map headers, may or not all be relevant to the routine but these all concern the values talked about, and are near the routines Jambo mentioned.
=========================
1. All the ones found by Jambo are FOR SURE limiting bytes.
2. String of stranges compares and moves and lsls at 080C26B0..two of the documented are found there.
3. Most important are C5 and 6C, for that reason I'm also searching for C4, cC6, 6B, and 6D.
4. No feasible compares or copies of c6 found.

These are close to the map-header functions area.
Spoiler:


These are not close to the routines, but in the ROM as a whole.
==============================================
1. 6B is never used as an immediate.

Spoiler:
 
Last edited:

Jambo51

Glory To Arstotzka
736
Posts
14
Years
  • Seen Jan 28, 2018
This post contains all the needed offsets and steps required to extend the number of available map names.
You can now have a maximum of 0xFC map names, which is a vast improvement on the previous number of 0x6C.
You MUST leave 1 map name byte (0xFD) for the background in the World Map, and the other 2 (0xFE and 0xFF) are needed to maintain support for trading with RSE. Currently, without a fairly drastic rewrite of the routines and map headers, it is impossible to support any more map names than 0xFC (253).

Anything in normal type is for a simple extension after the end of the existing map names, that is, using 0xC5 - 0xFC.
Anything in bold type is for using map names 0x0 - 0x57. This requires some thinking to implement!

Limiting Bytes:
Spoiler:

*0x080C0BEC sub r0, #0x58; This needs to be removed to fix name loading.

In order to extend the table to include values below 0x58, there are MANY steps required, including some ASM.

World Map Location Data:
Spoiler:


World Map Movement Bytes:
Spoiler:


Flight Data Controller Data:
Spoiler:


Names data:
Spoiler:


World Map Flag Data:
Spoiler:
 
Last edited:
Back
Top