Default Gui Endgame Screen

[Forboding Angel]

Could you guys (Engine devs) change it to be these colors?

The only thing missing is the orange grid. The orange grid should be much more transparent as to not impede viewing of the graph.

Orange isn't really a good color for them either. Perhaps a 50% transparent mid-grey?

Note that the box is outlined with 1px flat black. Not a dealbreaker, but would make it look so much more fantastic.

[abma]

sounds for me like it should be implemented in lua... not sure if thats already impossible or if some data is missing to do so.

[smoth]

well, something I began work on about a year ago and tabled for other stuff. You will need to log statistics throughout the game. Using the standard one is pointless there are too many project specific stats which are more relevant. IMO the graph should be dropped or turned into a widget.

[Jools]

well, something I began work on about a year ago and tabled for other stuff. You will need to log statistics throughout the game. Using the standard one is pointless there are too many project specific stats which are more relevant. IMO the graph should be dropped or turned into a widget.

I also started to work on one at one point. Totally agree with smoth about the precense of irrelevant data:most people just look at metal produced and damage dealt graphs. With own data you could also show who killed who, which was my idea at the time.

It would also be good if you could add a tab to that table for custom data. Finally it would be nice to get rid of that 'ally-team' word. People don't know what that is.

[knorke]

to change background include a graphPaper.bmp with mod

[Funkencool]

just curious in case I ever think to mess with it, is there even a way to disable it lua side (specific command/call) to replace it with a custom one?

[knorke]

Spring.SendCommands("endgraph 0") for off 1 for on

[SpliFF]

If you can turn off the screen then you only need the raw statistics and you already have access to that (esp: Spring.GetTeamStatsHistory)

The only missing piece is a chilli/redui widget that actually displays the data.

http://springrts.com/wiki/Lua_SyncedRead

Code: Select all

Spring.GetPlayerInfo

 ( number playerID ) -> 
   nil | string  "name",  (PRE-83.0: in synced code this is "SYNCED_NONAME"!)
         boolean active,
         boolean spectator,
         number  teamID,
         number  allyTeamID,
         number  pingTime,
         number  cpuUsage,
         string  country,
         number  rank
         table   customPlayerKeys

Spring.GetPlayerControlledUnit

 ( number playerID ) -> nil | number unitID

Spring.GetAIInfo

 ( number teamID ) -> 
         number  skirmishAIID,
         string  name,
         number  hostingPlayerID,
         string  shortName, (synced => "SYNCED_NOSHORTNAME"; non-local => "UNKNOWN")
         string  version,   (synced => "SYNCED_NOVERSION";   non-local => "UNKNOWN")
         table   options    (synced & non-local => empty-table)

Note: Before 0.82, the first argument was teamID, and then every other argument with a shifted position.


Spring.GetAllyTeamInfo

 ( number allyteamID ) -> nil | table   customTeamKeys

Spring.GetTeamInfo

 ( number teamID ) ->
   nil | number  teamID,
         number  leader, (:= a player id)
         boolean isDead,
         boolean isAiTeam,
         string  "side",
         number  allyTeam,
         table   customTeamKeys,
         number  incomeMultiplier

Spring.GetTeamResources

 ( number teamID, string "metal" | "energy" ) ->
   nil | number currentLevel,
         number storage,
         number pull,
         number income,
         number expense,
         number share,
         number sent,
         number received

Spring.GetTeamUnitStats

 ( number teamID ) ->
   nil | number killed,
         number died,
         number capturedBy,
         number capturedFrom,
         number received,
         number sent

Spring.GetTeamResourceStats 0.82 and later

 ( number teamID,  string "metal" | "energy" ) ->
   nil | number used,
         number produced,
         number excessed,
         number received,
         number sent

Spring.GetTeamStatsHistory

 ( number teamID [, number startIndex [, number endIndex = startIndex ]]) ->
   nil |
   number cur_max_index |
   {
     [1] = {
       "time"             = number,
       "frame"            = number,
       "metalUsed"        = number,
       "metalProduced"    = number,
       "metalExcess"      = number,
       "metalReceived"    = number,
       "metalSent"        = number,
       "energyUsed"       = number,
       "energyProduced"   = number,
       "energyExcess"     = number,
       "energyReceived"   = number,
       "energySent"       = number,
       "damageDealt"      = number,
       "damageReceived"   = number,
       "unitsProduced"    = number,
       "unitsDied"        = number,
       "unitsReceived"    = number,
       "unitsSent"        = number,
       "unitsCaptured"    = number,
       "unitsOutCaptured" = number,
       "unitsKilled"      = number
     }, ...
  }

In short, the data you need appears to be already tracked and provided to synced gadgets on demand. There's no need to track it yourself unless you have custom resources or other Lua-based stats to track.

[Jools]

In short, the data you need appears to be already tracked and provided to synced gadgets on demand. There's no need to track it yourself unless you have custom resources or other Lua-based stats to track.

That data is not good. For example, it counts built dragon's teeth as units lost, and also incomplete units killed as confirmed kills (imagine how that affects your kill count if you have a brawler shooting a factory with a huge queue).

We do need our own data, but fortunately it's not that hard to get. There are already several widgets/gadgets that gather that.

That data is also incomplete. For instance:

"damageDealt" = number,

Damage dealt is just a plain number, whereas it could be a matrix that contains damage dealt/received vis-à-vis each player.

[Funkencool]

True but it is something to build off of, first comes the basic lua graph (with old data format). Then comes all the cool new gadgets to fill it with useful and interesting information

[SpliFF]

That data is not good...

I would have thought it is exactly the same data used by the engine endgraph. Are you positive the Lua results are different from the engine stats?

