Hacking ROM Hack Others Null value between the characters and game crashes when i change the file size of the dialogues

[Harvestmoonsuchti404]

I am modding the Game Harvest Moon Animal Parade.
I edit the Dialogue there.

It works, but there are always Null/00 values between the chatacters, making it hard to edit the text. Also when i add/delete some parts of the dialogue and the file gets bigger/shorter, the game is unable to read the file and crashes. So does anyone know if there is any way to make the files bigger/shorter without the game crashing? Or does anyone at least know how to hide the null values? I know the file is UTF-16 so it shows the null, but i dont know how to change it, in another website someone said the Hex editors hide the Null values themselves but they dont.

 

[FAST6191]

Never seen a hex editor hide null values, at best the text decode will do the full 16 bits as part of the decode and thus appear to have less to show there/be more readily typed in. Trouble with that and most DS games is they almost always have some kind of 8 bit markup somewhere in the mix which breaks the basic decode fairly quickly. Some text editors might hide things (usually anything not printable ASCII).

File size changing. Yeah time to learn about pointers, in the case of the DS many files will also have the file size at the start of the file somewhere (right at the start, right after the magic stamp or in the case of many Nintendo provided formats then 8h) or in a helper file. Some will also have sizes of sections.

 

[Harvestmoonsuchti404]

Never seen a hex editor hide null values, at best the text decode will do the full 16 bits as part of the decode and thus appear to have less to show there/be more readily typed in. Trouble with that and most DS games is they almost always have some kind of 8 bit markup somewhere in the mix which breaks the basic decode fairly quickly. Some text editors might hide things (usually anything not printable ASCII).

File size changing. Yeah time to learn about pointers, in the case of the DS many files will also have the file size at the start of the file somewhere (right at the start, right after the magic stamp or in the case of many Nintendo provided formats then 8h) or in a helper file. Some will also have sizes of sections.

Could you take a look and maybe figure out where the pointer(?) could be here?

 

[FAST6191]

Setting the thing to 12 bytes wide there looks to be something counting upwards.

Curiously sections seem to start with MSGB (MSGP starts the thing so don't know if it is supposed to MSG and a further value to signify something).
347 instances of MSGB in the file.
The first MSGB starting at 1058h in the file. EE4A being the last entry in the list before then, rather shorter than the FEA2 where the last MSGB in the file happens.
Quick sanity check
1058h = 4184
Dividing that by 347 does give me 12 which is bytes wide. I was not necessarily expecting that as there is a start to the file and some other stuff, was expecting the result to be more actually.

Anyway EE4A is a lower value than I expected for an end of pointer table, however if I add the 1058 to it you get FEA2 aka we are probably dealing in so called offset pointers (they start counting where the real data begins rather than from the start of the file). If it helps to visualise it then you probably had a book start with Roman numerals for the contents, introduction and whatnot before going to Arabic numbers for the normal page numbers. Same idea but for computers instead.

What the remaining bytes are in that 12 byte section I am not sure. I would generally expect 4 bytes for a length/pointer as that can make for quite large files where 2 bytes/16 bits almost runs out in this example. Remaining ones could be a length (easier to read it than have to calculate it), could be formatting, could be who is talking or could be something related to any of those.

I am also not sure what is in the bytes between MSGB and the text itself, usual guess is formatting, what portraits to display or something like that, though could be lengths of individual lines within it (doubtful from what I have seen of it but without testing then eh).

Anyway back to pointers. First few locations of MSGB are
1058
10FA
11C6
123E
129A

Nothing in the start there, taking 1058 from it
0
A2
16E
1E6
242
Oh look

Offset(h) 00   02   04   06   08   0A

00000018  0000 0000 0000 00A2 0000 0001  .......¢....
00000024  0000 00A2 0000 00CC 0000 0002  ...¢...Ì....
00000030  0000 016E 0000 0078 0000 0003  ...n...x....
0000003C  0000 01E6 0000 005C 0000 0004  ...æ...\....
00000048  0000 0242 0000 00FE 0000 0005  ...B...þ....
00000054  0000 0340 0000 00C8 0000 0006  ...@...È....
00000060  0000 0408 0000 00DA 0000 0007  .......Ú....
0000006C  0000 04E2 0000 0098 0000 0008  ...â...˜....
00000078  0000 057A 0000 004E 0000 0009  ...z...N....
00000084  0000 05C8 0000 0092 0000 000A  ...È...’....

Next value also appears to be the length (take the next value and minus the current, or if you prefer add the value there to the current. Note in other things this might be be the same thing if they pad out the data for reasons like starting at a certain multiple is good for the processor).
The others appear to be counting upwards in that section but shortly after have random skips, so probably a line number/reference value instead (some text maybe got deleted, reordered or something). It may also be that I got it wrong there and the line numbers at what starts the entry before having location and size.