[Mutator] Even Match (Onslaught team balancer)

Anything about UT2004 mapping, Uscripting & more
User avatar
Wormbo
Posts: 383
Joined: Sun 28. Aug 2011, 11:52
Description: Coding Dude

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Wormbo » Sat 5. Mar 2016, 07:26

The option for removing player stats really was only a way to discard long-term unused data. In earlier versions it was necessary because the search algorithm was crap and the identification process used ever-changing data. But not playxers are identified by a constant value derived from the same data as their global stats ID. Have a look at your EvenMatchPPH.ini - there's likely nothing wrong with a few hundred entries. The search algorithm performance decreases logarithmically with the number of entries, i.e. doubling the number of entries should have almost no impact.

I suppose I could add map-specific stats as well, but of course that won't change much until everyone plays the same map at least their second time. Plus it would likely make the stats INI file grow significantly.
But generally, the idea for that extension would be: If there are map-specific stats, combine those with the generic stats using a certain (potentially configurable) ratio. Otherwise stick with just the generic stats for that player. Generic and map-specific stats would be tracked independently and in parallel.
Then again, while I'm at it, I could also make the minimum requirements for a player's PPH to be stored configurable. Currently the condition is "score positive and player's match time over 30 seconds". It might be reasonable to increase that to e.g. ten points and one minute by default.

User avatar
Wormbo
Posts: 383
Joined: Sun 28. Aug 2011, 11:52
Description: Coding Dude

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Wormbo » Mon 3. Oct 2016, 06:16

Alright, I'm about to post an updated version of the balancer that also keeps track of how everyone did on each individual map to provide a better initial balance. (Assuming not too many players join late.)

I need translations for a few changes and additions, though:
  • DeathString="%o was forced to auto-switch teams."
  • descDeletePlayerPPHAfterDaysNotSeen="To keep PPH data from piling up indefinitely [s]and affecting performance[/s], delete PPH of players who have not been seen in this number of days."
  • lblPlayerGameSecondsBeforeStoringPPH="Player in-game seconds before storing PPH"
  • descPlayerGameSecondsBeforeStoringPPH="A player must have accummulated at least this number of seconds play time in the current match before his or her PPH will be considered meaningful enough to store in the database."
  • lblPlayerMinScoreBeforeStoringPPH="Player minimum score before storing PPH"
    descPlayerMinScoreBeforeStoringPPH="A player must have scored at least this many points in the current match before his or her PPH will be considered meaningful enough to store in the database."
DeathString just changed "switch" to "auto-switch" to make itr even more obvious it wasn't the player's choice. For descDeletePlayerPPHAfterDaysNotSeen, the performance concerns part was removed for the reasons I described in the previous post. I can try guessing what to remove from it for languages other German or English, but I'd rather not tempt my luck. (Blizzard did that with a particular group speech sounds in Diablo 2 and managed to mess up because they didn't consult anyone who even remotely knew the language. "Damit kann ich jetzt noch nichts anfangen." - "I can't use that yet." - became "Damit kann ich jetzt noch nichts." - "I can't that yet." They meant to edit the sound to say "Damit kann ich nichts anfangen." - "I can't use that.")

Anyway, upcoming changes, in case you're interested:
  • Map-specific PPH stats, in addition to the generic ones.
  • Configurable minimum requirements for storing a player's PPH. The default changed from 30 seconds in the game and positive score to one minute in the game and more than 10 points.
  • PPH is saved slightly more reliably.

User avatar
GLoups!
Posts: 289
Joined: Fri 3. Feb 2012, 17:57
Description: Just play for fun.
Location: Fr

Re: [Mutator] Even Match (Onslaught team balancer)

Postby GLoups! » Mon 3. Oct 2016, 16:32

Somes editings for EvenMatch.frt

User avatar
Wormbo
Posts: 383
Joined: Sun 28. Aug 2011, 11:52
Description: Coding Dude

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Wormbo » Mon 3. Oct 2016, 19:00

Thanks!

