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

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

C_CliFF

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
    • General CoolNES Translations
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #40 on: February 08, 2012, 02:57:24 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

From what I can see, the reason Cartographer is crashing is the POINTER SPACE. Since the table separates 17 bytes between each pointer, try and put $11 instead of $00.

-C_CliFF

paranvoi

  • Jr. Member
  • **
  • Posts: 45
    • View Profile
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #41 on: February 08, 2012, 05:18:56 pm »
Hmmm... I noticed in the FF1 blocks that came with Cartographer, that in the RAW blocks there was a different .tbl file than in the POINTER_RELATIVE blocks. Is it necessary to make a whole new table file specifically for raw blocks? Because I just dumped the table starting at E8580 using the raw method and got this:

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

//BLOCK #004 NAME: oak1
//Block Range: $E8580 - $E85BF

//<$58>h<$3F><$08> <MALE><$03><$48><$40><$21> :<$23><$F8><$01>B <$47>  <$95>h<$3F><$08>
<MALE><$03><$48><$01><$21> :<$19><$F8><$01>B <$47>  <$23>i<$3F><$08> <MALE><$03><$48><$40><$21> :<$0F><$F8><$01>B <$47>  <$64>i<$3F>

I'm guessing that's not supposed to look like that...

From what I can see, the reason Cartographer is crashing is the POINTER SPACE. Since the table separates 17 bytes between each pointer, try and put $11 instead of $00.

-C_CliFF

Crashed unfortunately. D: This was what my block looks like with that $11 added in:

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: $11
#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 #42 on: February 08, 2012, 07:29:18 pm »
Try $10 instead of $11.
In the event of a firestorm, the salad bar will remain open.

C_CliFF

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
    • General CoolNES Translations
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #43 on: February 08, 2012, 08:17:17 pm »
I think the problem here is actually the BASE POINTER. Are you sure you want to add $F8000000 to each pointer to get to the right adress where the text is stored?

Correct me if I'm wrong but the first line where the text is stored is at adress $3FDAE2? And the first pointer that the text points to is at $E8580?

If that's the case, replace the BASE POINTER from $F8000000 to -$FFC06426. ($3F08 - FFC06426 =  $3FDAE2)

-C_CliFF

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #44 on: February 08, 2012, 08:37:56 pm »
No no no no no. #BASE POINTER is the address added to the pointer value that Cartographer reads from the ROM. In this case, it rolls over and cancels out the leading 08 when translating from the GBA address to the actual ROM address.
In the event of a firestorm, the salad bar will remain open.

C_CliFF

  • Jr. Member
  • **
  • Posts: 63
    • View Profile
    • General CoolNES Translations
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #45 on: February 09, 2012, 03:36:54 pm »
Yes, you're right.

This works:

Code: [Select]
#GAME NAME: Pokemon Fire Red (GBA)

// Start Adress: $3FDAE2

#BLOCK NAME: oak1
#TYPE: NORMAL
#METHOD: POINTER_RELATIVE
#POINTER ENDIAN: LITTLE
#POINTER TABLE START: $E8580
#POINTER TABLE STOP: $E85BF
#POINTER SIZE: $04
#POINTER SPACE: $10
#ATLAS PTRS: Yes
#BASE POINTER: $F8000000
#TABLE: firered.tbl
#COMMENTS: Yes

#END BLOCK

Output:

Code: [Select]
//GAME NAME: Pokemon Fire Red (GBA)

//BLOCK #000 NAME: oak1

//POINTER #0 @ $E8580 - STRING #0 @ $3FDC58

#W32($E8580)
//OAK: Inflicting damage on the foe<LINE2>
//is the key to any battle.<LINE1>
//<END>


//POINTER #1 @ $E8594 - STRING #1 @ $3FDC95

#W32($E8594)
//OAK: Lowering the foe's stats<LINE2>
//will put you at an advantage.<LINE1>
//<END>


//POINTER #2 @ $E85A8 - STRING #2 @ $3FDD23

#W32($E85A8)
//OAK: No! There's no running away<LINE2>
//from a TRAINER POKéMON battle!<LINE1>
//<END>


//POINTER #3 @ $E85BC - STRING #3 @ $3FDD64

#W32($E85BC)
//OAK: Hm! Excellent!<LINE1>
//If you win, you earn prize money,<LINE2>
//and your POKéMON will grow!<LINE1>
//Battle other TRAINERS and make<LINE2>
//your POKéMON strong!<LINE1>
//<END>

-C_CliFF
« Last Edit: February 09, 2012, 03:44:23 pm by C_CliFF »

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #46 on: February 09, 2012, 03:53:08 pm »
Ah-ha!

There's only one linebreak command after all! <LINE2> should be <LINE>, and <LINE1> should be <PAGE>.
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 #47 on: February 09, 2012, 04:33:26 pm »
That does work, but where does the 10$ come from? I get that that's the "pointer space", but what exactly does that mean? Because there's 16 bytes in between the end of one pointer and the start of another... (in the screenshot)

