News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Windhex - Sorry ... The string was not found. (Help!!!)  (Read 24872 times)

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #20 on: February 05, 2012, 01:30:57 pm »
I said it quite clearly: your table file should include "/FF=<END>". It doesn't belong in the command file. Good catch on the pointers, though.

Anyways. If your ROM is "firered.GBA" and your command file is "firered_commands.txt," then yes, your batch file should be good to go. The "-m" tag at the end means "multiple" - if you had multiple blocks defined, they would each have been dumped to a separate text file (without it, everything would've been dumped to just the one). The output should be "firered_script_000.txt".

But what about your table file? You have finished filling that out, right? Capital letters, punctuation, and whatnot? Don't forget to identify the "placeholder" tags and things like linebreak codes.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #21 on: February 05, 2012, 02:19:32 pm »
Quote
But what about your table file? You have finished filling that out, right? Capital letters, punctuation, and whatnot? Don't forget to identify the "placeholder" tags and things like linebreak codes.

Not yet. I've hit (almost) all the symbols that show up in the "what's your name?" -window in the beginning of the game (upper and lower case letters, numbers, punctuation) as well as the dollar sign. I'm just missing the backslash, which I can't find anywhere in the dialogue and can't figure out where it should go in the table. It could be B9, as I'm missing that value, but I'm also missing BA (and BB is capital A, and I can't figure out for the life of me what should come before capital A).

Regarding the placeholder tags and what not, how do I represent those in the table? The "pokémon name" tag is apparently FD02 (in the battle screen however it appears to be FD0F...), but how do I specify in the table what it is for? For example for capital letters A, B, and C, I have them represented with their values using an equal sign (BB=A, BC=B, BD=C, etc.) but what do I put next to FD02? "FD02=????" Or is it okay to just put FD02 in the table by itself without specifying what it does?

Also, I haven't found these symbols in the dialogue so I can't be sure if this has an effect or not, but the game also includes the symbols ♂ and ♀, for which I have found (read:made an educated guess) the corresponding values (B5 and B6), but when I put them in the .tbl file notepad complains that in order for these characters to be displayed properly, I need to save the file using Unicode instead of ANSI, but if I do that, WindHex isn't able to read the table (and instead displays everything as a period). If I save the file with ANSI however those symbols turn into question marks. What do I do about this...?

Also, is it possible that there is more than one linebreak code? Usually I see FB, but I could have sworn I saw FE being used for the same purpose somewhere...

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #22 on: February 05, 2012, 02:41:10 pm »
Put down special codes in the table as tags, like with "<END>". Just make sure there's something descriptive between the pointy brackets, like "<NAME>" or something. If you have multiple that do similar things, you might use, say, "<LINE1>" and "<LINE2>".

WindHex is a little stupid when it comes to Unicode characters - it's not your fault, it's the program's. You can use a workaround, though, like marking them as "<MALE>" and "<FEMALE>" in the table.

Finally, if you're still having trouble figuring out all the character codes, try opening the ROM in a graphics editor like Tile Layer Pro or Tile Molester and searching for the game's font. It should - should - be arranged in the same pattern as the table.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #23 on: February 05, 2012, 03:48:08 pm »
Um... I kind of have an extremely odd problem that I have no idea how to account for. :laugh:



I've already established FD01 is the "player name" tag and the above screenshot demonstrates that. However, in battle, this same tag is used where the enemy trainer's pokémon's name should go:



...  :o
(you can also see the "rival name" tag (RNAME) being used where a safari zone pokémon's name should go)

Well, I've already kind of noticed that tags used in battle and tags used outside of battle are independent of each other (or something like that). The (player's) pokémon name code for example is FD02 outside of battle, while in battle it is FD11 in most instances, otherwise FD0F (I think). So even though it looks like the same FD01 for example is being used for 2 different things, we're really looking at 2 different tags... one for battle and one for other dialogue, FD01* and FD01** perhaps. Is there any way though to indicate this difference in the .tbl though? Or is it okay to have this sort of mix-up in the sense that I can fix it manually after the text has been dumped (don't know how I would do that though)?

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #24 on: February 05, 2012, 05:34:57 pm »
The actual meanings of the placeholders might be contextual - they might print different things depending on what's supposed to be displayed on screen. At any rate, as long as they're consistent between your translated script and the original script, you shouldn't have any trouble, regardless of what you actually label them.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #25 on: February 05, 2012, 07:14:06 pm »
Hmm... I don't know what to say, but Cartographer still won't dump the script. I double-click the .exe and get this window for a split second:



