tutorial Lets talk about text baby! (String File)

[Perfectplex]

I was asked how the strings file works some time ago and how to know what the offset refers to.

First of all for a quick bit of advice I would suggest you use the Future Proof String/Super String and use @pozzums databases for the strings file.

This is a brief explanation of the structure of the strings file and how it can be modified without replacing any text for new names added to the list.

OK, first of all this is very much experimental and really for the curious and it is VERY much suggested that you back up your string_win.pac file.

Head to the pac folder and back up and copy the string_win.pac file to somewhere you can operate on it.

Open the pac and extract the shdc files using xpacker/pac tool/whatever pac program you have.

You should now have 7 shdc files, each of these are a language pack.

• 3F314DAD2BA8A770       (English)
• F38817357B2C9D38        (French)
• D0B04E1C5FCC11CE      (Italian)
• 006E0A9ADE8D5ADE      (German)
• C6CBD9277AFCB844     (Spanish)
• 3AE7B5E0300C84F7      (Arabic)
• 59B68B44389004C8      (latest_output.dat devs note)

Now I am going to only be playing with the English file but the procedure for the other languages will be pretty much the same thing I'd imagine and could easily just be chunk copy pasted into each should it be needed.

Now you can decompress the single file out of the English pack and open it with your Hex Editor.

Yes at first glance its just looking like a nightmare of hex code which makes no sense, but stay with me.

In HexEditor I suggest adjusting the slider offsets and window size to cap off the first 8 bytes and have 12 bytes showing and things will look a lot more ... clean.

 

Lets start from the top

00 00 00 00 = No Idea, possibly file number which means this would be a priority file read first or it could be an extension reserve of the next 4 bytes.

64 63 00 00 = Number of Text Entries.

OK, as we know these files tend to use little endian where the bytes read from right to left so this is actually 00006364.

Open up your calculator and change it to programmer mode, click on Hex (Hexadecimal) and type in 6364 and under the Dec (Decimal) value you will see this comes to 25,444

 

This is how many unique string entries are in the file (and thus the game).

Remember how I said to alter the window to only encapsulate 12 bytes (as shown in the pic above)? Well now you want to multiply the 25,666 (or 6364 by C if using hex) by 12.

6364 x C = 4A8B0

or

25,666 x 12 = 305,328

now add 8 on (the first 8 bytes at the top of the file).

Now we have 4A8B8 or 305,336.

If you jump to this address in Hex Editor you will see it is the start of the text in the character area that looks normal.

 

Now scroll back to the top again, also take another look at my first image in this post.

Notice the first line of entries.

Well what do we have here? A cuppa 0004A8B8'ers?

Yes this shows the first offset for the first entry is the same as the sum we worked out.

The next bytes are 0A 00 00 00, which as you will know 0A = 10, well this is the number of characters for the string, always do one more than the count to allow for the 00 divider ( . )

OK, well that just leaves the 00 00 00 00, really simple if you look at the list, this is just the text entry ID, it starts at 00 00 00 00 and ends at the last entry being A0 86 01 00 but will have gaps where old references have been omitted.

000186A0 = 100,000.

 

So does this mean I can add more entries?

Not unless you are willing to redo all the offsets, if you are willing then good on you, but it would mean with a tool to calculate the new offsets it wouldn't be difficult to slip in new text entries to the string file without needing to overwrite any.

As it stands the overwriting method is much more appropriate and this thread is aimed at the curious and anybody willing to write up a program whereby it will restructure the string file to allow for longer/shorter strings (swapping bytes 4-7) and changing the offset (bytes 0-3) with bytes 8-B being the ID, so you could for example slip in "Hulk Hogan" as ## ## ## ##   0B 00 00 00   55 04 00 00 with ## ## ## ## being the offset that reassigns the rest in the list.

I know this didn't provide too much value to most but it should be a reasonably easy to grasp breakdown of the string file and how it works and may inspire one of the resident programmers to take up the challenge to make a string editing tool.

Drag pofo file into the UI window

It reads the string file to be able to find the 4 string entries from the pofo and displays them.

Changing the string adjusts the character count and reassigns all the offsets once you accept it.

It also allows for a string explorer in which you can look for a String ID manually, if it finds no such entry and you choose to install to that entry it finds the end of the file and starts to append it.

Also remembering to change the entry count at the top of the file.

I'd do it myself if I were a competent programmer but its something I can only blueprint and would require somebody with the ability to convert my ideas into code.

Have a Happy Easter folks.

[TheVisitorX]

Thanks, hmmm... Maybe something useful for CCT ..... *adds that to his list*. Argh, I need a day with 48 hours...

Edited April 16, 2017 by TheVisitorX

[Aŕch Jŕ]

Nice Work Man

[pozzum]

I had originally built the super string to be an expanded 0000 file however @LordJustice17 had convinced me to go the 0001 file route and I'm happy with that.

And yeah I built a program for it that should be easy enough to output a 0002 file if we ever truly need one.  You just need to make sure to use strings that are not used in the main string.

[Perfectplex]

1 hour ago, pozzum said:

I had originally built the super string to be an expanded 0000 file however @LordJustice17 had convinced me to go the 0001 file route

Oh I thought thats what superstring did, I wasn't aware of a 0001 file? I aren't currently using the superstring because I'm experimenting and investigating the vanilla files and assumed superstring just replaced unneeded strings.

Edited April 16, 2017 by Perfectplex

[pozzum]

1 minute ago, Perfectplex said:

Oh I thought thats what superstring did, I wasn't aware of a 0001 file? I aren't currently using the superstring because I'm experimenting and investigating the vanilla files and assumed superstring just replaced unneeded strings.

no the default string actually only has a 0000 file this year.  The superstring doesn't overwrite any names it just adds about 4500 strings in between other values the string uses.

As I said if I wanted to fill another empty chunk of strings it wouldn't be too hard but we still have a lot of space in the 0001 string file.

[Perfectplex]

Is the 0001 string file a modified vanilla file? I can't find it, I only have string_win.pac with the sdhc files within and haven't noticed any other string files 

Or is it something added as a mod? I really need to test a custom string file with a list of "ch00100" and onwards but tackling all the offsets in the default string file looks like such a headache. do I just add another string file to the pach and head it as 0001?

Then do I continue where 0000 leaves off at 100,000 (decimal)?

Edited April 16, 2017 by Perfectplex

[pozzum]

yeah I used a 2K16 pac and pach with the extracted 2k17 uncompressed 0000 files. 

The 0001 in my super string is 100% custom I made it from the ground up with the tool I built. (it takes an csv list and converts it to a string file.)

[Perfectplex]

Oh sweet, that's going to come in useful, cheers for that tip

@pozzum

Edit: I just started to write this file but already have a problem, how would I be able to call a 3 byte string for a name or am I supposed to treat this as an override and use entries in the 2 byte region?

Also did I do this correctly?

Edited April 16, 2017 by Perfectplex

[pozzum]

You'd only want to use  a 2 byte name that's inbetween used names

[Perfectplex]

Sweet, cheers