Spring RTS Engine

wee here it is


giant image for lols.


It is pretty much the same as I used in the last days for the automatic uploads with knorkebot. So it should work. I just added some comments and changed the output a bit. Also added a console thing so it is not just a black screen during processing. It takes longer now with this graphic but does not look like its hung up I hope.
That was nessecary because with logging unitmovements, processing takes longer now. (10sec for a really long DSD game on my 2800+ amd)

As the settings menu is not done, I made it so that it just outputs everything: html, the picture with playerlist (as on the website) and a combined eventmap of all gamelogs. ie to analyze multiple games and it shows destroyed units of all those games.

The widget is included in the .zip download.
Copy it into your Spring\LuaUI\widgets folder like any other widget. Then press F11 to open springs lua list and enable it. (It will stay enabled in the next game)
It must be enabled before the commanders are spawned, otherwise nothing is logged. (also you can then type "openlogfile" in chat but yeah...)
You can open it to edit some settings, scroll down where it says
---------------SETTINGS-----------------

I got rid of the haven to drag&drop also a .bmp as minimap on the .exe, instead the minimaps inside "minimapsbmp" folder are used.
I have included some mapimages. If you have Springdownloader and Irfanview installed, mapimages are autocreated. If not, only those inside the folder work. (for now)

Here is how I use it:


Download link:
http://www.file-upload.net/download-282 ... 0.zip.html
33MB due to the mapimages mostly

I put a whatsthis.txt in all folders.
If it does not work or you do not understand something, ask back. My main concern so far was only to make it useable by me...

smoth wrote:Can it do a heatmap yet for where units kill from or at least where they die on the map?

die from=no. do you want this? I think usually the killer is quite close anyway. Unless for superweapons etc.
where they die on the map=since the very start... thats the whole point of this project
It works without gundam too, just *a games are numerous and easiest to test with. (at least in last spring version, there is no gundam yet that works with 82 i think?)
Or do you mean real heatmaps, like with color gradients and blur? Thats coming...

ops, appearently forgot to include a folder and thus html export does not work.
unzip the attached file so that folders are like
demonaut\htmlhull\gamereport.html
demonaut\htmlhull\diagramm.js

Thanks again, been really busy with school past couple weeks and I'll be playing with this some today.

Just played a single player game and got some funky stuff, is there some way to get demonaut to save its output to a file instead of the directory it is in?

you mean like demonaut\gamereports so the output files do not not clog up the directory the .exe is in?
seems like a good idea and i will add this but atm not yet.

single player:
if you are playing while logging, the widget only logs what you/your allies can see. Spring does not allow widgets to see anything more than the player for anticheat reasons. Try with a replay or spectacting a game.

download doesn't exist any more... can you upload it to springfiles please? or better: create a github project?

imo remove AA defence since there is not specific placement for them, it just add noise to the data

abma:
this is two years old...not sure if I still have this somewhere.
The source is not that interessting anyway and iirc it was needlessly complicated.

albator wrote:imo remove AA defence since there is not specific placement for them, it just add noise to the data

there was something to filter out units by cost, iirc filtering out all defense under a certain cost removed the noise of missile turrets and mines.

I'd love to integrate demonaut into the replays site. It is basically a widget plus a pix+html-generator, right? So big question for me is: Do widgets run in spring-headless??

yeah, widgets run in spring-headless...

ok, I found the file from the dead link:
http://knorke.darkstars.co.uk/demonaut_ ... 9_2010.zip
fun fact: I started it on windows vista and it went bluescreen.
so yeah...

imo it would be much better if there was no external tool.
Spring can pass data from ingame to website, zK already does that for some things: http://zero-k.info/Forum/Thread/3258
So better make it full lua or lua+web stuff.

Oh and found this too and loled a bit:
http://pastebin.com/QM1hSCqY

you could write a widget that uses luasockets that directly posts to some website...

knorke wrote:ok, I found the file from the dead link

Nice - thank you.

Oh... this contains only the demonaut.exe - do you have the source code?

knorke wrote:imo it would be much better if there was no external tool.
Spring can pass data from ingame to website

abma wrote:you could write a widget that uses luasockets that directly posts to some website... ;-)

Hmm.. that means, that all users upload the same data at the same time to the autohost/webserver?

knorke wrote:Oh and found this too and loled a bit:
http://pastebin.com/QM1hSCqY

grep SApien :D

dansan wrote:Hmm.. that means, that all users upload the same data at the same time to the autohost/webserver?

hmm, i thought the script could be run on the autohost, but this would require to run spring-headless instead of spring-dedicated.
also maybe its possible to select only one host to upload and not all?

