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
I suspect that the text string takes more memory than the original.
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
Quote from: Daniel3D on March 05, 2021, 12:37:43 PM
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?
I suspect so. But that's from a debuggers perspective. One of the programmers could verify my assumption.
Let's wait for some modder who can do this (I can't)
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!
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.
Quote from: Cas on March 05, 2021, 06:12:34 PM
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.
If you ask, I worked with Stressed all the time
Quote from: GTAMan18 on March 05, 2021, 07:16:52 PM
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
Fixed
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
Quote from: GTAMan18 on March 05, 2021, 07:21:09 PM
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.
That's right. You should only get corruption if you are directly overwriting the PRE file
Quote from: Duplode on March 05, 2021, 11:45:44 PM
Quote from: GTAMan18 on March 05, 2021, 07:21:09 PM
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.
Stressed can't open GAME.PRE, even after converted to GAME.RES, so I used a hex editor, which made the corruption
In GAME.RES the problem is, that Stressed can't open cinf and crak, which are very important segments. I think, that cinf stores the behavior of the obstacles, and the crak contains the cracked state.
And if I select ignore this resource, it'll screw up the physics, but at least, the car is drivable
Proof: https://youtu.be/XLuRz4Gu2sU
Quote from: GTAMan18 on March 06, 2021, 10:31:51 AM
In GAME.RES the problem is, that Stressed can't open cinf and crak, which are very important files. I think, that cinf stores the behavior of the obstacles, and the crak contains the cracked state.
Okay, I think this solves the mystery. Stressed built from the most recent sources (https://github.com/dstien/gameformats) (which I and, IIRC, Cas use) can handle cinf and crak, but the 0.2.1 release (including the Windows binary linked to from Southern Cross) can't. Tomorrow I'll try to prepare an updated Windows executable, which in any case is long overdue.
Thank you very much in advice!
Quote from: Duplode on March 06, 2021, 02:33:49 PM
Stressed built from the most recent sources (https://github.com/dstien/gameformats)
If you're planning to update its resource code, then make sure to add these to
stressed/resources/conf/defaults.conf
pbox = tuning
ter0 = tuning
ter1 = tuning
ter2 = tuning
ter3 = tuning
ter4 = tuning
Because the terrains, and the pbox (The list you can select track elements from during editing with the in-game editor) are actually tuning values
I'm not sure about mnam, snam, and tnam, but I imported them as text, and after saving, the saved TEDIT.RES worked, however I needed to duplicate the terrain segments in order to make them work correctly, but ter4 is replaced with ter1 by me in the Hungarian translation, because the ter4 segment was duplicated however, but remain corrupted