Location in code for display of the pakset version on loading screen

[jamespetts]

May I ask - where is the code for displaying the pakset version on the loading screen? This is not working in the recent builds of Experimental, and I should like to track down the problem. Thank you.

[prissi]

It is the copyright string of ground.outside.pak It was the only tile that needed to have exactly the same size as the tiles; unfourtunately it has become obsolete by Markohs ...

[jamespetts]

Ahh - do you mean that this feature has been removed? I thought that it was in 112.2?

[Markohs]

 Yep, I noticed that too. We can leave it as it is, or rename to SampleTile or something similar and make it mandatory. Or PakInfo.pak, since the game takes the info from there, mantaining backwards compatibility.


Let's see...


In stardard code, obj_reader.cc line 154 you can see the copyright it's taken from there:

Code Select Expand



            if (char const* const copyright = grund_besch_t::ausserhalb->get_copyright()) {
               ls.set_info(copyright);
            }



ausserhalb (means outside in german I think), is filled with the Pak file named 'ground.Outside', as you can see in grund_besch.cc:

Code Select Expand



static spezial_obj_tpl<grund_besch_t> grounds[] = {
    { &boden_texture,     "ClimateTexture" },
    { &light_map,     "LightTexture" },
    { &transition_water_texture,    "ShoreTrans" },
    { &transition_slope_texture,    "SlopeTrans" },
    { &grund_besch_t::fundament,    "Basement" },
    { &grund_besch_t::slopes,    "Slopes" },
    { &grund_besch_t::fences,   "Fence" },
    { &grund_besch_t::marker,   "Marker" },
    { &grund_besch_t::borders,   "Borders" },
    { &grund_besch_t::sea,   "Water" },
    { &grund_besch_t::ausserhalb,   "Outside" },
    { NULL, NULL }
};


When you synced from standard to experimental I think prissi's modification to the loading screen I implemented were still not made, but in simloadingscreen.cc, searching a bit, you'll find the code you are asking for. Was loadingscreen_t::set_copyright iirc, prissi changed it to something else afterwards.


If you need further details just ask, np.

[Fabio]

Why should this string be placed in an object the same size as a standard tile?
otherwise, I would add pakset info to biglogo.pak (possibly also renamed to paksetinfo.pak)

[jamespetts]

Hmm - the relevant code in Experimental is:

Code Select Expand


if(  grund_besch_t::ausserhalb==NULL  ) {
// defining the pak tile witdh ....
read_file((name+"ground.Outside.pak").c_str());
if(grund_besch_t::ausserhalb==NULL) {
dbg->warning("obj_reader_t::load()","ground.Outside.pak not found, cannot guess tile size! (driving on left will not work!)");
}
else
{
char const* const copyright = grund_besch_t::ausserhalb->get_copyright();
if(copyright)
{
loadingscreen::set_copyright(copyright);
}
}
}


