Problem with Text Processor using Buildfile method


#1

I must be really stupid but after two hours I have not managed to fix the problem that I have

I’m currently learning abour romhacking following the “ultimate-tutorial-2”, but I’m stuck in the section insert text. I understand a bit how the thing works and I have been trying to change some names:

I wrote the .txt file with the pointer of the text to change (these are for iron sword name and item description from FE7).

#0x3f3 
Cheap blade[X]

#0x279
This doesnt work.[X]

And added #include "Install Text Data.event" to the buildfile.

#include eastdlib.event
ORG 0x1000000

#include ".\text\Install Text Data.event"

I wrote the changes to the rom and event assembler says that all its fine.
The problem its that when i launch the rom, nothing changes.


#2

Do you have a file named “textbuildfile.txt” in the same folder as your textprocess.exe or textprocess_v2.exe file? That file dictates what text data the processor should be processing. For example, mine is set up like this:

#include "Other/Brown Box Text.txt"
#include "Other/Character Names.txt"
#include "Other/Chapter Names.txt"
#include "Other/Class Names.txt"
#include "Other/Descriptions.txt"
#include "Other/Item Names.txt"
#include "Other/Item Descriptions.txt"
#include "Other/Battle Death Quotes.txt"
#include "Other/Status Objectives.txt"
#include "Other/Misc Text.txt"
#include "ChapterTexts.txt"

Once you have your textbuildfile.txt set up properly and are #include-ing all the different files you want to insert into the game, then the textprocess.exe will work properly.


#3

@FPzero I don’t think they need to do that if they only have one file to process.

What does Install Text Data.event look like?


#4

Yes, my file its called "text_buildfile.txt, also the content of Install Text Data.event is:

#include "Tools/Tool Helpers.txt"
#include "Text Definitions.event"

TxtData0x3f3:
#incext ParseFile "_textentries\0x3f3.txt"
setText(0x3f3,TxtData0x3f3)

TxtData0x279:
#incext ParseFile "_textentries\0x279.txt"
setText(0x279,TxtData0x279)

#5

Well it looks like the processor is working fine if the Install Text Data.event file has stuff in it. You are telling your ROM Buildfile to #include that file, right?


#6

Yes, my ROM Buildfile text is:

#include eastdlib.event
ORG 0x1000000

#include ".\text\Install Text Data.event"

#7

Well, that looks correct.

Stupid questions time!

  1. Did you assemble to the correct rom, and if yes, are you checking that same rom?
  2. Did you modify the right text ids?

#8

Yes, i use a MAKE HACK.cdm and yes, I have tried different ids from objects, descriptions of objects and characters. On the other hand when I make a writing error in the fileInstall Text Data.event the assembly fails.

EDIT: Also, i checked the rom with HxD and the data is in the rom.

EDIT_2:

The ids i tested were:

  • 0x3f3 (iron sword name).
  • 0x279 (iron sword description).
  • 0x537 (Limstella name).

#9

If the text is in the rom, then the issue must be that the pointer to the text wasn’t updated. That’s what the setText macro is supposed to do, though… I’m not quite sure what went wrong. Is the text table in the same place as in a vanilla rom? Based on the fact that you said you changed Limstella’s name, I’m going to assume you’re working with FE7. If so, what pointer is at 12C88? It should be B808AC.


#10

Sorry, i’m a little new with this and i get lost with the second part. What is the “text table”? Can you explain it to me please?

I have a folder called tables where i have the nightmare modules to make changes in characters, items but… Also i made some other changes in things like music, units and all work fine.

EDIT: I checked the modified rom using HxD and searched in the offset 12C80, i found “B8 08 B4 A5” but im not sure if you are refering to that.


#11

12C88, not 12C80. It’s actually a text pointer table; given a text id, say, 0x3F3, the function multiplies this by 4 (because pointers are 4 bytes long) and adds it to the text pointer table to get a pointer (in this case, it should be 0x9000000 since that’s where you assembled your text to) to the text itself (Iron Sword).


#12

Well, i checked again and this is what i have:


#13

Have you installed anti-huffman? It doesn’t seem so.
Include this into your buildfile. You’ll need this, but that wouldn’t fix if there’s an issue with the text table.


#14

No, I do not have it installed. I tried to put it but when I started the rom, it showed me a black screen, I researched a bit about the problem but I could not fix it.

I have also tried to open the rom by FEditor to see the status of the modified texts, and these remain unchanged.


#15

The pointers must not have been updated, then. Check 0xB808AC + 4*0x3F3 = 0xB81878.


#16

This is what i have:


#17

Looks like the pointer didn’t update. Question is, why? As I said, the setText macro should take care of that for you…

Out of idle curiosity, if you open Tools/Toll Helpers.txt, what’s the chunk of code that defines TextTable look like? It should be on line 15 and look like this:

#ifndef TextTable
    #define TextTable 0xB808AC
#endif

If this is correct, all I can think of is to assemble again and see if anything’s changed.


#18

Here i think everithing is correct:

#ifdef _FE7_
#ifndef TextTable
    #define TextTable 0xB808AC
#endif
#ifndef PortraitTable
    #define PortraitTable 0xC96584
#endif
#endif

Thats why im lost, I also assemble the rom every time I make a change.
As i said im new into this so this maybe sounds stupid but the pointer at 12C88, its “AC08B8”, so its the same pointer that you told me before but reversed.


#19

Right, stuff in the rom is written in little endian, meaning the bytes are written in reversed order (the “most important”, or highest, byte appears at the end). So 08B808AC will appear at AC 08 B8 08, as you can see.
I really dunno what’s going on, though; everything seems to be set up correctly. What version of EA are you using?


#20

Im using EA v11.1.

Also, i started to read about inserting mugs and they dont show, maybe its because im doing something wrong since i readed it a little bit fast this morning but maybe its related with this problem too.