abma wrote:hmm, i thought the script could be run on the autohost, but this would require to run spring-headless instead of spring-dedicated.

That's what I could do on the replays server - for selected uploads, queued and on a dedicated core :)

I was considering implementing that for NOTA guys anyway, as they have coded a nifty SVG-dot-wars-movie-generator in lua, and wish to upload the movies to the replay site.

abma wrote:also maybe its possible to select only one host to upload and not all?

I thought about that too. The server could select one user, and tell the others to mute. But when that user drops, a recovery mechanism is needed... like other users queue info chunks and can be reactivated... but there goes simplicity and comes error proneness

Oh... this contains only the demonaut.exe - do you have the source code?

found it..it's so bad!
http://knorke.darkstars.co.uk/springmarker_source.zip
(50 mb because includes some minimaps as .bmp and other stuff)
There is a SDL_image.dll but does not seem to be used so I think this is not latest version but best I have.

----

svg is much than png better imo. Not only for dotwars but also other graphics.
You can even have websites pass variables to a svg, so you could change colors or turn on/off elements etc. (ie hide one team)
Seems a bit outdated to create static images when there is so much awesome stuff.

google graph seems good too:
https://developers.google.com/chart/int ... cs/gallery

Maybe one could also put information into the .sdf demo file?
At the end of game the logging gadget could just spam it all into chat and website could parse that.

Even more awesome would be if spring could write stuff to the demo and when playing it back, read the data again.
(ie: end of game save the length of match. at start of demo playback read it and use it to for a progress bar)

knorke wrote:found it..

Thank you. I'll take a look at it, when I have time again (in winter).

knorke wrote:svg is much than png better imo. Not only for dotwars but also other graphics.
Seems a bit outdated to create static images when there is so much awesome stuff.

Moving images cloud the mind - static images give your mind time to catch up to your imagination. (wise words by... me(TM))

Anyway - with the separation of data producer and gfx-generator it is possible to either use your code, or to implement something new in the preferred language on the preferred platform etc.

knorke wrote:At the end of game the logging gadget could just spam it all into chat and website could parse that.

After thinking a bit about the way zerok does it, it doesnt seem such a bad idea. A lobby-bot could listen in a channel to everyones messages. If each msg is tagged with a gameID and a frameID it could simply ignore the dups and at the end of the match transmit it all to a webserver.

knorke wrote:end of game save the length of match. at start of demo playback read it and use it to for a progress bar)

The match length is recorded in the demofile (gameTime). Springs replay mechanism just doesn't use this. I don't know if the information is available at runtime. If it were, a widget could display a progress bar...

With "not static" I did not mean "moving" but something like this:
http://www.schepers.cc/w3c/svg/params/ref.html

Anyway - with the separation of data producer and gfx-generator it is possible to either use your code, or to implement something new in the preferred language on the preferred platform etc.

yea, one idea was that as the gfx-generator got better, I could quickly re-generate the graphics from the data without running the replays again.
Also that made easier to plot data from multiple games into one image.

I don't know if the information is available at runtime. If it were, a widget could display a progress bar...

afaik it is not.
progress bar is just one example, could also note important events (like exploding commanders) and display them on the progress bar.
So that you know where/when to look.

abma wrote:I thought about that too. The server could select one user, and tell the others to mute. But when that user drops, a recovery mechanism is needed... like other users queue info chunks and can be reactivated... but there goes simplicity and comes error proneness

if the data size is small, every user can upload and the server can select / compare... broadcasting the data with a lua gadget is imo similar to that.

knorke wrote:With "not static" I did not mean "moving" but something like this:
http://www.schepers.cc/w3c/svg/params/ref.html

Ah OK :)
It'd be possible to create overlays that can be (un)shown... and other stuff... hmmm.... :)

I don't know if the information is available at runtime. If it were, a widget could display a progress bar...

afaik it is not.
progress bar is just one example, could also note important events (like exploding commanders) and display them on the progress bar.
So that you know where/when to look.

That plus a working "/skip" would be awesome.

abma wrote:if the data size is small, every user can upload and the server can select / compare... broadcasting the data with a lua gadget is imo similar to that.

OK... I have no experience with bots, widgets or gadgets :)
I thought having a redirection through a bot would help if the target server (or anything server side) changes. Because there'd be no need to change all the widgets of all users. They'd just have a lobby-channel hard-coded, and that's all.

OT: I just had a crazy idea: is lobby-channel-moderation secure? If it were, that could be used for a ingame widget auto-update function :D (ofc that's something that belongs into the lobby-prog, it just went through my mind, and I had to write it down ;)