Spring RTS Engine

would be nice if replay could play not only forward but also backward. guess that is probably not even too difficult todo. It would sometimes help identiyfying bugs cause u can literally "replay"critical situations over and over without starting the replay from zero.

I don't think that's possible.
It would require the engine to keep a log of all destroyed units (and thus deleted objects) in memory additionally to keeping undo-data for operations that are not strictly arithmetic - like value assignment. That would probably not only blow you RAM, but also your HDD.

well the save file from replays are very small so i guess everything it does it is just saving all the inputs from Players like command, text etc. and the rest is calculation. so it must be possible to revert it somehow.

Exactly: the replay file contains no state, only actions.
So the state of the simulation must be calculated for every step.
To go back a step, you'd need a reverse operation.
For addition that's substraction - simple.
But what if I select all units and right-click somewhere on the map?
The active operation for all units will be set (overwriting the previous command) to "move" or "attack" and they will compute a way there (or start to attack immediately) and change the direction of their bodies etc.
No calculation can get you back to the situation before the click, only saving all parameters of all units - that means the complete game state - that's hundreds of mega bytes of data. Now that was just for one frame - that's a fraction of a second. To go back a few minutes, you'll have to have saved thousands of game states - petabytes of data.
In case you know how video compression works: imagine a video file with no i-frames.

so if you Right click Units somewhere on the map…. (fucking automatic writing correction on Edge which i have turned out at least 10 times and after a while it enables itself- probably at every update)…. so u Right click and Units move somwhere and is arriving at new destinition. u have all commands, u have new and old Position and then start reading the commands backward. only Thing that is needed is a backward Simulation which inverts Speed, direction, and the visible movement. Maybe its more work than i thought but it should be possible.

It isn't workable, for the reason explained by dansan.

Commands change the state, but not always in a way that can be reversed - they can overwrite information, after which this information cannot be recovered without looking (typically very far) back into the past and then re-performing very many calcuations.

that is probably not even too difficult todo

I suspect you may be in management, so here are some free tips to improve your style and relations with your underlings:

• If something seems easy or obvious to you but has not been done yet, assume that it is probably hard.
• If you want to show this assumption is wrong, do some initial work on your own as a proof of concept and let others pick it up from there.
• If you can't do the work yourself, accept the opinions of people who can when they tell you it is actually hard.

Here is a relevant metaphor: https://www.youtube.com/watch?v=cSbyCI32CH0

The roadmap for better replay controls looks something like this:

• Engine save/load (feasible but extremely involved).
• Optimization of save/load to allow for brief autosaves (probably impossible).
• Integration of autosaves into replays to allow people to, say, snap back to back to whole-minute timestamps (relatively easy).

From talking to hokomoko, the timeframe for save/load ranges from a few years to never.

@Kloot i dont want to breaks ball nor it is true what u might want to say that i cant accept other opinions. i had an idea - i posted it and discussed it. trough a discussion there might be different sight, meaning Knowledge for this reason it is a discussion otherwhise it is a monologue. a discussion helps to understand Things - in this case me - how sth work. so no reason the be offended. thanks dansan and silentwing for explanantions.

Flaka wrote: ↑21 Dec 2018, 11:02 a discussion helps to understand Things - in this case me - how sth work

I think what Kloot says still stands, however I might add: If your aim is to gain knowledge, a question is probably what you want. And it's still useful to assume that it's going to be hard. It's also useful to keep in mind that it might have even been suggested before – this is why you're supposed to check before reporting bugs.

yeah, ok i got it!

Does this mean there are no random numbers used in spring engine?
Or is it maybe a seed?

There are no real random numbers in computation? unless you have external sensors too non deterministic real world data. And as the sim has to be sync aka the same after all input steps on all computers, random has to be the same for machines. Spring uses the Mersene Twiste for random, and although the results are slightly biased due to luas number range skewing the outcome its overall a very good random.

No, why does spring not have backwards replay ability and why do lots of other commercial engine do not have that as well or just some approximation like jump to replaysafe point at fixed time XY (like Halo 1 Engine).

Because the replay does not contain what happened in the game. It only contains all input.
Your replay for a deterministic simulation engine only contains all inputs, be it chat, mouse movements and keyboard inputs. If used with the same engine and the same game, the input can replay the game. Replay as in fast forward all input steps and simulation to the point in time the player wants. To speed that up, you can create subsavegames, as in points in time from where to start from. But let's say you want to actually reverse the flow of time. How to do that? Because that would make it necessary to really save all that happened since last input and then inversing them chronological.
And that one is hard.
Real hard as in a lot of game engines for money don't do that, cause so little is gained by it. Sometimes people don't do simple stuff not because they are lazy or evil. They don't do it because you demand water to flow up the river.

Save/Load is doable, has even been implemented a couple times. Including autosave. They're imperfect (no projectile, unit scripts reset, etc..) but still serviceable. Wouldn't work with replays though, since replays works with absolute exact state replication.

Can save/load not be implement as an open-ended replay? That way there'd be no special handling required.

tbh, luasave should be adequate. Just save positions, queues, and resource levels. Understand that projectiles and nanoframes will be lost when saving. That is good enough.

Losing anything while saving is not good enough for replay save/load. However, it may be good enough for standard save/load if your players aren't trying to exploit anything.

I can imagine that it'd be handy to setup missions.

Google_Frog wrote: ↑22 Jan 2019, 15:02 Losing anything while saving is not good enough for replay save/load. However, it may be good enough for standard save/load if your players aren't trying to exploit anything.

oh no, I meant just for general use case save load

dansan wrote: ↑22 Jan 2019, 15:46I can imagine that it'd be handy to setup missions.

Indeed.
Except I would use past tense instead of conditional.