But nothing! Is it possible the firered_script_000.txt is being dumped in some other folder? That'd be really bizarre... my computer doesn't have a working search feature either (yay Windows 7) meaning I can't search for any scripts that have possibly been dumped elsewhere.

I did take /FF=<END> out of the command file and put it in the table. Here's my command file again:

Code: [Select]
#GAME NAME: Pokemon - Fire Red.GBA

#BLOCK NAME: Script
#TYPE: NORMAL
#METHOD: POINTER_RELATIVE
#POINTER ENDIAN: LITTLE
#POINTER TABLE START: $3FDF3C
#POINTER TABLE STOP: $3FE514
#POINTER SIZE: $04
#POINTER SPACE: $00
#ATLAS PTRS: Yes
#BASE POINTER: $F8000000
#TABLE: table.tbl
#COMMENTS: Yes

#END BLOCK

And the .bat file:
Code: [Select]
cartographer firered.GBA fr_commands.txt firered_script -m

pause

(I changed the name of the command file, even though in the screenshot it still shows up as firered_commands)

And yes, the name of the ROM and the command file match up with what's in the .bat .

I put /FF=<END> at the very end of the table, like this:
Code: [Select]
... ... ...
FD20=<FOENAME2>
FD21=<FOENAMETWIN>
FD23=<PLAYERB>
FE=<LINEB2>
/FF=<END>

Ideas...?

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #26 on: February 05, 2012, 07:23:28 pm »
You're double-clicking the .exe, which is the same as trying to run it from the command prompt without arguments.

Double-click the .bat.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #27 on: February 05, 2012, 08:16:40 pm »
You're double-clicking the .exe, which is the same as trying to run it from the command prompt without arguments.

Double-click the .bat.

WOWWW what a blonde thing to do  :laugh: And I'm not even blonde.

Okay, well I just ran the .bat and Cartographer barely dumped anything, in fact it dumped only the battle text and nothing else. It went all the way from $3FDF3C to $3FE510 but didn't get any dialogue, just stuff like //<PONAME2> is paralyzed!<LINEB2>It can’t move!<END> , etc.

Is it possible for there to be more than one pointer table? One for battle text, one for dialogue, etc?

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #28 on: February 05, 2012, 10:15:13 pm »
Oh definitely yes. Breath of Fire's got six that I've found; Sylvanian Families had something on the order of fourteen.

For each of 'em, you'll set up a block in the command file, like you've got already: just copy everything from the "#BLOCK NAME" directive to the "#END BLOCK" (inclusive) and tweak the block name, pointer start, and pointer end as necessary. Might want to change "Script" in your current block to "Battle Text" or something similar, too.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #29 on: February 06, 2012, 11:29:37 pm »
I found another pointer table, which appears to be quite huge. Start value 00012B, end value 1E9F5F. Trying to dump the script with the table causes Cartographer to crash. :\ Is it possible that I might have accidentally included 2 pointer tables in this....? Or is it possible for a pointer table to be this big? I found this table by searching for the hex code of a string in the dialogue, which is of course going to be a lot more expansive than the battle text, which would explain the size...

Start and end strings:


Direct link: http://i6.aijaa.com/b/00282/9518521.jpg

Command file:

Code: [Select]
#GAME NAME: Pokemon - Fire Red.GBA

#BLOCK NAME: Battle text
#TYPE: NORMAL
#METHOD: POINTER_RELATIVE
#POINTER ENDIAN: LITTLE
#POINTER TABLE START: $3FDF3C
#POINTER TABLE STOP: $3FE514
#POINTER SIZE: $04
#POINTER SPACE: $00
#ATLAS PTRS: Yes
#BASE POINTER: $F8000000
#TABLE: table.tbl
#COMMENTS: Yes

#END BLOCK

#BLOCK NAME: Dialogue
#TYPE: NORMAL
#METHOD: POINTER_RELATIVE
#POINTER ENDIAN: LITTLE
#POINTER TABLE START: $00012B
#POINTER TABLE STOP: $1E9F5F
#POINTER SIZE: $04
#POINTER SPACE: $00
#ATLAS PTRS: Yes
#BASE POINTER: $F8000000
#TABLE: table.tbl
#COMMENTS: Yes