Is there any way to dump multiple tables at once btw? Instead of doing all these tiny tables one by one? How is it that the script of the FF1 that came with Cartographer was able to be dumped to just 2 text files that contain everything?

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #48 on: February 09, 2012, 04:52:13 pm »
That does work, but where does the 10$ come from? I get that that's the "pointer space", but what exactly does that mean? Because there's 16 bytes in between the end of one pointer and the start of another... (in the screenshot)

10 hex = 16 dec. Don't tell me you've gotten this far without knowing hex? >_>

Is there any way to dump multiple tables at once btw? Instead of doing all these tiny tables one by one? How is it that the script of the FF1 that came with Cartographer was able to be dumped to just 2 text files that contain everything?
[/quote]

Remove the "-m" option from the end of the command string.
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 #49 on: February 09, 2012, 06:25:41 pm »
Is there any way to dump multiple tables at once btw? Instead of doing all these tiny tables one by one? How is it that the script of the FF1 that came with Cartographer was able to be dumped to just 2 text files that contain everything?


Remove the "-m" option from the end of the command string.

Doesn't the -m just force Cartographer to dump everything into the same text file? I still would have to make an individual end block for every single pointer table, for which I'd have to find the start and end address for every one, right? :\

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #50 on: February 09, 2012, 06:51:39 pm »
Ah. Sorry, I misunderstood.

Believe it or not, FF1's a much simpler game - there's just one pointer table for all the game's dialogue. For Pokémon, there's a lot of different little specialized dialogue blocks each with their own pointer tables.

So yeah, there's really no way around it - except maybe choose a game with less text. >_>
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 #51 on: February 11, 2012, 06:32:01 pm »
Ah. Sorry, I misunderstood.

Believe it or not, FF1's a much simpler game - there's just one pointer table for all the game's dialogue. For Pokémon, there's a lot of different little specialized dialogue blocks each with their own pointer tables.

So yeah, there's really no way around it - except maybe choose a game with less text. >_>

I think what I'm gonna do is use Advance Text to edit what I can (=99% of the dialogue) and hit the rest using Windhex/Cartographer/Atlas (=battle text, menu text, etc.)

But arghhhh I'm having a problem again. =_= Can someone explain why I keep getting a "string not found" error when I try to do a hex search here:



The start of the string OLD COUPLE is at 23E809. In little endian formatting this should be 09E82308, right? Why does that value return an error when I do a hex search for it? D: And yes, I have "start search from the beginning" checked. And I get the same error when I search for the the start address of any of those trainer names.

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #52 on: February 11, 2012, 08:35:30 pm »
Well, I can add two more values to your table: 53=PK and 54=MN.

So. I'm...at a loss here. That should be the address, but then the formatting here is very, very odd - there's a lot of zero-padding in all the other strings. Try searching for another string address: if the actual start of the string doesn't work, try the start of the zero-padding.
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 #53 on: February 12, 2012, 12:00:55 am »
Well, I can add two more values to your table: 53=PK and 54=MN.

So. I'm...at a loss here. That should be the address, but then the formatting here is very, very odd - there's a lot of zero-padding in all the other strings. Try searching for another string address: if the actual start of the string doesn't work, try the start of the zero-padding.

Hehe, good eye with those 2 new values, totally missed those :D

But yeah, still can't get the hex search to work. I'm trying both the start of the string and the start of the 0-padding, but I keep getting the same error message with every trainer name.

OH WAIT! I decided to try searching for the start address of the very first string in this collection of trainer names:


I did a hex search for the PK in PKMN TRAINER and got a match. I got excited thinking I found the pointer table where all the names were stored, like "yes, I found the motherload!" but whaddaya know, the pointer table was pitiful in size.



When I dumped it, this is all I got:
Code: [Select]
//GAME NAME: Pokemon - Fire Red.GBA

//BLOCK #005 NAME: trainer_names

//POINTER #0 @ $D809C - STRING #0 @ $23EAC8

#W32($D809C)
//    <END>
//POINTER #1 @ $D80A0 - STRING #1 @ $23E558

#W32($D80A0)
//PKMN TRAINER<END>

I... kinda need to be able to translate more than just 1 out of all the trainer names in the game. :huh:

Any idea where those others might be stored? The start address of PKMN TRAINER is literally the only one that returns any match. Even if I search for the start address of the 2nd PKMN TRAINER (I have no idea why there are 2 back-to-back like that in the first screenshot?) then I still get the "string not found" message. :| Same thing happens if I search for the 0-padding. Helppp.

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #54 on: February 12, 2012, 12:04:55 am »
What does the other pointer point to? What's at 23EAC8?
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 #55 on: February 12, 2012, 12:36:20 pm »
What does the other pointer point to? What's at 23EAC8?

