The Communal To-Do List


#128

That feature contains many cool beans. I approve.


#129

Totally going to use this in EN. Great stuff!


#130

Binding it to Select turned out to be simple (for FE7, at least). If anyone wants to try it out, just write 05 F0 F8 F8 2A E0 to $1C3E0. FE8 doesn’t seem to use the Select button so I had to improvise a bit. The FE8 patch is working but not ready for release.

The problem is that calling the routine with select instead of the menu does something to screw up the minimugs. Notice that in the two screenshots I had before, info windows like terrain and unit data are disabled while enemy range is active.
Now we get this:


#131

Can you write a brief description of how the binding works? This is something I’ve not known about how to do.


#132

Sure, it’s simple enough. I started with a break on read on the IO pointer (0x08B857F8 for FE7, 0x0858791c for FE8).

Right below the break you can see what it’s checking for (AND 0x1 checks for A button, AND 0x4 checks for Select, AND 0xF checks for A+B+Start+Select). From there you can do whatever you want after the branch.

For FE8 it was harder because there is no check for the Select button. So I changed the Start check to Start OR Select, and checked which one it was later.


#133

…Wait, what? Why are those ROM pointers instead of being in the IO block (0x04xxxxxx)?


#134

Because in order to check the IO block, the routine must first
ldr r0 =#0x8b85748
ldr r0, [r0]
to get the RAM address where key inputs are stored (0200:0000 region). As for why it checks there instead of directly from the 0400 region, I don’t know but probably because there’s a difference between key press, key hold, and key release.


#135

the key pointers are copied from 0400:xxxx to 0200:xxxx every mainloop cycle for a reason i couldn’t figure out


#136

It might be because of some quirk of how the IO hardware actually works

or maybe it’s just to make debugging easier idk

As for the extra level of pointing via the ROM, probably because it was written in C and the compiler didn’t optimize something very well.


#137

This may be too ambitious but I think it would speed up things a lot faster if someone expanded the data to include all characters and classes from the GBA games into one FE7 or FE8 rom. I simply stopped work on my game because I screwed all the hex up. Had all my characters, faces, items, classes ready from the GBA games I just couldn’t expand my rom right. I’td be awesome if people good at adding that data with hex editor could collaborate into one super rom with all those characters and stuff so we all can all start our hack using it as our base rom. Of course if you need more than all the GBA content you could always expand it again but I’m sure some of us hate adding Marth, Roy, even a custom Ike into our every hack we make and expanding the character data wrong.

Point is several of us could all work on inserting tons of classes and characters on one rom and making it available to all as a “starter pack” rom so to speak. If we want Moulder, Roy, Eliwood, Gerik, Bartre, and Myrrh in the same game we download the super rom bc theyre all already in it. With all the expanding already done we can spend more time on other aspects of the game because expanding is nothing but busy work (personally I get headaches when we start talking hex and free space ranges. Of course it may cause issues if it got too big


#138

Yes. Yes we do. Let’s stop doing it.


#139

Lol not necessarily Roy, Marth, Ike. Mainly FE7 on GBA and Sacred Stones Characters/Classes/Items for now at least


#140

Without a lot of other work, there’s no way you’d fit all of the characters.


#141

moving battel background animations? like tree leafs faling off?