Trouble coding new parameters for pak assets

[jamespetts]

Thanks to VS's help, I have now managed to make makeobj compile. However, I have had considerable difficulty in adding a new parameter for it to read. The problem seems to be that the writer always writes 0 to the pak file instead of the number actually present in the .dat file, even if the default is specified as 1. I am trying to add an "is_tilting" line to the vehicle definitions to go with the new cornering algorithm, and have added this to vehicle_writer.cc:

Code Select Expand


uint8 tilting = (obj.get_int("is_tilting", 1));
node.write_uint8(fp, tilting, 33);

I have also changed the line:

Code Select Expand


int total_len = 31;


to

Code Select Expand


int total_len = 34;


to take account of the additional size of the new 8-bit integer that I am using to store the is_tilting value (I have set a bool "get_tilting" function to return true if is_tilting is 1, or otherwise return false).

I have added the following line to the test .dat file:

Code Select Expand

is_tilting=1

However, whenever the program reads the tilting variable on a file compiled with the version of makeobj that I have compiled, is_tilting always comes out at 0, rather than 1. I am having great difficulty in understanding why this is (especially since I copied exactly the code for reading and writing other variables), and should greatly appreciate any assistance.

[prissi]

Sorry makeobj is cryptically. Use a hexfile to look at your file. Other than that I am seriously lacking time unfourtunately. makeobj took me month to fully understand its function (and some parts like the reference reader is still advanced magic to me).

[jamespetts]

Prissi,

thank you for your reply. Can anybody else help?

[prissi]

None of the active coders, imho. You need more patience young padawan. It took me a month to make first sucessful change.

[VS]

Incidentally, yesterday I took a look at the code prissi mentioned... needless to add, I just decided to retreat while preserving some sanity.

So yes, we are probably not expected to get it working :(

Maybe Hajo could know something about this.

[z9999]

I think you need to add it before "sound_str_len", "sound_str_len" is number or sound file name which is not fixed byte length and is 0 byte usually.
That isn't a part of VHCL node.

And more, if you added 1 byte, total_len = 32, isn't it ?

[jamespetts]

z9999,

thank you for your suggestion. When I tried adding it before the sound (and renumbering accordingly), Simutrans produced an access violation at startup whenever a  pak file produced with makeobj so altered was in the selected pak directory. Really, it might be faster to use existing open source XML classes and make an entirely new XML format for future assets than to make sense of the scantly documented and excessively cryptic .pak file format (keeping the existing .pak code for backwards compatibility only).

Does anyone else have any suggestions in the meantime?

[VS]

To the last suggestion I can only say:

[jamespetts]

VS,

it is hard to see why such a simple operation as reading some text from a file should require such Byzantine cryptic intracity.

Further testing has showed that, when I insert the is_tilting value higher in the file, it corrupts all of the values written below it, even though I have carefully renumbered everything to match the byte sizes.

Edit: Even more odd: when I look at the files in the hex editor, all appears to be correct: there is one additional byte of data in the vehicle node section that exactly corresponds to my "is_tilting" parameter's number from the .dat file. I can only imagine that the problem is in the reading, not the writing, yet there does not appear to be any code in the reader that depends on the files being a particular length or in a particular order. It really is most odd.

[z9999]

You didn't write the code of reader, so I can't know it.

When I tried adding it before the sound (and renumbering accordingly), Simutrans produced an access violation at startup whenever a  pak file produced with makeobj so altered was in the selected pak directory.

Did you set the correct node length which I suggested ?
Can you see all node list with "makeobj dump" without error ?

[jamespetts]

Z999,

thank you for your suggestions: I have finally managed to make it work (and was just editing the above post to say so when I saw your message - yes, I did set the node length to the correct level. It turns out that the later parts (relating to the sound) do not count towards the node length at all, because they are in a different node). It turns out that the sequence in which the data is read is important, and must be the same as the sequence in which the data is written, or else the data will become corrupted. Furthermore, it is important to distinguish between the different nodes in the .pak files. Running makeobj dump <filename> will display the nodes and their sizes. For vehicles, the node that contains the numerical vehicle data is the VHCL node, and, after the root node (with the header information), it is the first node in the file. (The nodes can be found easily in a hex editor: the node name in capital letters appears in the ASCII section immediately before the node begins. This appears to be the system that demarcates the various nodes). Immediately after the VHCL node, there is a text node, containing the vehicle name, the author's name and possibly some other information. The VHCL node stores all the numerical data about the vehicle, including bool flags represented by numbers.

To add the new data on whether the vehicle is a tilting train, I added the code for writing the data immediately after the final data that was read in the vehicle reader (the coupling constraints), but before the data on the sound (which is actually part of a different node (probably because it contains text): when I checked in the hex editor, in this configuration, my is_tilting byte was the very last byte of the VHCL node). I then added the code to read the is_tilting byte at the very end of the version 8 section of the reader. In a .pak file with no is_tilting byte, the number read in is unpredictable (I should have expected that the first byte of the word "TEXT", namely hex 54, decimal 83, would have been read, but that appears not to be the case: 204 is the commonest number, but 25 and 15 are also seen), but never seems to be less than 10. To ensure backwards compatibility (without random vehicles being flagged as tilting), I have set the relevant get function to return a true value only if the is_tilting integer is exactly 1, and return false otherwise. There are no false positives in Pak128 with this value set, and my test vehicle is correctly marked as tilting. If the new cornering algorithms including this tilting patch are incorporated into the trunk, of course, a new version 9 can be created that only reads that final byte at all if the file is flagged as a version 9 file, which eliminates the (fairly small) chance of a vehicle incorrectly being marked as tilting.

Thank you to everyone for your help, and especially Prissi and Z999 for suggesting things (the hex editor and the sequencing) that lead to a solution. Perhaps this should be documented formally somewhere...?

Edit: I have found a way of ensuring that the is_tilting value is always either 0 or 1: check to see whether the node.size is exactly 32: if it is, then the program can be sure that we are using the new subversion of file version 8, and can go onto read the tilting value from the file; otherwise, the tilting value should be set to its default value of 0. I have also tested with the code for reading the tilting byte from the file removed, and found that that does not cause any errors or data corruption: in other words, version 8a is fully backwards compatible with version 8.

[prissi]

I would recommend to add to any new feature a new version number. That is the purpose of a version number. Everything else just causes confusion imho. But as long as you just experiment for yourself go ahead

[jamespetts]

Prissi,

ahh, yes, that might be sensible, but I don't want to add a new version number myself, since anything that I produce then would only work with my own version :-) It makes sense for you to be the only person who adds a new version number. If you incorporate the new cornering (including tilting trains) into the trunk (and I hope that you do), then it would make sense if you used an official version 9 rather than the unofficial version 8a. However, if, for some reason, you decide not to incorporate it into the trunk, I should still want assets created with my modified version of makeobj to work with the non-modified version of Simutrans, hence defining an 8a, and making it backwards compatible with 8.

[prissi]

I was thinking the same, with less word though ...

[jamespetts]

LOL! Ahh. I usually think in more words