Spring RTS Engine

We've had discussion for a long time now about generating replay animations (dot wars) from the games you play. The problem is you cant read enemies positions with widgets, so you have to re-play the replay to write the animation data.

Can we have engine side gadget for this?

The data should be in a simple and efficient format (avoid repetition), so any widget could read it in the end of the game and generate their own formats if wanted so.

Use a spectator, otherwise youll force me to do a proof of concept cheating widget that reads your gadgets/widgets output

AF wrote:Use a spectator, otherwise youll force me to do a proof of concept cheating widget that reads your gadgets/widgets output

Who said anything about outputting it during the game and not at the end?

for one unit there should be at least:
-unitID
-uDefID
-time created
-time finished
-time destroyed
-position log (constan time seperation)
-position where destroyed
-array of times and teams of owner changes

could probably get away with tracking positions per second and just use bicubic smoothing on clientside (this works great with my mouse path tracing widget)

I could also modify my path tracer to work with this unit position stuff (even in a widget) to offer a cool overview of unit paths as the game progresses

AF wrote:Use a spectator, otherwise youll force me to do a proof of concept cheating widget that reads your gadgets/widgets output

I can already cheat without any gadgets, dont worry.

Another engine request that should be a game request. This is a bogglingly stupid thing to do in the engine.

• The behaviour would be game specific.
• It is dead easy to implement as a gadget.

Make a game side gadget to collect the data you want and berate whichever gamedevs you want to include it.

How exactly we cant make it work on every mod?

TradeMark wrote:How exactly we cant make it work on every mod?

Sure you can make it work on every mod but not with every game.

3 main reasons mainly to do with the flexibility of Spring.

1) Some data collected will be useless or confusing. Unit creation, finishing and destruction are used for non-gameplay purposes.

The best example is the morph gadget. A unit is destroyed and another created, this would be detected by the engine (no I don't want a special "Ignore this for stats" tag, it's bloat).

KP network packets is another example.

There are many other gadgets that use creation and destruction. There are a lot of things that can be done with gadgets that I have not thought of and no doubt there are a lot that would break any engine side system.

2) Games with different gameplay may want other data that is not supported by the engine. In this case they would have to write their own duplication of the functionality. It is much better to write a gadget that game devs can then modify for their needs.

3) Some games might not want this so it's just bloat.

CA (and s44 I think) already use a stats tracking gadget.

Yeah, but how would it not be able to create "dotwars" animation from that data with every game/mod ?

All in all, its just dots that are moving, if the game/mod has units in it, you should be able to track those units positions and make animation... right? Thats really all we need to do the dotwars. I wouldnt mind if it didnt have commanders visible etc. This would be very handy to quickly view the games youve played without launching in spring.exe and fast forwarding for 2 hours... So basically im suggesting a way to preview your replays quickly.

Also, i didnt suggest this gadget would be default on.

Yeah, but how would it not be able to create "dotwars" animation from that data with every game/mod ?

Not in it's current state. But as a gadget the gameside stats can be easily changed without engine update!!

The gadget would print a large list of data to infolog which could then be auto parsed by a program.

Google_Frog wrote:

Yeah, but how would it not be able to create "dotwars" animation from that data with every game/mod ?

Not in it's current state. But as a gadget the gameside stats can be easily changed without engine update!!

What... its not possible to get units coordinates from every mod/game with one single method? Why?

Google_Frog wrote:The gadget would print a large list of data to infolog which could then be auto parsed by a program.

Thats not very userfriendly way in means of bug tracing (you want to dl 50megs infolog file?) Cant gadgets create own files..?

If you go for engine support, then you should do it all the way: Have the engine autocreate an animated gif of the minimap and embed it in the demo file.

zwzsg wrote:If you go for engine support, then you should do it all the way: Have the engine autocreate an animated gif of the minimap and embed it in the demo file.

I wouldnt make gif because i cant modify the look of it afterwards (for example scale it bigger, or play it slower/smoother), IMO outputting pure data is best since you can read it with flash program as you wish and render it as you wish. OR make own program to display it as you wish... OR even make JS animation from that data.

Basically we just need another replay format, binary! no XML bloat crap D:

The best example is the morph gadget. A unit is destroyed and another created, this would be detected by the engine (no I don't want a special "Ignore this for stats" tag, it's bloat).

KP network packets is another example.

There are many other gadgets that use creation and destruction.

To work around this I now use the UnitDamaged callin and check if damage taken > current health to get "real deaths"

IMO outputting pure data is best since you can read it with flash program as you wish and render it as you wish. OR make own program to display it as you wish... OR even make JS animation from that data.
Basically we just need another replay format, binary! no XML bloat crap D:

xml or something else textbased is easier to parse than binary.

If you go for engine support, then you should do it all the way:

Yes.

Have the engine autocreate an animated gif of the minimap and embed it in the demo file.

No.
Or at least, not only. Export data in a way similiar to what Pako wrote and let us play around with it.

1) Some data collected will be useless or confusing. [because spring games are so different in some aspects]

Let the parser figure out how and what data to use. If energy and metal bars show random values let the parser ignore them.
I think the most important things are the same in every spring game:
-units position, health, destruction etc
-players dying, winning
Its a pity that ie flag positions in S44 would not be saved but that does not matter so much.
A lot can already be done with this. Definetly a dotwar like preview.

tl;dr
Make engine output unitpositions, health,bla etc after the game ended in a textbased format either included in the replay file or a second ".replayextradata" file.

knorke wrote:xml or something else textbased is easier to parse than binary.

No lol, binary doesnt even need parsing.

XML or something textbased is for humans. You dont read and render this code by your own very eyes...

Also binary data will be much more packed. Less upload time too.

--

Why dont we make the actual spring replay format in XML...?