+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  Where the heck is the error??? Cartographer/Atlas problem.
Pages: [1]
Author Topic: Where the heck is the error??? Cartographer/Atlas problem.  (Read 1 times)
Auryn
Guest
« on: July 08, 2011, 08:55:41 pm »



the value x034C @ x0C is the first pointer in little endian.
the value x034E @x14 is the second pointer in little endian.
So this should give a dump of 2 bytes for the first pointer but Cartographer give me many more bytes than that and this for all pointers in the table.
The descriptions in the dump show the right values of pointers / text adresses.
This is a copy of the command file to be checked:

#GAME NAME:\t\tAAI2 (NDS/Jp)

#BLOCK NAME:\t\tText Block 460 (POINTER)
#TYPE:\t\t\tNORMAL
#METHOD:\t\tPOINTER
#POINTER ENDIAN:\tLITTLE
#POINTER TABLE START:\t$000C
#POINTER TABLE STOP:\t$0344
#POINTER SIZE:\t\t$02
#POINTER SPACE:\t\t$06
#ATLAS PTRS:\t\tYes
#TABLE:\t\t\tAAI2jpn.tbl
#COMMENTS:\t\tYes
#END BLOCK
« Last Edit: July 09, 2011, 05:00:54 am by Auryn »
Vehek
Guest
« Reply #1 on: July 08, 2011, 09:13:44 pm »
Does your table have a proper end token? Are those "many more bytes" duplicates of later strings?
Auryn
Guest
« Reply #2 on: July 08, 2011, 11:20:53 pm »
There is no end token in the text.
And the "many more bytes" are about 800+ bytes  from the pointer on or less if the end of file is reached.
Ryusui
Guest
« Reply #3 on: July 09, 2011, 12:56:38 am »
How does the game know how long each string is if there are no end tokens?

The "error" is that Cartographer doesn't automatically stop dumping once it reaches the next pointer address. If there are no end tokens and thus no way of telling where a string ends apart from checking the next pointer address, then you'll have to dump the raw script and insert pointer writes manually.
Auryn
Guest
« Reply #4 on: July 09, 2011, 02:13:21 am »
The next 2 byted after the pointer tell the game the length with a calculation.

So no easy way to make it stop at the next pointer and from what I know, there are no cartographer source codes to change it  nor another program to dump the text Cry Cry

3.18 MB in 463 files to be pointed by hand  :banghead:
Ryusui
Guest
« Reply #5 on: July 09, 2011, 02:49:26 am »
Not necessarily. An ad hoc script dumper is easy to put together. You know you can get Visual Basic 2010 Express for free, right?
Auryn
Guest
« Reply #6 on: July 09, 2011, 04:29:41 am »
My programming skills are equal to 0 in window...the only things i program are scripts in secondlife but even those not at high level. Thanks anyway for the help.

Now i get to use for the first time Atlas and I am a bit perplex about some values there.
First my hand corrected cartographer dump look like this (cut for save space):
//GAME NAME:\t\tAAI2 (NDS/Jp)

//BLOCK #000 NAME:\t\tText Block 460 (POINTER)

//POINTER #0 @ $C - STRING #0 @ $34C

#W16($C)
//<$AA><$55>

//POINTER #1 @ $14 - STRING #1 @ $34E

#W16($14)
//全てのデータを<Blue>消去<White>しã
Ryusui
Guest
« Reply #7 on: July 09, 2011, 02:31:54 pm »
See, that's the beauty of using Cartographer. See that "#W16" business before each text block? It's already formatted to insert the pointers properly.
Auryn
Guest
« Reply #8 on: July 11, 2011, 09:03:32 pm »
Yeah...thanks I knew that but there are still 4 unanswered questions in my post  :banghead:
Ryusui
Guest
« Reply #9 on: July 11, 2011, 09:53:24 pm »
Right.

1. If you have a "game.tbl," and it's the table for the game's script, then yes, use that. If you don't have a table, you'll need to make one. Fortunately, since the script is likely stored in Shift-JIS format, you can use the one we have right here.

2. Offset is how much each embedded pointer will be offset. For example, say you're doing a GBA game that needs 32-bit pointers. That'd be "#EMBTYPE("LINEAR", 32, $8000000)." Also, if you're using a proper pointer table, you don't need embedded pointers.

3. #JMP doesn't have to specify a range; specifying the first address will do fine. (The readme mentions this, BTW.)

4. If you're using Cartographer right, this little chunk attached to the start of the script is all you need.
Auryn
Guest
« Reply #10 on: July 12, 2011, 11:41:35 am »
Thanks, I will give it a try then.
Klarth
Guest
« Reply #11 on: July 16, 2011, 01:27:42 pm »
There aren't many games that use pointers for string length detection.  I'd suggest using a custom dumper (if you need help, PM me with specifics, since this would probably take less than 10 minutes) and then reinserting with Atlas using a script like:

Code:
#VAR(dlg, TABLE)
#VAR(ptr, CUSTOMPOINTER)
#VAR(ptrtbl, POINTERTABLE)
#ADDTBL("game.tbl", dlg)
#ACTIVETBL(dlg)
#CREATEPTR(ptr, "LINEAR", $-80000000, 32)
#PTRTBL(ptrtbl, $C, 6, ptr)
#AUTOWRITE(ptrtbl, "<END>")
#JMP($034C)
// Start text here

全てのデータを<Blue>消去<White>して[LINE]
<FAB5><$AD><$55><Blue>初期状態<White>に戻しますか<ACB4><$AA><$55><END>

<FAB5><$AD><$55>本当に全てのデータを[LINE]
<Blue>消去<White>してよろしいですか<ACB4><$AA><$55><END>
I put <END> on each string myself so that you can use pointer tables instead of having WXX Atlas commands through your whole script.  Define it as /<END> in your table.  I'm not sure if Cartographer does start/stop dumps, but you can use romjuice for that and apply the code above (with adjustments for script/pointer start offsets...and the <END>s)...or spend a few minutes doing a custom dumper to automate since you have 463 script files and probably tons of strings.
Nightcrawler
Guest
« Reply #12 on: July 16, 2011, 02:32:55 pm »
Wouldn't that fail to insert properly? The pointer tables need to have one more pointer than it has strings to get the length for the last string.
Klarth
Guest
« Reply #13 on: July 16, 2011, 02:52:24 pm »
Quote from: Nightcrawler on July 16, 2011, 02:32:55 pm
Wouldn't that fail to insert properly? The pointer tables need to have one more pointer than it has strings to get the length for the last string.
Good point, I didn't cover that.  The last string should look like:
Code:
String<END>
<END>

That way autowrite will write an additional pointer just after the last string.
Pages: [1]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC