OpenXcom Forum
Contributions => Programming => Topic started by: grrussel on May 27, 2013, 01:59:13 am
-
Patch is attached.
-
nice, nice, how about sorting by the (potential) turn counter as well?
-
Would need some means of saying a) this save is a battle save and b) it has N turns elapsed. Don't see a trivial bit of code to do that, on a quick look round in the code. Pointers?
-
in order to gather that info from saves, for instance, 100 of them (which can be in user folder) program will need to load each save file, and extract particular values. i don't see how it can be feasible without huge delay and lots of harddrive work.
-
maybe a small "info string" could be added to the savefile name, and ignored for in-game display purposes? I'd guess it only needs to be a few characters to convey the information we need for sorting.
-
savefile name? No. Names could be any. And easily could renamed. And what will it do in this case?
-
The existing system opens each save game file in any case, to get the game time - the UI then translates the game time into a localised date / time for display to the user. Sorting by time adds no noticeable overhead. It seems to be sufficiently fast at present, I have 56 save game files present in the same folder.
So, I doubt checking a) if battlescape and b) what turn in the battle it is, would add any more overhead. Its more how to determine the values for a and b.
-
The existing system opens each save game file in any case, to get the game time - the UI then translates the game time into a localised date / time for display to the user. Sorting by time adds no noticeable overhead. It seems to be sufficiently fast at present, I have 56 save game files present in the same folder.
So, I doubt checking a) if battlescape and b) what turn in the battle it is, would add any more overhead. Its more how to determine the values for a and b.
The reason the current system works is because the date is stored in a YAML subdocument separate from the rest of the data (you have to parse the whole document to access any field in it), so it only has to parse that to list the saves. Parsing all the savegame data for the listing would be extremely cumbersome.
So checking a) and b) is actually trivial (it's just one var with the turn), but to use them in the listing you would have to save that data in the subdocument. And you'd get the inevitable "but I wanna see both the date and the turn" and run out of space.
-
Cool. Well, if looking deeper into save games would make the process too slow, then I guess the patch can applied as is ;-)
-
Newb necromancer reporting for duty. ;D :-[
Will this (save files sorted by date) make it into 1.0?
-
Yes.
-
Awsum.