(I altered the line from

Code Select Expand

if (char const* const copyright = grund_besch_t::ausserhalb->get_copyright()) { to

Code Select Expand

char const* const copyright = grund_besch_t::ausserhalb->get_copyright();
if(copyright) in order to diagnose the problem).

It turns out that "copyright" always has a null value, so the issue is in the code that sets the "copyright" value of "ausserhalb". Do you happen to know where in the code that this might be?

[Ters]

Why should this string be placed in an object the same size as a standard tile?
otherwise, I would add pakset info to biglogo.pak (possibly also renamed to paksetinfo.pak)

Probably because that tile contains the most basic piece of information that every pak set must provide. Any change to this is a significant compatibility issue, but doable.

[jamespetts]

Hmm - further research has turned up something odd: this problem does not occur when I load Standard paksets (such as the latest Pak128.Britain), nor very old Experimental paksets (such as Pak128.Britain-Ex 0.7.1, from about 2009); however, more recent Experimental paksets, which correctly display the version data in 10.27, do not show the version information in the latest RC/development builds.

[prissi]

Does the copyright show for other objects in the display. If not, then I suspect a pak format error ...

And fabio, Simutrans cannot get the tile size of a pak set, as those can have any size. Thus I decided a small pak file which I though will be always there. This is also an easy detection, if this is a pakset forlder or not. (A logo is not mandantory.)

[jamespetts]

Copyright does indeed correctly show for buildings and vehicles - is that what you meant?

[Markohs]

Probably because that tile contains the most basic piece of information that every pak set must provide. Any change to this is a significant compatibility issue, but doable.

Since ausserhalb/Outside is not needed anymore to display it, but it's for getting copyright/tilesize I suggest allowing a new type of object called "BasicTile", that serves for exactply the same purpose than the old one, except it won't be used, just measured for size, as it is now.

And I suggest, for backwards compatibility to allow reading both objects, giving preference to the new one. I can do this change if you desire so. Backwards compatibility with old paks will disappear anyway with new kieron's patch, so it's not really something so important.

[Ters]

I don't see much point in adding a new one-shot object type. grund_besch_t is so generic, essentially just a named container for images, that we might as well keep using it. A basic tile is more "grund" than much of the other stuff. And if we just keep the name, no compatibility hacks are needed.

We might however merge ground.Outside.pak with things like a logo into a pakinfo.pak file as Fabio suggested. As far as I could tell, a pak file can contain multiple named nodes, and the code that locates ausserhalb doesn't seem to care what file it comes from. But one would probably need to tweak makeobj into making such a special pak file, and code that looks for ground.Outside.pak to see if a directory contains a pak set, would have to be changed to look for either file.

[jamespetts]

May I ask - where in the code is the copyright for this object (ausserhalb) set?

[Ters]

Just like for every obj_besch_std_name_t, the copyright comes from the pak file during loading (second subnode, of type TEXT), and in turn from the dat file. It's nothing special about the copyright text in itself, just that it is exactly that string which Simutrans choose to display to identify the pak set. The pak build system (makefile) may also treat it specially in that it may automatically generate that (part of the) dat file in order to include svn revision number. Pak64 does this.

[jamespetts]

Hmm - I do not think that this is done for Pak128.Britain: the relevant part of the Python script is:

Code Select Expand


# Note, ground.Outside.pak must be in the top dir for it to be recognised as a pakset
echo Building ground.Outside.pak
build %OUTPUT% ./pak1file/128/


It is very curious that the copyright is missing on the groundOutside.pak here, however, but not on other objects.

Edit: May I check that I have the correct definition in the relevant .dat file? The contents of outside.dat are as follows:

Code Select Expand


Obj=ground
Name=Outside
# This field is used to give the pakset's version.
copyright=Pak128.Britain-Ex-0.9.0
# hangtyp * animation
#water outside
Image[0][0]=images/ls-water-128.0.0


Is there anything wrong with this?

[Ters]

I tried opening ground.Outside.pak from pak128.Britain-Ex 0.8.4 and 0.8.3 with the pak file reader from my PakViewer tool, and the copyright node was empty. While this tool doesn't support Simutrans Experimental, it was able to get what looked like copyright strings from a random selection of five cars in BritCitycar-Ex.pak. This suggests that the error is during generation of ground.Outside.pak, not in the game.

[jamespetts]

Hmm - is the .dat file above correct? If not, where ought it to be? If so, then I shall have to investigate further in the reader/writer modules.

Edit: Initial investigations show obj_writer.cc to be identical to the equivalent in Standard.

Edit 2: Hmm - obj_reader.cc seems to be the same, too. Even more odd.

[Ters]

It looks correct for all I know about Simutrans Experimental, but in situations like this, one should always double check that it actually is that file that is used. Try to run makeobj manually on that file only, copy the result into the installed pak set and see if that makes a difference. I have several times been looking at some file, trying to figure out why it isn't working, only to realize that either myself or the program was looking at the wrong file.

[jamespetts]

Hmm - I have checked, and it appears to be the only outside.dat in the /grounds folder, and is the only example of any file in the whole set of .dat files with the word "Outside", save for the makefile, which I do not use for compiling (using instead the Python script).

Further investigations, incidentally, show that the name object correctly appears as "Outside", but the "copyright" object is empty.

Edit: Ahh, I think that you were correct about the file location: because of the way in which the python script works, the outside.dat file is located in a special /pak1file directory, not in the general grounds directory: that file had not been included in my project, so I had not found it. Adding the copyright string to that appears in the game.

It seems that earlier versions used the folder name as a proxy for the pakset name, which had disguised the problem, but this is no longer done, the name being taken only from outside.dat.

[Ters]

I still suggest doing a test. When reading code, it's too easy to read what you think the code does, not what it actually does. Either hand build the pak file, or delete the dat and see if you still get a ground.Outside.pak. Running makeobj manually would also narrow it down to makeobj, or exclude makeobj from further investigation, a key principle in investigation.

[jamespetts]

See above...

Edit: Incidentally, what is the underlying purpose in having the pakset name sometimes set by this version string and other times set by the pakset folder name, depending on the context?

[prissi]

The copyright only contains the version, the pak set name is the folder name it is inside (since many paks do not set copyright of outside at all).