for the love of God a Save Option. That lets you save and recontinue on multiplayer games with friends and even when its only you fighting 1 bot.
I had a huge battle with 4 friend lasted 3 hrs and the thing crashed it sucked to loose all that work.
For the love of God a Save Option!!!!!!!
Moderator: Moderators
-
cRaNbErRy MuFfInMaN
- Posts: 3
- Joined: 26 Sep 2006, 05:56
No, it doesn't. The problem is that's pretty much the only way to do any kind of resync/save/scenario/late join right now - there's no way to save that records/loads the _current_ gamestate. Only by playing through the whole history of the game (which, if you've tried it, is freakishly long to do on a slow box) can you actually join a game. This isn't a minor piddling difference, because it involves implementing a 100% accurate serialization system for all present gamestate, whereas the only thing that is recorded to do the "replay" style approach is to record the initial gamestate and all user-initiated changes (the rest of the state can be inferred based the user-changes.... but it takes time).10053r wrote:Cadyr: Thanks for the tip! That only shows to highlight just how close we are to a real save feature. I think this is a great request, especially since it offers SO much functionality for what seems like only a little effort.
mwha?! I'm not aware of a single game that allows saving midgame in multiplayer other than FPS type games and MMO's.
What you're asking is impossible, it would require that spring be able to resync.
And then there's the simple fact that doing that with a replay would take a huge amount of cpu power because it then has to run the game from the very start from that demo, and it will vary immensely from person to person, and at times could take 1-20 minutes for the average PC to fully replay the file at 20x speed multipliers, nm older PC's or long games.
Replays arent replays like normal files, they cant be rewinded etc. When spring runs it saves all the network commands it recieves to a file aka the replay. Then when it plays the file it just feeds those commands back into spring as the game plays, so there's no gamestate data saved just network commands and a startign script.
What you're asking is impossible, it would require that spring be able to resync.
And then there's the simple fact that doing that with a replay would take a huge amount of cpu power because it then has to run the game from the very start from that demo, and it will vary immensely from person to person, and at times could take 1-20 minutes for the average PC to fully replay the file at 20x speed multipliers, nm older PC's or long games.
Replays arent replays like normal files, they cant be rewinded etc. When spring runs it saves all the network commands it recieves to a file aka the replay. Then when it plays the file it just feeds those commands back into spring as the game plays, so there's no gamestate data saved just network commands and a startign script.
Because the messages at any point in time do not describe the game state. They can be seen as deltas, only when knowing frame N and the delta frame N one can calculate frame N + 1. Since frame N is never stored, you solution is impossible.MrNubyagi wrote:Since all messages are time stamped why can't you start from any particular point in the demo? Initialize the game as it initializeses when starting a demo, copy last known package time in a variable, do thetime = lastknowntime - 30 seconds or so and feed the engine al packages whos time is thetime as if the demo had started. Start paused so it would be sure everyone syncs.
So dont say its doable..., or make a patch yourself.If i don't know exactly doesn't mean it can't be done, but even more so its very doable. I didn't participate at this from the start so i don't know where to jump in and on what to document. More of it i don't have any experience in networking stuff.
Yes, this has several disadvantages tho, like much (as in really much) bigger replay files, because they need to include "keyframes" describing the gamestate at regular intervals. Probably means a size increase of 10-20x.Replays are scrollable if programmed to be. Rise of Nations has scrollable replays and its not the only rts with this feature.
You forget things like handling network connection initialization, making sure everyone loads the right savegame, etc. etc. Also adding in serialization isn't easy if you got to reverse engineer parts of the engine to figure out what it is actually supposed to do.Ussually in a TBS save games wil be found plenty. But most RTS game have a save game feature when playing with AI. All its needed is a timestamp that can be worked relative to the engine to create a savegame even for multi. I believe saving is made of the objects dump. I encountered something called serialization so far that resembles what a save game shoudl do.
All Spring needs is serialization i believe, or, an enhanceddemo system that would work as a savegame system.
You need keyframes too.Now the way to scroll is to read the timestamps. Its clear that the engine reads the demo and during play it writes to it. Therefore there are allready functions that take the timestamp as a parameter or there is some member data or whatever that works with time stamps. Either work a way to separate in a new file the stuff from timestamp x on or work on the actual demo file.
There don't exist any buildings or units in the demo. There only exists a set of initial conditions, like Map=blah, Mod=foo, StartMetal=400, etc., and a set of user commands.The buildings and units exist in the demo.Do they exist as a result of saved commands in the demo or are they cotained in the demo file as well? Can they be saved with F8?
Yes, everything is possible given sufficient time, which is exactly the problem.Now i also undertand that the objects allready in game might not appear in the demo. Well the save function should come in this saving every once in a while. Then sync the time of the save with the timestamps and recreate the game at that point. I don't know what it takes to make it work tough as i don't know the system but i am certain it can be made possible.
I am very confused, mostly because I don't really know how the engine works.What exactly is preventing Spring to have, apart from the replay recorder, a seperate function which when called at any moment, reads all the status of all units and weapon shots (perhaps in addition to other particles that are not purely for visual effect) at that particular instant, and then write them into a single file, aka a SAVE option? Is that because of the complexity of Spring engine, that simply a save file cannot reccreate what's really happening when being loaded? Or is it because such a save file would be way too large? Or is it just because there are not enough people who want it?
infact we already have code that does that courtesy of jelmer and his creg class.
To save a game press f8.
To load a game, start spring.exe and select load test.sdf
Any AIs in use wont be reloaded, and its not possible to continue a network game from this.
But if AIs where given something along the lines of
void Save(const char* savefile);
void load(const char* savefile);
Added to IGlobalAI and IGroupAI, and then where reloaded when a savegame was loaded, then that would be saving and loading sorted, and all we'd need is a way to specify which savegames are loaded and what filenames to save them too.
All the hardwork has already been done by jelmer It just needs a little extra work to finish it off. Namely an ingame save/load dialog, a way to specify a savegame in the commandline, and AI save/load support.
Network game saves that can be reloaded and continued as a network game later on are simply out of the question however.
To save a game press f8.
To load a game, start spring.exe and select load test.sdf
Any AIs in use wont be reloaded, and its not possible to continue a network game from this.
But if AIs where given something along the lines of
void Save(const char* savefile);
void load(const char* savefile);
Added to IGlobalAI and IGroupAI, and then where reloaded when a savegame was loaded, then that would be saving and loading sorted, and all we'd need is a way to specify which savegames are loaded and what filenames to save them too.
All the hardwork has already been done by jelmer It just needs a little extra work to finish it off. Namely an ingame save/load dialog, a way to specify a savegame in the commandline, and AI save/load support.
Network game saves that can be reloaded and continued as a network game later on are simply out of the question however.