Allow registering player-based formulas to stats match module

[chatasma]

This allows mapmakers to define player-based formulas as match statistics that can be shown in the match stats summary at the end of a match.

i.e. adding this to a Bridge map

<stats>
    <stat value="player_score" name="`6Goals" />
</stats>

(where value is a player-based formula)

Adds bridge goals as a stat that is appended at the end of the match stats summary

Creating as a draft pull request to receive feedback and/or thoughts!

[Pablete1234]

Generally speaking having this feature added would be good, however, it needs some changes to how its implemented.

I think using variables for this is the wrong approach, and you should instead be using a formula. Formulas allow any set of variables to be mixed-and-matched as the map author desires, for example they could make it value="player.health + player.food" and their final score would be however many hearts and food they were able to keep.
This change alone would remove some of the overhead of dealing with variables, as it simplifies it to an expression that you can call to get the value of at the end of the match.

Ontop of that i'm not sure of the stats -> additions -> stat structure in xml, maybe simplify to:

<stats>
  <stat name="Score" value="player.health"/>
</stats>

i'm guessing that the only reason to have additions is a potential future where removing builtin stats is an option, but if that's the case we could probably have them in an attribute like <stats remove="deaths"/> or something along the lines

[chatasma]

Generally speaking having this feature added would be good, however, it needs some changes to how its implemented.

I think using variables for this is the wrong approach, and you should instead be using a formula. Formulas allow any set of variables to be mixed-and-matched as the map author desires, for example they could make it value="player.health + player.food" and their final score would be however many hearts and food they were able to keep. This change alone would remove some of the overhead of dealing with variables, as it simplifies it to an expression that you can call to get the value of at the end of the match.

Ontop of that i'm not sure of the stats -> additions -> stat structure in xml, maybe simplify to:

<stats>
  <stat name="Score" value="player.health"/>
</stats>

i'm guessing that the only reason to have additions is a potential future where removing builtin stats is an option, but if that's the case we could probably have them in an attribute like <stats remove="deaths"/> or something along the lines

I agree with everything stated here generally, so:

• Change the stats to accept formulas instead of dummy variables
• Remove the additions element, we can designate adding/removing as a property anyway

[Pablete1234]

Overall looking pretty good, just a few minor touch-ups

One thing that still seems odd is:
AggStat will always pick the higher value for any player, having the initial value be anything other than 0 will probably not work well (eg: imagine you're tracking distance to the goal, winner is 0 distance, the max distance away is 300 blocks, you use default of 300; no player will be able to get better than that, and wont be shown).
You may need to either add the concept of positive/negative stats, or simply get rid of default, make it 0 like all the other stats (they only define it for the sake of specifying the type, ie: int or double) and just assume all stats are positive and count starting from 0

[chatasma]

Makes sense on the default value, I am going to remove the XML default and have it initialize to 0 since that seems sensible for most if not all use-cases

[Pablete1234]

LGTM, just needs some testing now :)

[chatasma]

I did some (very rudimentary) testing with a bridge map (i.e. the example mentioned in the PR) to see if goals were added which looked like they were. Any other test cases I should be evaluating here?

[zzufx]

I've retrofitted and tested this module on some of my maps and includes (teams and FFA) and it seemed to work nicely. Maybe a filter argument could be useful in the future, but I've managed to do the stuff I wanted just fine without it so far.

Could also be a good opportunity to stardardize the spelling on the original multi-word stats (I think shot could be lowercase here) I can't seem to find the match link stuff here so it might not even be part of PGM, it's been a while (regardless of that, the suggestion would still be to change the OCC one, "Longest Shot"

PGM/util/src/main/i18n/templates/match.properties

Line 57 in d20769c

match.stats.type.longest_bow_shot = Longest Shot: {0}

)

[Pablete1234]

Match link isn't pgm, in the case of occ it's handled by https://github.com/OvercastCommunity/Dewdrop/blob/main/src/main/java/tc/oc/occ/dewdrop/managers/MatchManager.java#L43

Seems a bit out of scope for this pr to change