Would it be makeable to change the file extension of ST.exp PAK files to another extension?
Like *.pex (Pak EXperimental), *.pkx (PaK eXperimental or *.obj (OBJect).
So ST.Standard would try to load wrong files and hangup. And if ground also would have the new file extension, ST.experimental paksets wouldn't be shown in ST.standard. There would be so much new features with a new extension, and I can't care that this would be so much work.
A more efficient solution would be to modify Simutrans-Standard to read Simutrans-Experimental .pak files, and discard the extra data that Simutrans-Standard does not use. I offered to write a patch to do this for Simutrans-Standard once, but I never had a reply.
Quote from: jamespetts on July 18, 2009, 01:04:11 PM
A more efficient solution would be to modify Simutrans-Standard to read Simutrans-Experimental .pak files, and discard the extra data that Simutrans-Standard does not use. I offered to write a patch to do this for Simutrans-Standard once, but I never had a reply.
Hm, I don't think that's a so good idea. This would mean extra memory use for ST.standard. And also would take more time to start.
And Simutrans should be as quick as it can!
It would not require Simutrans-Standard to use more memory, as the additional data would be discarded rather than stored. The additional loading time would be trivial, and would only apply in any case when loading Simutrans-Experimental paksets.
This is plainly not possible, as soon as standard extands its own structures. Or there would have been a loading routine needed for both variants of structures. Similarily I could demand for SImutrans Experimental to save standard files ... (Btw. Simutrans standard could save also 99.17.0 and every version in between, also this feature need a recompiling.) A similar switch should be possible with SE.
That approach would not work for paksets, though.
Same problem with paksets: As soon as they are extended, they would not work. However, simutrans currently ignores anyway any additional information at then end of a record. As long as you put it there, it should be ignored. You just need to check the size of the record to decide whether there is additional stuff or not.
The problem is that for many types of objects, there are a series of nodes. Vehicles, for example, have the VHCL node at the beginning of the file, and after it, the sound and graphics data. If the VHCL node is not of the size expected by Simutrans-Standard, it will fail to read the vehicle at all.
It is not neccessary to fail, as the size of a node is given in the node header. That can be patched out I think.
Example from building reader:
fread(besch_buf, node.size, 1, fp);
So any superflous code will be ignored.
Presumably, though, for Simutrans-Standard to read Simutrans-Experimental .pak files, it would have to be patched out in Simutrans-Standard?
Simutrans standard should read experimental pak files as long as the internal revision is not stepped up but the extra stuff is just appended to the records. This would mena that SE just have the size to guess the revision, but simutrans would not need any modifications.
Stepping up the internal revision is or course difficult, since then both would run obviously out of sync.
Simutrans-Experimental uses its own file versioning system for the .pak files of the types that are different in Simutrans-Experimental, such as for the vehicles, which involves adding a large hexadecimal number to the file version in writing, then checking to see whether certain bits are set when reading, and, if they are, subtracting that large number. That way, Simutrans-Experimental can extract a separate Simutrans-Standard and a Simutrans-Experimental file version dataset (the version being 0 if a Simutrans-Standard file is being read) from the same byte sequence as Simutrans-Standard uses for its file version. Thus, Simutrans-Standard would have to have code to read these different types of version numbers in order to read .pak files written by Simutrans-Experimental.
Then a change of simutrans standard is very unlikely, as it is made to be backwards compatible and is still very flexible, because one of the main rules of programming is that one should avoid breaking a well working system without need. And there is not real need to break the versioning system, since much stuff can be appended to a record. For instance, addintion vehicle data at the end of a current record would just check wehter there is more data, then read the first four bytes (or whatever) for a serial number for experimental and then it would do the appropriate action.
Personally I don't find it very important that experimental pak files can be opened in standard version. (so a extension file change can be useful)
What I do find important is that it is easy to generate both an experimental and standard pakset from the same sources (that is in: in the sources are the added data like comfort rating and so on, but they are not "compiled" in the standard pakset file)
Rationale: an extended pak128/pak64 without a "fork" from the current data files
(note: I don't know anything of the current system, so I don't know how hard this is, or maybe that it is already like this)
Nathan,
one way of building the both at the same time easily might well be to use a script, and have the outputs from the Experimental version of Makeobj go into a different directory.