Oho, nice one, I didn't even notice that value there. This is what's at 23EAC8:



It's the very end of the list of trainer names. Doing a hex search for it actually did return a match, but it wasn't very fruitful. Just a couple stranded 08's. There was what looked like a potential pointer table at the top:



But I dumped it and got this:

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

//BLOCK #006 NAME: trainer_names2

In other words it was totally empty. :D

Here's a message someone else sent me about this problem. I already asked him to explain what he meant a bit clearer but maybe you can look at it too Ryusui and get something out of it  :P
Quote from: Tauwasser
Well, anyway, your current problem seems to be not finding pointers to the individual trainer data.
The reason for this is simple: There are none.
IIRC, all Pokemon games so far (at least GB/C + GBA) have always counted trainers from the start of the respective trainer class. So basically, you will need to find the first "Cooltrainer" on that list and look for a pointer to his data. All other Cooltrainers' data is then computed by counting 0xFF bytes, which end one trainer's data. You can go look for the start of the list. There should be a pointer to it regardless of me being correct or not. That way, you should find the master pointer table and find all sub table-entries from there. You will of course have to repoint the whole table for a sub-trainer type.

I don't really get what Tauwasser means here by "look for a pointer to his data". Is that something different from the start address to the string?

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #56 on: February 12, 2012, 01:06:33 pm »
Okay, this is gonna be kinda funky: what he's saying is that the game doesn't have pointers to each individual string in this case. What it does instead is iterate through the list until it finds the string it wants.

Say the game tries to look up String #36 for a particular event. In normal cases, it would take the start of the pointer table and do a little math to get the address of Pointer #36, which would point to the string the game wants. In this case, it instead goes through the list and identifies each string ending by the telltale FF byte at the end.

The upshot of all this: good news! You don't need a pointer table, because the game just looks through the whole block for the string it wants! Horribly inefficient, but there you go. You can just dump the whole block in raw mode and reinsert it without any trouble.
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 #57 on: February 12, 2012, 02:02:01 pm »
Okay, this is gonna be kinda funky: what he's saying is that the game doesn't have pointers to each individual string in this case. What it does instead is iterate through the list until it finds the string it wants.

Say the game tries to look up String #36 for a particular event. In normal cases, it would take the start of the pointer table and do a little math to get the address of Pointer #36, which would point to the string the game wants. In this case, it instead goes through the list and identifies each string ending by the telltale FF byte at the end.

The upshot of all this: good news! You don't need a pointer table, because the game just looks through the whole block for the string it wants! Horribly inefficient, but there you go. You can just dump the whole block in raw mode and reinsert it without any trouble.

Oh, cool! Good to know :laugh:

Well I've gotta be doing something wrong. I dumped the block in raw mode and got this:
Code: [Select]
//GAME NAME: Pokemon - Fire Red.GBA

//BLOCK #007 NAME: trainer_names (raw)
//Block Range: $FB93 - $FC03

//<$08><$80><$20><$40><$02><$08><$40> <$28><$03>V <$20><END>

Aiyaiyai...

Here's the end block I made for that:
Code: [Select]
#BLOCK NAME: trainer_names (raw)
#TYPE: NORMAL
#METHOD: RAW
#SCRIPT START: $FB93
#SCRIPT STOP: $FC03
#TABLE: table.tbl
#COMMENTS: Yes
#END BLOCK

I wasn't really sure where to stop the script. I did a hex search for that 23EAC8 value and just picked the position of the 08 at the end of the string that came up.

EDIT: I just tried it again with this block:
Code: [Select]
#BLOCK NAME: trainer_names (raw)
#TYPE: NORMAL
#METHOD: RAW
#SCRIPT START: $23E588
#SCRIPT STOP: $23EAC8
#TABLE: table.tbl
#COMMENTS: Yes
#END BLOCK

In other words I'm using the start and end of the block of trainer names itself and not doing any hex searches. But this too resulted in a super small amount of dumped material:

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

//BLOCK #007 NAME: trainer_names (raw)
//Block Range: $23E588 - $23EAC8

//<END> FOUR<END>OLLECTOR<END>   POKéMANIAC<END>IST<END> RANGER<END>

Ryusui

  • Hero Member
  • *****
  • Posts: 4989
  • It's the greatest day.
    • View Profile
    • Tumblr
Re: Windhex - Sorry ... The string was not found. (Help!!!)
« Reply #58 on: February 12, 2012, 02:54:02 pm »
Make an alternate version of your table, and remove the "/" from the start of the end tag. That should work.
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 #59 on: February 12, 2012, 03:05:50 pm »
Make an alternate version of your table, and remove the "/" from the start of the end tag. That should work.

Just tried that. Dumped the same exact thing :\

This is what the end of my alternate table looks like:
Code: [Select]
FF=<END>
Didn't change anything else in it. And yes I did remember to go into the command file and change the text in the #TABLE slot of the end block to match the file name of the alternate table.

? D: