As stated in the subject - all my saves up to Dec 4th have their pakset displayed, but all since Dec 8th have just space instead of pakset name.
This looks as though it may be a merge related issue - I wonder whether Ranran might have some idea about this...?
Quote from: Ranran on December 18, 2020, 09:10:11 AMAs previously reported, there is an issue where the save version cannot be read correctly. The version will be blank. (It is saved correctly just because it cannot be read. If you use an old client, you can check that the version information is recorded in the save data created by the current client)
I think that is the cause.
One of the possible problems seems to be the incorrect version. (Or the part related to this is incorrect)
#define SIM_SAVE_MINOR 7
#define SIM_SERVER_MINOR 7
But I have no idea what this version should be.
For example, current nightly build can't recognize the saved game version recorded by itself, but the it will read recorded version if you change it. But I couldn't find the number to read its own saved game.
I explained this before in that thread.
This may be due to the current version number. It could be displayed when changing the version number. I couldn't find a version number that could display everything correctly. So I asked which version number was right.
It seems that the version number is saved correctly in the save data when saving. Because they are displayed correctly when using older clients.
Ranran, sorry I don't understand what you mean...
In any case - current nightly shows pakset only in saves from December 4th and older. So there must be some change that happened between 4th and 8th of December, that broke saves in this way. Upgrade of bridgewater brunel, and maybe implementation of the new compression (lzstd ?) comes to my mind?
I remember coming to a different conclusion before because my symptoms are different from you. The cache file doesn't seem to be created correctly.
And just to make it clear, the missing pakset info does not make any problems - the games load normally.
/*
// read pak_extension from file
loadsave_t test;
test.rd_open(fname);
// add pak extension
pak_extension = test.get_pak_extension();
// now insert in hash_table
sve_info_t *svei_new = new sve_info_t(pak_extension.c_str(), sb.st_mtime, sb.st_size, test.get_version_int(), test.get_extended_version());
// copy filename
char *key = strdup(fname);
sve_info_t *svei_old = cached_info.set(key, svei_new);
delete svei_old;
*/
I remembered commenting out because I couldn't merge this part correctly. It would be helpful if someone could confirm or correct this.
Oh, since yesterday, the pakset is not shown at all. Not even for older saves. But the pakset info is stored, because I can start simutrans like: ./simutrans-extended -load test.sve And it loads the right pakset automatically. Otherwise it is a bit uncomfortable that for manual loading you don't know which saves are form the currently used pakset.
Ah I see it may be related to me deleting the cache.xml file... Anyway I uncommented the code mentioned by Ranran (gui/loadsave_frame.cc), and the pakset info is now shown.
Ranran, what is the problem with the code you mention? I have uncommented it, and the load dialog shows the pakset without any problems. Is there any reason to keep it commented/disabled?
If you uncomment it, it will only work if you have deleted all saves that before mass merge from standard (EDIT:) saved games with standard version 122.0. or later
I've been investigating this and found that the cause of the crash was when the standard 122.0 saved game is in the same folder as the extended saved game folder.
You can uncomment it if that crash is acceptable. But if not, we need to deal with it.
I don't think it's preferable because it's difficult for the player to find the cause when that happens. I took some time to determine that the 122.0 save was the cause.
I don't know why this happens. I would appreciate it if you could help us in this matter.
Currently I haven't checked all save file formats so some save file formats may cause a crash.
EDIT:
For example, this file (https://drive.google.com/file/d/1xZqYN1i1xd2l7kxZq6imULoeOixFdAiZ/view) will not cause a crash in older extended or current nightly builds, but it will always crash if you comment out the above line and opening the load save dialog.
The saved game is a normal file of standard 122.0.
EDIT2:
However, if the hash table already exists, it will not crash because it will not execute that statement. Delete _cached_exp.xml. Then, it will always crash.
It is a BZIP format save and the process of reading it causes an error. It gets an error in the code of classify_file and bzip2_file_rdwr_stream.
So it's not a GUI issue and it's difficult for me to deal with.
There are still some unmerged commits for them. But unfortunately it wasn't easy to incorporate so I'm not doing it.
https://github.com/aburch/simutrans/commits/master/io
I'm guessing that commits from r9620 onwards are related to this. They are not yet incorporated into extended.
It also seems that this can occur the other way around. In other words, having an extended save causes a crash in standard.
Put demo.sve of pak128.britain-EX in the standard save folder. Then crashes when try to open the load save dialog in r9274.
It means that the dialog cannot be opened. That is, you cannot load any save.
It also occurs with another recent extended's sve file.
Just as I commented out codes where extended causes a crash, it might be able to avoid the crash by doing the same with standard.
This seems fixed in the latest nightly on st\andard. It shows "(st-exp) - 2021-6-21" i.e. the filename and that this is an extended save.
I apologize for the inconvenience this issue has caused you over the past few months. (´・ω・｀)
Pull request #462 is a simple fix for this problem.
Please check if it works. Maybe you have a broken, unsupported save that causes a crash. In that case, you need to delete _cached_exp.xml.
This is similar to the problem that simutrans has when the configuration file is corrupted, and can be a stumbling block for many people if they don't know how to deal with it.
It's not clear how often this happens, though, and as prissi pointed out, it may have been fixed by embedding it from the standard. I used to have the crashing problem, but now I can't reproduce it.
The integration from the standard has changed the structure of the GUI, so it is not in the same style as before.
I have now incorporated this: this does seem to effect a significant improvement, including fixing a longstanding bug with the order in which saved games are displayed. Thank you for this, and apologies for the delay in incorporation.