[Hiei-]

About Lufia 1 :

http://www.hiei-tf.fr/Lufia1_ASM-Hack_Expanded_MTE_dictionaries.zip

If someone want to use those modifications, feel free to do it. Read the texte file of the ZIP archive for more details (Address of the MTE dictionnaries, how to calcul the pointers, etc...).

It can be useful if you want to translate the game in a foreign language and plan to use the german tools, to have more room for your translation (once you used the original MTE dictionnaries of the game, 256+64+16 (336) entries if you ignore the caps mirroring, you'll still have 256 entries left for your translation

The original game have 4 compression dictionnaries :

- One offering 16 entries (10-1F in the .tbl file)

- Another offering 64 values (80-BF in the .tbl file) and the same values mirrored to C0-FF in the tbl file (with the first letter in caps for C0-FF values).

- A last one offering 256 values (0C00-0CFF in the .tbl file) and the same values mirrored to 0D00-0DFF in the tbl file (with the first letter in caps for 0D00-0DFF values).

Basically, with the modifications of the IPS patch, the game (automatically expanded to 2 MB) now have :

- One offering 16 entries (10-1F in the .tbl file), but you can put longer entries if you need to. I know the game accept, at least, 14 characters entries, but it can accept probably more. You'll have to try to know the actual limit.

- Another offering 128 values (80-FF in the .tbl file), and you can also use longer entries if you need to.

- Another one offering 256 values (0C00-0CFF in the .tbl file), and you can also use longer entries if you need to.

- A last one offering, again, 256 values (0D00-0DFF in the .tbl file), and you can also use longer entries if you need to.

If some peoples are interested by the log of the modifications, just ask and I'll post it.

[Vegetaman]

I am bumping this topic only because I felt like I needed to finish the SRAM guide. But in the time that has expired since I last touched this, I was notified that a RAM map has been updated on the site's wiki by Gendou and Alchemic:

http://datacrystal.romhacking.net/wiki/Lufia_%26_the_Fortress_of_Doom:RAM_map

With this being said... Is there anything that seems missing or unclear on how it works from an SRAM point of view at this point as far as character data? Because it looks fairly covered now. But it is my sincere belief that every treasure chest and secret item in this game must have an SRAM bitfield associated with them, so I was going to put that next on my list of things to track down. Anybody have any good tips on where to start looking for that?

Also I finally got around to playing with those dictionary tools from the .ZIP file. Very, very cool.

[KingMike]

I see only two bytes listed for EXP ("lo" and "hi" byte), but there definitely should be at least 3 bytes per character.

[Vegetaman]

I see only two bytes listed for EXP ("lo" and "hi" byte), but there definitely should be at least 3 bytes per character.

You're quite right -- it would need 3 bytes to be able to exceed 65535 and go up as high as 0xFFFFFF or 16777215... The same as Gold. Perhaps I should verifying and prove/disprove the information on that page and incorporate what I discover into my guide...

Also, in addition to bitflags for chests opened, there would have to be some for story scenarios and bosses beaten as well... If that SRAM code could be cracked, you may be able to pull off some neat stunts (like... a world without bosses). Of course, it may turn out like when I gave the Hero the Elf spell -- turns out that if you go there without Jerin in your party the game locks up like fort knox.

[badinsults]

Sorry about the bump, but I have been trying to extract the script for Lufia 1, and was wondering if there was any new progress on this. I have a prototype of the game which has an unpolished version of the script, and it appears that has a different length, so just applying a direct hardcoded event addresses is not going to work.

I have done some investigation on the dialogue window close bytes (0x04). As far as I can tell, dialogue closing is controlled by two bytes, 0x04yy, where yy is the type of dialogue window closing. For example, 0x046C is for closing a dialogue box in the opening scene (which has no background for the text). I'm guessing the mess before each dialogue is a mixture of information related to the type of background box, the way the text scrolls (automatic or user input), where the text box is display, justification, font type, etc. I haven't fully investigated that yet, though.

Edit: it seems that this is only partially true, because some dialogue closings are three bytes (e.g. for dialogues where the next dialogue is a yes/no option, it is 0x040C20)

Edit 2: As originally suspected, the excess bytes control things like the time the message is on screen and stuff. The game basically loads the script chunk as a subprogram, and the extra bytes contain commands that tell the game how to output the text. So in reality, it is not possible to read the text as one huge chunk with a program like Cartographer. You would need something far more involved, which is probably beyond my skill level.

[Vegetaman]

Wow it's been almost five years and I totally feel I need to go back and update this SRAM document finally. Wow, talk about real life getting in the way.

But very interesting about the message box information, badinsults. I wonder if there are other things contained there, such as pauses or movement information for cutscenes, or if it is truly just text and text persistence time? I think we could figure this out!

EDIT:

Oh geeze it's been 6 years almost. Yikes.