How to separate the text and game physics in GAME.PRE file?

[GTAManRCR]

The question is above. If I try to translate this, to make the translation 100%, it will screw up the game's physics, and will produce errors like these

[Daniel3D]

I suspect that the text string takes more memory than the original.

[GTAManRCR]

Would be a memory issue? So it's better not to modify this?
In my Stunts translation I left this file because of the glitch

[GTAManRCR]

I suspect that the text string takes more memory than the original.

If I write shorter words, it'll corrupt the game menu, memory issue again?

[Daniel3D]

I suspect so. But that's from a debuggers perspective. One of the programmers could verify my assumption.

[GTAManRCR]

Let's wait for some modder who can do this (I can't)

[Cas]

Are you editing the text by overwriting existing text in the PRE file?  You shouldn't do this. Instead, decompress the PRE file to a RES file using Stunpack, then remove the PRE file from Stunts directory and edit the RES file. It will be much easier and flexible, but also, it won't cause conflicts.

The reason why you're getting memory corruption likely is because of the compression for PRE files. These files are compressed using a method that makes some parts of a file replicated in another, so when you change a part of the text, it's possible that you're also changing some value that will go in a completely different place.

Now that I've said it vaguely, but more simply, I'll be a little more technical, but specific. There are three "families" of compression algorithms that are the most prevalent: RLE and similar, Huffman-like, and LZW-related. I think the compression used by Stunts is a mixture of RLE and LZW and perhaps some Huffman too. RLE and Huffman compress each part of the data independently, so if you edit something, yes, you may break the encoding and everything will crash, but you can't possibly corrupt something else. But with LZW, strings that are found in several places in a file are replaced with references to a single string. This means that, if you later go and modify this string, you're actually modifying all instances of it. Now say that you have an ASCIIZ string that ends in the letter "e" and a character 0. This is identical to a word integer value 65. If all 65's were to be referenced to the end of this string then, say the string is "Drive", if you change this to "Manejar" ("Drive" in Spanish), then this "e" plus character 0 is changed to "ej", which is a much larger number. It is unlikely that strings only two characters long are being referenced this way, because that would yield no compression, but it is possible. Longer strings (typically four characters long) are more likely to be replicated and less likely to create conflicts, but with so much data, conflicts kind of have to happen if you change the majority of the text. Besides, if you modify a string also changing its length, all strings after it will shift positions. Some LZW encodings are relative to the current pointer position, in which case, this wouldn't matter, but others are relative to the beginning of the file and this would create major mayhem!

[GTAManRCR]

Stunpack makes a file as PRE.out which is RES, but after editing strings with Stressed, it'll save as uncompressed, so that will become RES.

And, I encountered terrain glitch between ter1 and ter4 files. Every of them (They're tuning values like pbox in TEDIT.PRE/TEDIT.RES) has the right hex byte, but I think due to badly integrated mnam, snam, and tnam it became corrupted, but ter0 works fine somehow. How do I fix this? (I'm talking about TEDIT.RES)

ter0 = Terrain 1
ter1 = Terrain 2
ter2 = Terrain 3
ter3 = Terrain 4
ter4 = Terrain 5

If I select ter4 in the map editor, the game will crash. Between ter1-ter3 it will only be corrupted even if has fulfilled with the right hex bytes.

[GTAManRCR]

These files are compressed using a method that makes some parts of a file replicated in another, so when you change a part of the text, it's possible that you're also changing some value that will go in a completely different place.

[GTAManRCR]

If you ask, I worked with Stressed all the time

[GTAManRCR]

And, I encountered terrain glitch between ter1 and ter4 files. Every of them (They're tuning values like pbox in TEDIT.PRE/TEDIT.RES) has the right hex byte, but I think due to badly integrated mnam, snam, and tnam it became corrupted, but ter0 works fine somehow. How do I fix this? (I'm talking about TEDIT.RES)

Here's what I'm talking about

[GTAManRCR]

Fixed

[Daniel3D]

Fixed

How? Please elaborate..

[GTAManRCR]

Not the GAME.PRE, but TEDIT.RES

I duplicated the four terrain segments, and because the fifth one (Terrain 5) gave me an error, as it became corrupted, I replaced it with ter1, which is Terrain 2 in Stunts track editor

[Duplode]

If you ask, I worked with Stressed all the time

Just to be sure: are you getting those text-related errors after editing GAME.PRE with Stressed and saving it as GAME.RES? If so, that's pretty strange, and should be investigated further. Stressed is supposed to take care of the lengths declared in the resource file header so that changes like those you are doing don't lead to memory being overwritten in wrong places.