For example, it counts built dragon's teeth as units lost, and also incomplete units killed as confirmed kills (imagine how that affects your kill count if you have a brawler shooting a factory with a huge queue).

a.) Why would the engine know dragons teeth aren't "real" units?
b.) How likely is that brawler scenario? It sounds entirely contrived. If you need an example that bad to make a point then you don't have one.

Nothing you've said convinces me the data is "bad" or at least any worse than that already being shown. I still don't see any benefit from the extra overhead and complexity of compiling these stats yourself.

Damage dealt is just a plain number, whereas it could be a matrix that contains damage dealt/received vis-à-vis each player.

And how would you represent all that PvP data visually? It seems like something that would be very difficult to display for a 20 player game since you'd have to display approximately 20!/(2!(20−2)!) combinations of dealt/received data, which is about 190 pieces of unique data.

[Jools]

I would have thought it is exactly the same data used by the engine endgraph. Are you positive the Lua results are different from the engine stats?

It is the same data.

a.) Why would the engine know dragons teeth aren't "real" units?
b.) How likely is that brawler scenario? It sounds entirely contrived. If you need an example that bad to make a point then you don't have one.

a) It's not really relevant to discuss why the engine doesn't know that DT:s aren't real units, the point is that it doesn't. Humans, on the other hand, do know this.

b) The brawler scenario is just one example to illustrate the problem. I can't say how likely it is in general, for me it happens occasionally (more often in those game where someone goes air)

And how would you represent all that PvP data visually? It seems like something that would be very difficult to display for a 20 player game.

That's a relevant question. I can think of some ways*, each of which have their faults. I'm just saying that this is what people want to see. I'm sure you can think of as better way than me.

*For one example, although imperfect, have a look at my ecostats widget: http://springfiles.com/spring/lua-scripts/eco-stats

[Jools]

About how to show the data, it doesn't have to be 20!/(2!(20−2)!) combinations for a 20 player game. People and computers don't read data in the same way. I was thinking of something more visual.

In my widget I give every player a colour and for each player draw bars that only show the damage they have dealt per enemy. I'm not sure if you really need a received damage bar as well, most of the times that should correspond to the dealt damage bar of the other player. I know it may not correspond 100%, but I suspect the difference is small.

[Funkencool]

This might need a different thread but what would people like to see in an end game graph?
Just spitballing, maybe:
average cost in Metal of units,
or even average damage dealt/average cost per unit (making cost)?
would also be nice to have highlights of certain points of game, battles etc..

I agree about the pvp. That could be dealt with on the user end. In a 10 v 10 I would only be able to personally PvP with 10 people (on other team) or 20 data points recieved dealt. And it would be neat in ZK, for example, they could make a nemesis award. For that matter I wonder if they could use their award widget to write to an array..

edit:

I'm not sure if you really need a received damage bar as well, most of the times that should correspond to the dealt damage bar of the other player. I know it may not correspond 100%, but I suspect the difference is small.

Except probably in FFA's, where received might be cool too see.

[Jools]

Yes, but wouldn't that be available by looking at the opponent's bar?

I mean, if damage dealt by player B to player A is x, then wouldn't the damage player A has received also be x?

Except from the damage that is the result of:
- the number of DT:s player A has built
- maybe indirect damage is not attributed to any player.

[malric]

This might need a different thread but what would people like to see in an end game graph?

Besides all the normal ideas, I think people would like to see if they were better at (at least) something. This might be good for the team that lost not to feel that bad (we want more players playing the game ).

What I personally would like to see easy is when the opponent got "in front" (resource wise, unit wise, land covered, land scouted). Scouting for example is very hard to assess from the graphs (assuming metal is close enough).

[Funkencool]

I mean, if damage dealt by player B to player A is x, then wouldn't the damage player A has received also be x?

I suppose that would be mostly true in mobile v mobile conflicts, but in my mind I imagine a fleet of player A's Gunships being lost to player B
A = 0, B = butload or maybe in an FFA while A's mobile units were attacking B player C overtakes A's base, therefore dealing but not recieving damage. Or perhaps player A like's to scout a lot and deals a lot of damage to mex/cons but player B does not. Or Player A is better at micro and weasels his units out of any damage in a conflict, etc.. etc..

I think all that would be interesting statistics to see.

edit: Gotchyea, I was looking at it backwards. Still it all has to be stored locally so, I still think should be Damage recieved by player B and Damage dealt to player B

Besides all the normal ideas, I think people would like to see if they were better at (at least) something. This might be good for the team that lost not to feel that bad (we want more players playing the game ).

What I personally would like to see easy is when the opponent got "in front" (resource wise, unit wise, land covered, land scouted). Scouting for example is very hard to assess from the graphs (assuming metal is close enough).

My thoughts also that, or at least a little entertaining data that doesn't necessarily point out all of your faults. But it should have data that can beneficial to improvement as well.

[Forboding Angel]

apm
metal spent
energy spent
metal produced
energy produced
units built
units lost
resources lost from units dying
resources I cost my opponent from killing his shit
Build order of each player (all units built all game and at what time (gametime) they were built)

More but I can't think of everything yet.

[knorke]

Maybe some of the obvious bugs are fixable without too much hassle:
-faster game/replay speed resulting in more apm
-like graphs going outside the scales (partly mod problem i think)
-better scale numbering, for example vertical scale rounded to integers

None of this discussion is new, talking about details like what stats to show in a widget is useless as at this point nobody is working on such widget.

[Funkencool]

just as a making a widget is useless if you don't know what your making.. how do you know there's not someone non-vocal reading this and decides to put it into action..