Now, do we have any Spanish, Italian or Russian players here who would like to help with those translations? (I suppose they need a similar level of translation fixing.)

User avatar
Miauz55555
Posts: 777
Joined: Sun 7. Jun 2015, 22:12
Location: Germany

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Miauz55555 » Mon 3. Oct 2016, 19:28

Maybe
Sedoy wrote:...

, Fors, Sern can help with the russian part?
Image

User avatar
Pegasus
Posts: 962
Joined: Wed 4. Nov 2009, 23:37
Description: ONSWordFactory
Location: Greece

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Pegasus » Mon 3. Oct 2016, 21:18

Wormbo wrote:Alright, I'm about to post an updated version of the balancer that also keeps track of how everyone did on each individual map to provide a better initial balance. (Assuming not too many players join late.)
[...]
Anyway, upcoming changes, in case you're interested:
[list][*]Map-specific PPH stats, in addition to the generic ones.
[...]

Setting aside the fact that pressure to produce this update can be traced back to a specific group, who lately seem to've found it prudent (?) to disguise their chronic aversion towards inter-round balancing by conflating the concept of "initial data accuracy refinement", a worthwhile pursuit in general, with that of "sufficient adjustment over time to account for balance drift" - and it bears noting those two are not interdependent, just as a matter of applied math (i.e. interpolation on data sets) - there is one concerning side-effect of this local impasse now being exported to the rest of the UT ONS community hitherto getting good use out of EvenMatch, whose likelihood concerned parties cannot sensibly afford to dismiss, namely a potentially explosive increase in required space to store PPH data entries due to this new scheme.
Considering the average ONS[Plus] server nowadays may be hosting as many as 70-80 maps on its roster, unless the updated mod also incorporates additional code for assessing the storage of PPH data through some kind of clustering/grouping mentality - say, with percentage or absolute-figure margins within which performance variations across different maps would not be deemed significant enough to warrant distinct, separate entries - isn't this change just by itself liable to inflate the size of server-residing EvenMatch data logs (plus associated CPU/disc performance overhead for reading, calculating and/or writing those) by a factor equal to the average number of maps (not matches, mind) played per month, for a total product of average monthly players by aforementioned average maps "seen" over said month? Compared to the current size that merely approximates the average monthly player population, wouldn't this be a worrisome and onerous burden to place on the shoulder of all EM-employing servers just for the sake of temporarily sidestepping more ideological problems?
In fairness and to be clear here, some of these issues are not for Wormbo to address, but seeing how the gears have been set in motion once again in terms of EM's development, some clarification on the issue of smart(er) data handling n' possible compression/uncluttering methods (MPEG4 video encoders' delta frames come to mind as another example) in this planned new version would certainly be appreciated here.

As always, thanks in advance, both for any forthcoming analysis, as well as for your ongoing support of EvenMatch in general, Wormbo.
Image

User avatar
Wormbo
Posts: 383
Joined: Sun 28. Aug 2011, 11:52
Description: Coding Dude

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Wormbo » Tue 4. Oct 2016, 03:52

We can obviously go the UTAN Ban Manager route of storing the data in binary form. That would, however, prevent easy access to it, as it's no longer human-readable.

While we're on the topic: How big is the actual PPH database for CEONSS?

User avatar
Pegasus
Posts: 962
Joined: Wed 4. Nov 2009, 23:37
Description: ONSWordFactory
Location: Greece

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Pegasus » Tue 4. Oct 2016, 05:38

As far as the size of CEONSS' PPH database is concerned, that's something only Cat can offer tangible figures on. Still, if the size of every entry is (approximately) the same, couldn't a conservative estimate be made by just assuming, say, a number of 150ish players seen per month, multiplied by the size of the average entry? Factoring in the requisite header (and footer) log parts, how big would something like that be? A dozen KBs or so?

As for efficient ways to store EM-tracked data, what I was proposing was more a semantic-level approach, whereby prospective entries for already tracked players in "new" maps could be assessed for being relevant or useless, even if they would meet all other admissibility criteria for recording mentioned in your list (playtime, score and so on), based on PPH point distance from extant EvenMatch record(s) for them, rather than always creating a new record for a non-present {PlayerID, Map} pair and handling the bulk size through raw data compression methods on a binary/hex level.
After all, beyond just raising the issue of quick human perusal via text editor if the data wouldn't be in plaintext anymore, the raw data compression approach could also impose a not insignificant server-side processing (and memory) cost at the end and beginning of each match because EM would need to decompress the entire log to either add relevant entries at the end of a match (and then recompress) or just draw as many as 32 entries at the start of a new match based on the participating players' presence in the data. Considering the total amount of entries could be in the thousands (for, say, 200 tracked monthly players and 70 maps, this could be as many as 14,000, even though a more typical case could see that figure being less than a third of that maximum, for a still considerable 4,666 entries), I gotta wonder whether there even exists any data structure that UT can employ within its Uscript "sandbox" that could elegantly handle such a size (of structs no less, not just single variables), or what that [de]compressing and writing process might feel like match after match after match. Assuming I'm not missing something obvious here, such as, say, that EM's database might remain uncompressed for longer periods of time than just the span of any one match, or anything like that, I'm focusing on this again because the longer I've thought about it, the more complex and sticky it appears to get.

With no intention to offend here, I hope it's starting to come across why this whole EM "update" proposition could be the source of some warranted concern, or even skepticism, once someone starts looking closer into what exactly it might entail, operationally speaking.
Image

User avatar
Wormbo
Posts: 383
Joined: Sun 28. Aug 2011, 11:52
Description: Coding Dude

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Wormbo » Tue 4. Oct 2016, 17:15

Data compression is slow in UnrealScript, same for text processing, therefore I'd prefer relying either on the built-in configuration file features or the data package features. The raw INI-based entry currently takes up around 110 bytes on average, and depending on how an entry would be stored in a data package, it would probably take up around 40 to 60 bytes. Keep in mind that map-specific lists only ever include players EvenMatch saw playing that map for long enough and with high enough score. As a result they will pretty much always be a lot smaller than the overall list.

UnrealScript itself can handle the data amount just fine. It only keeps the total list and the current map's list in memory, so all the other maps don't matter at all. Each list is a simple dynamic array of structs, sorted by the players' "EvenMatch ID" string, which allows efficient O(log N) lookup and approximately O(1) insert. (I know, it's really O(N), but the constant overhead of inserting outweighs the linear part by so much, it won't really matter.)

User avatar
Cat1981England
Administrator
Posts: 2232
Joined: Mon 23. Aug 2010, 15:35

Re: [Mutator] Even Match (Onslaught team balancer)

Postby Cat1981England » Tue 4. Oct 2016, 19:19

Thanks for your continued work :thumbup:

Wormbo wrote:While we're on the topic: How big is the actual PPH database for CEONSS?

Pegasus wrote:As far as the size of CEONSS' PPH database is concerned, that's something only Cat can offer tangible figures on. Still, if the size of every entry is (approximately) the same, couldn't a conservative estimate be made by just assuming, say, a number of 150ish players seen per month, multiplied by the size of the average entry? Factoring in the requisite header (and footer) log parts, how big would something like that be? A dozen KBs or so?


The size of the EvenMatchPPH.ini is 105KB's with 1007 ID's. Delete Player PPH is set to 31 days.

As a comparison, yesterday there were 145 different people on and 42 maps played, the server.log was 650KB, AntiTTC logs 341KB, Chat logs 54KB, Player join logs 86KB

----------

I have to ask though, at what point are we going to consider matches balanced? Are we looking for an average match time or until people stop complaining?

Also, would player win/lose rate be a better alternative then PPH?
The Universal Declaration of Human Rights, Article 1:

All human beings are born free and equal in dignity and rights. They are endowed with reason and conscience and should act towards one another in a spirit of brotherhood.


Return to “The Creative Corner”



Who is online

Users browsing this forum: No registered users and 1 guest