News:

Simutrans Chat Room
Where cool people of Simutrans can meet up.

Seeking views - .pak file differentiation?

Started by jamespetts, May 21, 2009, 04:01:25 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

jamespetts

Reading an automatically translated thread about Simutrans-Experimental in the German forum (here), there was some discussion about how Simutrans-Experimental paksets ought to be dealt with and differentiated from Simutrans-Standard paksets.

Presently, Simutrans-Experimental can read Simutrans-Standard paksets (but some Simutrans-Experimental specific features will not be available), but Simutrans-Standard will fail on trying to load a Simutrans-Experimental .pak file. The present suggested solution is to have a separate install directory structure for Simutrans-Standard and Simutrans-Experimental, and confine Simutrans-Experimental paksets to the Simutrans-Experimental directory. Makeobj-Standard can, however, read a .dat file written for Simutrans-Experimental, so it is at least possible for pakset maintainers to have a single set of .dat files if they want to be able to make Simutrans-Standard and Simutrans-Experimental compatible paksets.

Two other suggestions were canvassed in that thread: one was making Simutrans-Standard able to read Simutrans-Experimental compiled .pak files (but discard the extra data specific to Simutrans-Experimental), and the other was for Simutrans-Experimental .pak files to have a different ending (.pac was suggested, but I prefer .epk or .pke), to distinguish them from Simutrans-Standard .pak files.

These solutions are not mutually exclusive - a separate directory structure is recommended in any event because Simutrans-Experimental works best with different simuconf.tab settings than Simutrans-Standard (the passenger level, for instance, should ideally be lower in Simutrans-Experimental), and different file name extensions would not stop Simutrans-Standard being able to read Simutrans-Experimental .pak files.

Simutrans-Standard compatibility is not something over which I have any control: that is something that Prissi would have to decide, if he considers it worthwhile. A different file name extension could, however, be implemented if that would bring any real benefit.

I should be interested in any views on these various solutions, as well as any other suggestions aimed at helping to minimise any difficulties caused by the fact that there are now two different .pak file formats.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

The Hood

I think it would be most straightforward and clear to have a different directory structure AND a different file ending - that way everything is separate, and it's also clear when distributing stuff that .pke (or whatever) will only work with experimental.

whoami

Quote from: jamespetts on May 21, 2009, 04:01:25 PM
Reading an automatically translated thread about Simutrans-Experimental in the German forum
Knowing the usual quality of automatic translations (especially from German), I hope that you didn't have to suffer a lot. Did you recognize that most of the text was a manual translation of the ST-exp feature list that you had written?  ;D

QuoteTwo other suggestions were canvassed in that thread: one was making Simutrans-Standard able to read Simutrans-Experimental compiled .pak files (but discard the extra data specific to Simutrans-Experimental)
What I meant was a little different: have one pak file format, allowing parameters for both forks to be included. This will, of course, make sense only if you don't plan to alter the file's structure entirely, it is meant for optional single parameters. I also suggested a namespace separation to recognize parameters from the other fork easily (when reading a dat file), and to prevent future collisions. I know it is late for this change to happen.

The advantage would be that people wouldn't have to distribute twice the number of pak files. We just have to remember that both programs get different data, but since their behaviour will differ anyway, this doesn't sound like a problem to me. The current behaviour is that makeobj ignores unknown and misencoded parameters (annoying, because you don't get necessary feedback for typing errors).

QuoteSimutrans-Standard compatibility is not something over which I have any control: that is something that Prissi would have to decide, if he considers it worthwhile.
You mean porting ST-exp enhancements back into ST-main? Prissi has expressed his view that this is already impossible for most changes. (Shall we continue this politics stuff in another topic?)

jamespetts

Whoami,

I did realise that the thread was a translation of my feature outline, yes. It was the responses that interested me. I think that I managed to get the gist of most of it.

In respect of the single pak format, that is certainly a possibility, but would require Prissi's co-operation because of the way in which the data are encoded in .pak files. Essentially, what would be required is that Simutrans-Standard (1) detect when it is reading a Simutrans-Experimental .pak file; and (2) discard exactly the right data so as not to read a Simutrans-Experimental parameter as if it were a different Simutrans-Standard parameter. Simutrans-Experimental already does the reverse of this to enable it to work with Simutrans-Standard .pak files.

This would not require importing any of the actual Simutrans-Experimental features into Simutrans-Standard (I am aware that Prissi's views on game design are different to mine, and that he would prefer most of the features of Simutrans-Experimental not to be imported into Simutrans-Standard), but simply altering the Simutrans-Standard code to recognise when it is dealing with a Simutrans-Experimental .pak file, and alter the way in which it reads it accordingly. The basic structure of the .pak files is not different in Simutrans-Standard to Simutrans-Experimental, so this should not be a difficulty.

The advantage of this solution, as you state, is that it would not require people to have to compile two sets of .paks to make a pakset Simutrans-Experimental and Simutrans-Standard compatible; but it would need Prissi's co-operation, as it would require changes to Simutrans-Standard's object reading code (but not gameplay).
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

KrazyJay

just a suggestion. A different extension like pakx or pke is easier to distinguish than using pak for every extension. Maybe it's also convenient to consumers to make clear for what tile size the pak file is for, and get extensions like filename.96c.pakx . But that's only from the simple consumers' point of view, not from the developers' side.
Played Simutrans in:
~ The Netherlands ~ United Kingdom ~ Taiwan ~ Belgium ~


Simutrans player

VS

A portable format? Well, we already do have one - the dat and tab files. Leaving out makeobj and pak file layer of the whole process would achieve this. In the past it worked somewhat like that, I was told. You might want to ask Hajo who may remember details, or user "zarevak" who successfully decoded that and was the first real addon creator :)

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

jamespetts

And the .png files? :-) Yes, certainly, if the .pak format was depracated, and Simutrans-Standard was designed so that it could read .dat and .png files directly, that would be one solution. Again, however, that would require Prissi's co-operation, and I don't know his view on such a solution.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Isaac Eiland-Hall

hmm... it seems that, as we've gone open source, being able to read uncomplied dat and png would be handy... (as I remember one of the points of the pak file was to protect the artwork)

jamespetts

Yes, that may be sensible. One possible downside is that it might take a fair bit of re-coding to be able to go straight from .dat and .png files to the game. Perhaps it could be put up as an extension request...?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

whoami

Quote from: jamespetts on May 22, 2009, 09:31:59 PM
The basic structure of the .pak files is not different in Simutrans-Standard to Simutrans-Experimental, so this should not be a difficulty.
.pak encoding is one part, but there can be structural changes to higher levels, e.g. if you are going to alter vehicle constraints, factory linking, size of objects etc..

And I forgot: a separate namespace (simply a prefix) for ST-experimental's simuconf.tab parameters would also be a good idea, it would help the users to identify them easily.

jamespetts

Whoami,

what do you mean by a namespace here for simuconf.tab parameters? How would that work?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

whoami

As I wrote: a prefix can be used. Parameter "foo" would become "ste_foo".