VERY Strange Situation

[davcefai]

I have a contract to deliver 12,000g of gemstones to Quzaarar in Galaxy 4.

It so happens that Quzaarar overlaps Riusbequ. Whem I select Quzaarar as my destination I get there but, on the way to the planet my location changes to Riusbequ!

OK, I carry on to the station, dock, sell booty, refuel, try to jump to Quzaarar, same old story.

Jump elsewhere, try again, end up in Riusbequ.

So I decided that it was a justifiable cheat to edit my save file. I altered the contract destination to Riusbequ by changing the planet number. launched from the station, docked again. No droids unloaded my cargo.

I then jumped to a nearby planet, jumped back to Riusbequ and successfully fulfilled my contract.

Now for the really strange bit:

I can quicksave but when I tried to save as a new commander I found myself in the "Game Options" menu. At that point I could get back to the game. However after exiting and restarting the game, once I try to "Save Commander" and find myself in the "Game options" menu I can get out of this menu but cannot get back into the game. I can only exit the game.

Loading other saved games does not result in this behaviour. Only the game I "hacked" does this.

So there are 2 problems:

1. Quzaarar changing to Riusbequ.
2. Menu problems.

Has anybody else come across anything similar and can anybody suggest a workaround?

[another_commander]

Confirmed. This seems to be a problem that occurs if you have many files in your saved games folder. I suspect something going wrong with setting up the list of saved games that is shown on the relevant screen. This is not a new problem, it goes as far back as 1.68 and happens with a slight variation (not sure about 1.65, will check at first opportunity. On 1.68, if you have many saved files and click to load one of them, it would sometimes throw you to the startup screen with a message like "Unrestricted Play Enabled").

Workaround: Remove some saved games. Leave only 6 or 7 of them and retry to load your game.

[davcefai]

Workaround worked around

Thanks

[Eric Walch]

This seems to be a problem that occurs if you have many files in your saved games folder.

there is also an other reason not to have to many games in the folder. I noticed that in full screen mode, it takes more time to buildup the save file screen when there are more files in the folder. On slower machines like mine, it takes a lot of time when there are more than 50 to 100 files in the save folder.

[Hoopy]

It also seems to do a lot of work when you try to select a save file prior to loading one. It obviously has to parse enough to read in the ship type, credits, commander's name and number of kills (or whatever it is you get in the little summary) but that shouldn't take a whole second.

For that reason alone I only every have a few save files (and move the excess to another directory) as I'm too impatient to spen 5 second scrolling down through 5 of them to get to the latest one.

Maybe I should name my commanders with a decreasing number at the end so the newest one apears at the top?

[another_commander]

It also seems to do a lot of work when you try to select a save file prior to loading one. It obviously has to parse enough to read in the ship type, credits, commander's name and number of kills (or whatever it is you get in the little summary) but that shouldn't take a whole second.

Most of the delay is finding the system name, because it has to run the galaxy generation seed stored in the save file. On my system, it can usually switch between saves in the same galaxy pretty normally, but if I reach a save file set in a different galaxy, then it takes plenty of time. But I think that the current location is a piece of information that has to be there, in the summary of the file, so I would not like to have it removed, really, even if it takes longer to browse through games.

[Hoopy]

surely it wouldn't take that much RAM to store the name of every system? then it wouldn't have to regenerate it all every time.

[another_commander]

Point taken. And fixed. Now Oolite writes the name of the current system in the save file and looks up this, instead of generating an entire galaxy database just to grab a name. To maintain backwards compatibility, if the current system name key is not found, then it falls back to using the galaxy information to extract the system name. Speed when traversing saved game lists has been drastically improved.

[Hoopy]

cool

[JensAyton]

On a wider topic… quite a few slowdowns (and, until recently, leaks) in Oolite seem to be related to generating system information. Obviously some or all of this could be cached, but a significant design problem is that there is insufficient abstraction; various system info look-up tasks are done in approximately the same way in various different parts of the code.

Still, caching the derived information – system names and descriptions, for instance – for all four thousand systems shouldn’t actually use very much memory. It’s definitely something to look into.

[another_commander]

Workaround worked around

Thanks

Better workaround: Build trunk SVN 1299 and try again. This has now been fixed. You can have as many saves as you like in your folder again. It was apparently some issue with the gui controls.

[Influence D]

I've built the 1.7 code for 64-bit Ubuntu 7.10 (from the oolite-dev-source-1.70.tar.bz2 archive on the downloads page, not from SVN - not sure what revision that is) and I've just had this same issue - in my case, it only occured for the last save game in the list, and was being caused by too many screenshots, not saves, in my oolite-saves folder... not sure if that merits a mention or not.

I moved them to another folder, and everything is peachy keen once again.

Up until I found this thread I thought it had something to do with being in the shipyard before going to the save screen - glad I did a search

[Influence D]

Hmmm - it just started happening again, and I didn't add any files to the directory (saved over an older file, not the last one on the list this time). Moving a few more saves out has unbroken it again. It might have something to do with the SIZE of the save files, as well?

[another_commander]

No, it has to do with the way the version 1.70 and earlier gui code handles the selected row on the screen. Try this: Make sure you don't have any subfolders inside oolite-saves. Put plenty of save files inside oolite-saves. Run Oolite. Go to the load game screen. Select the 8th file from the list of saves (don't count the (..)oolite.app entry). Once loaded, try to load a game again. You will be thrown to options screen. Incidentally, the gameoptions selection in the options screen happens to be in the same row as the eighth game from the list you just loaded. The game keeps the selected row number in memory, but loses the context in which it is selected. This is fixed in the current tree.

The version you are building from is revision 1255 or 1256 (1.70-linux), while we are already on revision 1312 on the development tree. You can get the latest sources using Subversion as described here (link is for Windows, but the Subversion instructions apply to Linux, too). It is recommended that you go ahead and try, because many more bugs, apart from this one have already been fixed in the newer unreleased revisions.

[Influence D]

ah - I was just posting in case the bug was different to what was mentioned before. or magically related to the 64 BITS OF RAW POWER that is my OS, somehow.

re: the SVN source - will be doing that this weekend, most likely; but having taken so long to work out how to get it compiled in the first instance, I thought I might PLAY it for a while first...