#END BLOCK

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #30 on: February 06, 2012, 11:47:17 pm »
You need to pay a bit closer attention to what you're doing - you're finding numbers and going off half-cocked. Kudos for taking my lesson to heart regarding finding the actual start of the pointer table, but take a close look at what comes after: the table in the top screenshot starts at 128 (remember, pointers are little-endian - the telltale "08" comes at the end of each four-byte sequence!) and ends at 150 (the final pointer starts at 14B). There's also a second short one in there running from 1BB to 1D0.

The second screenshot's table starts at 1E9F28 and runs to 1E9F60, as you discovered, though there are a fair number of duplicates: you might want to double-check what's actually stored at those addresses.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #31 on: February 07, 2012, 01:40:20 pm »
You need to pay a bit closer attention to what you're doing - you're finding numbers and going off half-cocked. Kudos for taking my lesson to heart regarding finding the actual start of the pointer table, but take a close look at what comes after: the table in the top screenshot starts at 128 (remember, pointers are little-endian - the telltale "08" comes at the end of each four-byte sequence!) and ends at 150 (the final pointer starts at 14B). There's also a second short one in there running from 1BB to 1D0.

The second screenshot's table starts at 1E9F28 and runs to 1E9F60, as you discovered, though there are a fair number of duplicates: you might want to double-check what's actually stored at those addresses.

I'm not sure I quite understand... are you saying that in those 2 screenshots I'm not looking at one big pointer table, but rather a whole bunch of different, tiny ones? Regarding the first screenshot, are you saying I would need to add 2 different end blocks to my command file, one for the table that runs from 128 to 150 and another for the table that runs from 1BB to 1D0? And then a separate end block for every short table I find in that huge gap from 00012B all the way down to 1E9F5F?

