New feature: Symbolic links in tars

[frosch]

Today we added a small feature: Support for symbolic links in .tar files. (r13697)
So what is this for?

32bpp graphics can be stored in .tar files. Inside the .tar their paths are like "sprites/<name of 8bpp grf>/<spritenumber>.png". The problem up to now was, that .grf files exist in two versions (dos resp. windows palette) with two different file names. OTOH most [1] 32bpp graphics are not affected by the palette difference, so one 32bpp .tar should be enough for both of the 8bpp .grf files. But because of the different file names this did not work. [2]

Now you can add symbolic links to your .tar file [3]. I.e. if your .grfs are named 'mynewgrf.grf' and 'mynewgrfw.grf' you can put your 32bpp .png files in 'sprites/mynewgrf/<sprite number>.png' and add a symbolic link from 'sprites/mynewgrfw' to 'mynewgrf'. That way your .tar works for both .grf files.

Some restrictions:

• If you use a directory-link like above, the images need to have the same sprite numbers in the dos and windows grfs.
  So if for some weird reason your 8bpp grfs are not 'in sync', you should add some ActionC NOPs to make them 'in sync'.
  Alternatively you can add a file-link for every sprite. (You can also use file links if the same sprite has to appear multiple times in your grf for some reasons).
• The links have to use relative paths. I.e. your 'sprites/mynewgrfw' link can point to '../sprites/mynewgrf' (stupid example), but not to '/sprites/mynewgrf' or even '/usr/local/share/games/openttd/data/sprites/mynewgrf' (for obvious reasons).
• Because of performance and simplicity you cannot concatenate multiple directory links. I.e. when OTTD searches for the file 'sprites/mynewgrf/123.png' you cannot add a link 'sprites'->'mysprites' and 'mysprites/mynewgrf'->'mygraphics'. Only one directory link is resolved for files. (However if you have a link 'sprites/mynewgrf'->'../mygraphics', 'mygraphics/123.png' is still allowed to be a file link to e.g. 'mysprites/my123sprite.png'.)
• File links have to point directly to their destinations, other links must not be involved. E.g. if you link from 'sprites/mynewgrf/123.png' to 'mysprites/mypathelongation/my123sprite.png', all three parts 'mysprites', 'mypathelongation' and 'my123sprites.png' must be directories resp. files (i.e. no links).

These four points should not be any serious restriction for you.
So, now you are ready to make your 32bpp tars capable to both windows and dos palette grfs.


[1] Those without palette animation.
[2] This has been known quite some time, but because it was not reported to http://bugs.openttd.org it has been forgotton.
[3] Might not be that easy using windows though.

[GeekToo]

Very nice that this issue has been solved. It was also a problem for the extra zoom tars, so thanks for putting effort into this.

Having said that, I'm sorry to say that I have mixed feelings about the way this was solved:
-it does complicate things for graphics creators ( we will have to update every tar in the 32bpp (extra zoom) graphics list on the wiki with the symlinks)
-It makes it hard for Windows (and probably Mac users) to create graphics tars. And Linux users can create the tars, but cannot test them both, assuming they have only one flavour of the original grfs (and personally, I don't like to release stuff that I haven't seen working).
-It continues the problem of the difference between the 2 pallette flavours, which should not be necessary for 32bpp.

So I suggest a little different solution (and have to admit that I never really looked at the fileloaders, so I don't know if it is possible):
-I suppose the application knows whether it has to use a windows or dos pallette. If it is windows, just use the specified file name for the tar png loader, if it is dos, convert the filenames to windows names: for the original grfs, add the 1: trgr -> trg1r, for newgrf add the w at the end of the name. That way, the graphics creators would only have to create the windows version.

Again, I really appreciate your efforts in solving this, but I think that would be a better solution.

[Rubidium]

Just a small informational note: adding "w" to a NewGRFs name doesn't always resolve to the Windows version; sometimes you have to remove the "d" and (possibly) replace it with a "w". And there is even the possibility that the DOS and Windows names are fairly unrelated. This makes it really hacking what OpenTTD needs to do to support it properly when it cannot even do it, except hardcoding all combinations one can ever come up with instead of leaving it to the graphics file that replaces it which will always work.

[athanasios]

Still original graphics have fixed names. There GeekToo's approach is a better than symbolic links.

[frosch]

-it does complicate things for graphics creators ( we will have to update every tar in the 32bpp (extra zoom) graphics list on the wiki with the symlinks)

Well IMO they are wrong anyway. All 32bpp tars I have seen replace directly the sprites in the original grfs. That makes it impossible to disable the replacement/switch between different replacements.
Adding a new way to load/unload tars in addition to the usual newgrf window is silly.
So IMO they should be converted into proper ActionA newgrfs with 32bpp support.

-It makes it hard for Windows (and probably Mac users) to create graphics tars. And Linux users can create the tars, but cannot test them both, assuming they have only one flavour of the original grfs (and personally, I don't like to release stuff that I haven't seen working).

You just need a volunteer for 'tarcodec'