No Saves makes it impossible to play the greatest games.

[PicassoCT]

Are we there yet?^infinity

[CarRepairer]

No dsd makes it impossible to build the greatest nux.

No pathfinding makes it impossible to find the greatest paths.

Impossible greatest games... Y U NO SAVES!

[zwzsg]

I have put savegames into Kernel Panic, GRTS, EvoRTS, CA, BA.

[smoth]

I have put savegames into Kernel Panic, GRTS, EvoRTS, CA, BA.

oh look, someone who actually does work! Z can have some man love from meh!

[zwzsg]

oh look, someone who actually does work!

Nope, that was two years ago. I stopped working on it when I realised people were more interested in talking about it than using it.

[Google_Frog]

On an unrelated note, it'd be leagues easier for gadgets to be compatible with the current save/load system if the units (and features) could be recreated with the same unitIDs they had (unitID arg to Spring.CreateUnit(), perhaps)?

Currently you have to remap all the new unitIDs to the old ones, which is extremely difficult when the gadget in question is 4000 lines long and uses unitIDs all over the place (CAI).

This would be good. CAI works on luarules reload though so it's not a large problem.

[smoth]

oh look, someone who actually does work!

Nope, that was two years ago. I stopped working on it when I realised people were more interested in talking about it than using it.

much of this community is like that. Like politicians, they just talk and talk never actually doing anything or contributing anything. It is hard not to view them with contempt.

[Cheesecan]

Your expectations are too high. Just because you build something doesn't mean people will use it. You have to sell what you made because it's competing with a lot of other things for people's attention. Now you didn't do that so you're quite mad. People do this in their spare time so frankly you should not expect anything from them. So for instance if you want me to go write you saving routine, you are welcome to give me a salary offer, otherwise I will go on working on the things I feel is interesting to me.

Don't expect to get sympathy when you admit you quit because nobody praised you.

If what you need/want is to feed your ego and feel cherished, this is not the best place for that.

[smoth]

Your expectations are too high. Just because you build something doesn't mean people will use it. You have to sell what you made because it's competing with a lot of other things for people's attention. Now you didn't do that so you're quite mad. People do this in their spare time so frankly you should not expect anything from them. So for instance if you want me to go write you saving routine, you are welcome to give me a salary offer, otherwise I will go on working on the things I feel is interesting to me.

Don't expect to get sympathy when you admit you quit because nobody praised you.

If what you need/want is to feed your ego and feel cherished, this is not the best place for that.

YAWN. 2/10

[Cheesecan]

That high?

[Pako]

I did save/load system, didnt test too much but seems to work. Wasn't too hard because most of the work was already done but still way many hours more than these "I didn’t look into the source code yet, because I don’t think I will have the time to contribute in a useful way at all in the next few weeks anyway" people never would.

Currently you have to remap all the new unitIDs to the old ones, which is extremely difficult when the gadget in question is 4000 lines long and uses unitIDs all over the place (CAI).

There can be many broken gadgets but only way to fix is probably make all gadgets work with reInitializing themself after luarules reload.

[Google_Frog]

All ZK gadgets reinitialise themselves correctly but there are some things that require saved data if they are to reinitialise themselves such that the game doesn't change.

For example we have a capture unit that can take control of enemies. If the capture unit is killed the controlled unit reverts to it's original team. In terms of basic spring functionality the controlled unit is no different to any other unit. The gadget uses a table to link one unit death event to the transfer of the units it controlled to their original team.

On luarules reload the connection table is lost so any controlled units are now permanently on the team that captured them. A complete save/load system would not just need luarules reload safety, it would need to save the appropriate data from each gadget.

Are UnitRulesParams maintained with save/load? That would be useful.

[Niobium]

I feel efforts would be better spent on a system based on resuming play from a replay, instead of trying to do saving/loading through state which Spring just wasn't designed for. A replay-based approach also has a tonne of benefits, such as tiny save files, being able to load ANY point in a game, and an easier time integrating it with multiplayer.

[smoth]

would be cool nio.

[PicassoCT]

My mandate utters, after carefull consulting and advice, a recording device for replays, as to create cutscenes would be even more nice! No infringment intended...

[zwzsg]

I feel efforts would be better spent on a system based on resuming play from a replay, instead of trying to do saving/loading through state which Spring just wasn't designed for. A replay-based approach also has a tonne of benefits, such as tiny save files, being able to load ANY point in a game, and an easier time integrating it with multiplayer.

Replays easily reach ranges of several megabytes, maybe not big compared to the size of hard drives, but still much larger than my states save. There's no special difficutly in making state save with multiplaye either. Replay based save system have the disavantage of being bound to a very specific Spring version. They also take much longer to load. If the game lasted for an hour, even if your PC is capable at running the simulation at x5 speed or x10 speed, it still takes unacceptably long to load.