How exactly can you tell that in the first screenshot we are looking at 2 different pointer tables? Okay, so, at line 00000120 (in the top screenshot) the first 08 is the 5th from the right (sorry I don't know the string that would correspond to, I'm at school now and can't open WindHex to check). Because the 08 comes at the end of a 4-byte sequence, I need to count 4 bytes to the left (including the 08) and that would give me the start address for this table. The last 08 is situated 3rd from the right at line 00000160 and this would be the end address. Correct? Then you're saying we have another table start at line 000001B0, 4th from the right. This 2nd table ends at 000001D0 3rd from the right.
My question is, how do you know those are 2 different tables and not one same table? Why do we have one that runs from 128 to 150, and another that runs from 1BB to 1D0, instead of having just one table that runs from 128 to 1D0? How can you tell?
And what about the random 08's floating around in between those 2 tables? There's two at line 00000180, one being 2nd from the left and the other being 4th from the left (unless those are B's? can't tell). Why do those not belong to either of the 2 pointer tables you just pointed out in that screenshot?

If pointer tables are of such small sizes like this, doesn't that mean there are going to be about 500 of them total? D:

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #32 on: February 07, 2012, 03:00:59 pm »
The pointers all have to "start" (or end, from our human-readable perspective) in "08." You're right that there does seem to be a stray pointer at 180; however, it's the only one between the two blocks, and feeding Cartographer a non-pointer to dump from will cause it to crash. You'd have to set it to dump as a block in and of itself.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #33 on: February 07, 2012, 07:03:07 pm »
The pointers all have to "start" (or end, from our human-readable perspective) in "08." You're right that there does seem to be a stray pointer at 180; however, it's the only one between the two blocks, and feeding Cartographer a non-pointer to dump from will cause it to crash. You'd have to set it to dump as a block in and of itself.

I still don't get how to tell where one table ends and another begins? How did you know just by looking at that top screenshot that there were 2 tables there? I'm guessing this is what you are trying to tell me is there:


But how did you know that those are 2 separate tables and not just one table? Is it because of the "gaps" in between? By that I mean there's no 08's at all on lines 00000170 and 00000190. And those 3 stray 08's that I circled (one of those might be a B actually)... okay, you know they're not part of a table because...? What do you mean "it's the only one between the two blocks"? Sorry, totally lost again...

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #34 on: February 07, 2012, 07:27:38 pm »
You got it. They can't be pointers because they're not GBA ROM addresses. And if you try to dump them, Cartographer will crash.

Just FYI, the pointers will also be aligned on multiples of four, so not just any 08 will denote a pointer. So the four bytes starting at 180 are likely a pointer; the sequence starting at 1A4 definitely isn't.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #35 on: February 07, 2012, 10:30:15 pm »
NOOOOO! I just wrote a long message and accidentally backspaced out of the window, and it got deleted. D:

Okay in short, I was asking what you do when the pointer table for something just doesn't seem to exist? D: The problem is this block of text here:



Starting with "OAK: Oh, for Pete's sake..."
(The "I'll do my best!" line before that is part of the battle text block that I already dumped)
Whenever I search for the start address of any of the strings in this part of the dialogue ("OAK:", "the TRAINER", "But rather", etc.), I get taken to a "table" that looks like this:


As you can see, there's a handful of 08's floating around there, but they're all stranded from one another and have no other 08's in their immediate environment. For example, the 08 I have highlighted has 1 line above it with no 08 in it and 4 below it with no 08. And we just established that it's not a pointer table if it has gaps in it like that, right? :\ But whenever I search for the start address of any string in Oak's dialogue here, I get taken to a table like that.

What do I do? There's got to be a working pointer table somewhere where this text is stored, right?

Also, can you explain why, when I try to dump this table, Cartographer crashes:


This is one of the few strings in Oak's dialogue there in the first screenshot up top that seemed to return a valid table. There's an 08 on every line and they're aligned in multiples of four. Yet this table crashes Cartographer. What gives?

Here's the block code for that table:
Code: [Select]
#BLOCK NAME: oak1
#TYPE: NORMAL
#METHOD: POINTER_RELATIVE
#POINTER ENDIAN: LITTLE
#POINTER TABLE START: $E8580
#POINTER TABLE STOP: $E85BF
#POINTER SIZE: $04
#POINTER SPACE: $00
#ATLAS PTRS: Yes
#BASE POINTER: $F8000000
#TABLE: table.tbl
#COMMENTS: Yes

#END BLOCK

Normmatt

  • Full Member
  • ***
  • Posts: 140
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #36 on: February 07, 2012, 11:11:35 pm »
Also, can you explain why, when I try to dump this table, Cartographer crashes:


This is one of the few strings in Oak's dialogue there in the first screenshot up top that seemed to return a valid table. There's an 08 on every line and they're aligned in multiples of four. Yet this table crashes Cartographer. What gives?

Here's the block code for that table:
Code: [Select]
#BLOCK NAME: oak1
#TYPE: NORMAL
#METHOD: POINTER_RELATIVE
#POINTER ENDIAN: LITTLE
#POINTER TABLE START: $E8580
#POINTER TABLE STOP: $E85BF
#POINTER SIZE: $04
#POINTER SPACE: $00
#ATLAS PTRS: Yes
#BASE POINTER: $F8000000
#TABLE: table.tbl
#COMMENTS: Yes

#END BLOCK

That would be because after the first pointer the next 4 bytes aren't a pointer and cause reads outside the rom to occur aka crashing cartographer. You need to seperate the dump into 4 seperate blocks each one 4 bytes long just enough for each pointer nothing more.

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #37 on: February 07, 2012, 11:15:31 pm »
Normmatt's got it summed up. The pointers are "stranded," if you will, in the middle of other data - quite possibly ASM code, in fact. You'll need to either define these as separate blocks, or else dump the script in "raw" mode (which requires you to provide the start and end addresses of the text to be dumped, rather than the pointers to it) and insert the pointers into the dumped script manually.
In the event of a firestorm, the salad bar will remain open.

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #38 on: February 07, 2012, 11:57:09 pm »
That would be because after the first pointer the next 4 bytes aren't a pointer and cause reads outside the rom to occur aka crashing cartographer. You need to seperate the dump into 4 seperate blocks each one 4 bytes long just enough for each pointer nothing more.

Oh my gosh that's going to take foreverrrrrr if I have to make a separate block for every single stranded 08 in the dialogue.  :-\

Normmatt's got it summed up. The pointers are "stranded," if you will, in the middle of other data - quite possibly ASM code, in fact. You'll need to either define these as separate blocks, or else dump the script in "raw" mode (which requires you to provide the start and end addresses of the text to be dumped, rather than the pointers to it) and insert the pointers into the dumped script manually.

Dumping the script in raw mode sounds like a good idea. So I gather the start and end address of a single string, right? Then what do I do?

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #39 on: February 08, 2012, 12:12:47 am »
Double-check the Cartographer readme. You'll have to change the settings listed in the block. Alternately, open up the FF1 command file that came with it; there are two example blocks, one pointer-relative (like you've been using) and one raw.
In the event of a firestorm, the salad bar will remain open.