3.1 beta4 has been released! (And beta3 has been skipped.)

[NoQ]

can't you guys just use the same stuff in 3.0 beta 4 for save/load games?

Of course not!

[zany]

can't you guys just use the same stuff in 3.0 beta 4 for save/load games?

Of course not!

why not?

[Shadow Wolf TJC]

can't you guys just use the same stuff in 3.0 beta 4 for save/load games?

Of course not!

why not?

Lack of backwards-compatibility?

[cybersphinx]

can't you guys just use the same stuff in 3.0 beta 4 for save/load games?

We'd need to revert all the new savegame stuff, then backport any new additions (the javascript stuff maybe) to the old crappy code, and then we're back at ugly binary blobs that break as soon as you want to change anything. And then we'd still need to fix the new format for future releases.

[zany]

can't you guys just use the same stuff in 3.0 beta 4 for save/load games?

We'd need to revert all the new savegame stuff, then backport any new additions (the javascript stuff maybe) to the old crappy code, and then we're back at ugly binary blobs that break as soon as you want to change anything. And then we'd still need to fix the new format for future releases.

what difference does that make? if that worked and the new way don't then roll back?

[aubergine]

@cybersphinx - For persisting Javascript stuff, there is a much better approach that can be used...

1. Add localStorage and globalStorage globals.

Each has the following methods:

* setItem() -- add an item to storage
* removeItem() -- guess what this does (:
* clear() -- removes all data from the object.

In particular, setItem() would scan the data being stored to make sure it's not got any functions or other non-saveable stuff in it. It would throw an error if there is non-saveable stuff in the object to be stored.

sessionStorage = stuff to go in the savegame file

localStorage = stuff to be saved in the user profile folder, with filename based on JS script that's using it (ie. this is persistent cross-game storage, which would allow AIs to learn about players from multiple games!)

2. When it comes to save the game...

(pseudo-code:)

var saveGameData = JSON.stringify(sessionStorage.data);
var scriptPersistentData = JSON.stringify(localStorage.data);

As the results would be JSON (JS object notation) you wouldn't be able to store them in an ini file, instead the string would get stored in a plain text file.

3. On starting a game

localStorage.data = JSON.parse(scriptPersistentData);

3. On loading a game

sessionStorage.data = JSON.parse(saveGameData);
localStorage.data = JSON.parse(scriptPersistentData);

4. Spot the obvious issue...

If a game has several of the same AI script running, each of them will want the same localStorage. But, this can be worked around by having special setItem(), removeItem() and clear() methods. Because only one script can be active at a time, there is no chance that you'll get several instances of the same script reading/writing at the same time.

Needs more ponderance, and I assume localStorage would be hardest to implement, but using JSON notation is a proven reliable way to store/read, well..., JavaScript Object Notation (:

The current weirdness that's going in to the ini files in the savegame makes any type of debugging very difficult, especially for JS objects/arrays that get persisted because they get converted to some weird gibberish that's not human-readable.

[Emdek]

aubergine, it could be INI.
But better way than using JSON directly would be to have calls to set, get, clear options which would be saved in special section of save game file in INI format (QSettings can store not only text values). It's a bad idea to introduce next file format as INI can save that data just fine (including multi level structures).

[aubergine]

@Emdek the way objects/arrays are stored in ini files is grim as toast. If I'm trying to debug a savegame, it would help a great deal if I could see the JS objects in JSON rather than some weird escaped format that the ini file uses.

The sessionStorage could get put in to savegames as a series of .js files, one for each script for each player.

For example: If there were 3 NullBot AIs on a 4 player skirmish map, then the following .js files would get created in the savegame:

* player1_nullbot_1.0_sessionStorage.js
* player2_nullbot_1.0_sessionStorage.js
* player3_nullbot_1.0_sessionStorage.js

The format is:

* "player" + playerID + "_" + AI filename (without .ai) + "_sessionData.js"

This way it will be trivial to understand which dollops of JSON belong to which player / script, and it's really obvious where the data will be accessed by the script (sessionStorage).

And only stuff in sessionStorage will get persisted and this will make life easier because devs won't need to worry about what they store on global. It will be very obvious within scripts what's accessing sessionStorage and localStorage = stuff to be persisted.

Right now, it's very difficult to see what stuff will/should get persisted - anything on global object (whether intentional or not) that isn't a function and isn't a JS API feature and isn't a constant (I think) will get persisted. It's all too easy for devs to accidentally or unintentionally put something on the global object that they didn't intend to go in to the savegame.

Using sessionStorage and localStorage will make devs think consciously about what they are putting in to savegame files. And it will allow the JS API to check (via setItem mehtod) that what they are putting in is valid for a savegame, throwing a descriptive error if not.

I'm aware that there is a desire to make life easy, hence the current approach of "try and save all stuff on global", but this is a false notion. It's the equivalent of saying "it doesn't matter if devs use the correct syntax in their scripts, it should just work" -- of course devs have to use the correct syntax, otherwise it will break. And I think with persisting data, we need some prescriptive syntax (ie. if it's not in sessionStorage or localStorage it doesn't get persisted).

[aubergine]

Also, sessionStorage (at least) will be backwards compatible. It's easy to add a fake sessionStorage object if one does not already exist, and the current JS APIs will just store whatever is in there in the .ini files. New JS API would JSON the contents and store in .js files as mentioned above.

Other alternative, perhaps better, would be to have eventSaveData() and eventLoadData() events. saveData would let the script know it needs to get stuff in to sessionStorage because the game is about to be saved. loadData would let the script know that a game containing sessionStorage has just been loaded (specifically that the sessionStorage object now contains the loaded data)

[Emdek]

aubergine, please don't compare how it works currently to as it can work (I've first seen that weird escaping in WZ save games).
With custom INI parser we could have things like (there is no standard anyway...):

Code: Select all

[section][children][child1]
property=some unescaped (except for \n character) UTF8 value
anotherProperty=some value
one more property=blah
[section][children][child2]
foo=bar

Or:

Code: Select all

[section/children/child1]
property=some unescaped (except for \n character) UTF8 value
anotherProperty=some value
one more property=blah
[section/children/child2]
foo=bar

[aubergine]

That's still deeply hideous compared to JSON.

With JSON, a JS dev can see at a glance exactly what is stored. With the proposed ini format above, it would take me ages to find anything. I really want to be looking at JSON, not some Windows ini file weirdness.

Also, remember that properties in JS are just strings - they can contain anything. For example, "[section]" or "foo=bar" are valid property names in JavaScript!

Try:

var obj = {};
obj["foo=bar"] = true;
obj["[section]"] = true;

Using JSON and putting the results in to a .js file is a really simple way to avoid the game breaking on all these fringe cases. It's a tried and tested way of getting javascript objects represented by text. If it's valid in JavaScript then, with the exception of things like functions that .setItem() can throw out, JSON can handle it both for stringyfying and parsing.

Simple, reliable, readable, widely adopted (eg. by the entire internet = I'm pretty sure it will work well).

Adding ever more kludges to ini files to make them do something they weren't designed for doesn't strike me as a good direction.

[Emdek]

The main issue is these files aren't meant to be edited.
For such needs I can create editor that will visualize that in a way that JSON does.
I'm just against adding another file format along INI files (which has exact same possibilities).
And you can escape characters in keys / sections too (not by hand, game game would do that for you), no problem.

[Lord Apocalypse]

I have two possible issues.

Downloaded and installed last night, started a quick game and noticed two things. First, when I set my units to retreat at moderate damage (yellow bar) only one of two units actually went back to base. Reselected remaining group to reset damage retreat and the sole yellow unit did not retreat. Is the retreat on damage now based on damage % or still based on Dead, Red, Yellow?

Second, right mouse use to swivel the map around.. Sometimes worked sometimes it didn't or would act really flaky and only gave me partial movement.

Will try again later this evening to see if things have changed and it was just an odd fluke but figured I would give a heads up just to be safe

[Emdek]

Lord Apocalypse, there is for sure (I've seen that myself often) that there is 1% difference between yellow bar start showing (AFAIR from 25%) and medium damage being reached (from 26%).
There is ticket in trac for this issue.

[aubergine]

@Apocalypse: With the mouse swivel thing, I had that happen to me last night - can you confirm if it happens more when you've got the camera close to the ground (ie. you can see the sky in the distance)? I normally play with the camera looking down on the map at an angle of about 45º but when the camera is pretty much parallel to the land (making all the sky visible in distance) it seems to freak out.