[Mutator] Even Match (Onslaught team balancer)

[Wormbo]

Fro those who don't know it, Even Match is a mutator originally requested by laboRHEinz specifically for CEONSS. I revived the project for the Omnip)o(tents server after it slowly came to a halt here at version 2 alpha 6 quite a while ago.
The current release is version 2 beta 1 with the following new features:

• beta 2
  • The SHA1 hash used for storing PPH data will now be explicitly sent by the client when stats logging is disabled. If the client did not configure stats credentials, a random hash will be generated clientsidely. This random hash will be stored on the client and sent every time instead of an actual hash until the client configures a stats username and password.
  • A potential fix for players voice chatting to the wrong team after a switch is included, although I could not really test it.
  • Another potential fix, namely for players being able to undo a forced team switch, is included in this release as well. It can be configured with the new UndoSwitchCheckTime option.
  • The selection of balancing candidate players was modified. Now players from the bottom of the scoreboard should be preferred.
  • The RecentBalancingPlayerTime option was not available via webadmin. It is now.
• beta 1
  • PPH storing now uses the SHA1 hash of players' stats identifiers, which is essentially based on the player's CD key, stats name and stats password
  • the inactivity time after which a player's PPH record is removed can now be configured and defaults to 30 (instead of just 2) days
  • PPH storing no longer relies on the EvenMatch package name; in other words, starting with this release, stats will survive version changes
  • players who join the winning team, either from spectator mode or from the team that is currently behind, are now reliably switched (back) to the other team that needs them more
  • some fixes related to Accessed None and Array out-of-bounds errors
  • some improved config option descriptions and in-game messages
• alpha 9
  • PPH is now accumulated over more than one match. All older PPH values together and the current match PPH each contribute 50% to the value that is used to rate players during shuffling. This 50%/50% contribution is persisted at the end of the match, which causes older match PPH to be faded out gradually.
  • The team shuffling algorithm was completely rewritten from a very time-consuming optimal solution to a relatively simple approximation that still gives very good results. This should prevent even the slightest chance of "runaway loop" crashes during shuffling.
  • Fixed soft balance delay not being applied. Now when an imbalance between teams is detected, Even Match correctly waits for the soft balance delay to pass before doing anything. If automatic balancing is disabled an manual balancing is requested and necessary, the soft balance delay is not applied.
  • Exported sources should now be compilable without any error regarding a missing ProgressArrowRotator resource.
  • All user-visible messages should now be localizable.
• alpha 8
  • renamed config options to hopefully make them easier to understand:
    • MinDesiredRoundDuration -> MinDesiredFirstRoundDuration "Minimum desired first round length (minutes)"
      If the first round is shorter than this number of minutes, scores are reset and the round is restarted with shuffled teams.
    • bShuffleTeamsFromPreviousMatch-> bShuffleTeamsAtMatchStart "Shuffle teams at match start"
      Initially assign players to teams based on PPH from the previous match to achieve even teams.
    • bConnectingPlayersBalanceTeams-> bAssignConnectingPlayerTeam "Assign connecting player's team"
      Override the team preference of a connecting player to balance team sizes.
    • bAlwaysIgnoreTeamPreference-> bIgnoreConnectingPlayerTeamPreference "Ignore connecting player team preference"
      Ignore player preferences for a team color, allowing the game or Even Match to pick a team.
  • new config options:
    • bBalanceTeamsBetweenRounds - Whether to always apply balancing between rounds.
      This isn't total shuffling, but just moves the bottom players of the bigger team to the smaller team until player counts are balanced. If player count is odd, the behind team gets the remaining player.
    • bBalanceTeamsWhilePlaying - Whether to auto-balance during the match if teams get uneven. (Turn off if you only want balance on player request.)
    • bBalanceTeamsDuringOvertime - Whether balancing (auto or requested) should happen during overtime. (disabled by default)
    • bDisplayRoundProgressIndicator - Whether the team progress HUD indicator should be displayed.
      That indicator off by default now. If Even Match assesses the game state correctly, that indicator will not provide any useful information for players. As mentioned before, I will probably remove it for the final version.
    • TeamsCallString - The chat message text players can use to call for team balancing instead of the "mutate teams" console command. (not set by default)
      While a round is ongoing, players and admin spectators can call for a team balance check. Non-admin spectators are excluded to prevent abuse. Even Match will do a quick check to see if the call is allowed and seems justified. If so, regular soft balancing will start as configured and will be followed by forced balancing if necessary.
  • Added Linux emitter crash fix. (This will only be applied on dedicated non-Windows servers.)
  • Added some more debug logging. (Enabled by default for now.)
  • Fixed an array index out of bounds error, which also partially broke soft-balancing.
  • Excluded bots from top-scorer ranking.
  • Added more "key player" criteria:
    • Double damage with >5s left
    • Super weapon with ammo in inventory
    • Using Linkgun to heal things
  • Added "criteria downgrades" for repeatedly unsuccessful forced balancing attempts. The "key player" criteria are turned off in the following order: nearby node check, UDamage, super weapon, linkgun, vehicle passengers, important vehicle, valuable player.
  • Improved team shuffling algorithm's computational complexity to reduce the risk of runaway loop crashes with many players and known PPH records.
• alpha 7
  • Initial "you are on ..." message is no longer dropped because of "Play!" announcement.
  • Bots are ignored from any mid-game balancing by default.
  • Balancing can be disabled for small player counts.
  • There is a HUD indicator now that displays Even Match's assessment of which teamn is how far in the lead. This is mainly for debugging the alpha version and I'll probably make it configurable and disabled by default for the final release. Please send me a screenshot with a short description if you think the indicator shows something blatantly wrong in a certain situation.
  • Rewrote the team progress assessment code. The previous code seemed to make sense when I wrote it, but it turned out to be way, way off in relatively common situations.
    The new logic considers core health and the enemy's distance fro mthe core, node numbers and health and the own distance to the enemy core, as well as whether cores are vulnerable or the game is in overtime.
  • Interaction between the "Connecting players balance teams" and "Always ignore team preference" options was changed:
    "Connecting players balance teams" now doesn't simply disable a connecting player's team preference, but actively sets a team number. In combination with "Always ignore team preference" this also happens if no active rebalancing is strictly required.
  • Fixed forced team switching not killing live players, which caused weird effects. For example if you were in a vehicle and switched from red to blue, you'd still drive a red vehicle that could even contain other red team members. Force-switched players now respawn properly and their death message reflects the reason.
  • Fixed the "switch to winning team" protection sometimes kicking in for force-switched players. (Pointless, as they didn't chose to switch themselves.)
  • Extended the "important player" check to exclude drivers of vehicles with passengers from forced switching.
• alpha 6
  • Tweaked short round results message after end of match to say "first round", not "previous round".
  • Excluded configurable percentage of top-scorers from mid-game balancing.
  • Excluded players from mid-game balancing that are currently contributing to their team's progress, e.g. by driving a key vehicle or healing or attacking a node.
  • Allowed the size difference to become larger if the smaller team is further in front.
• alpha 5
  • Changed PPH cache to use Unix timestamp.
  • Added a message sent to a force-switched player to notify about the switch.
• alpha 4
  • Fixed random initial side switch. (Power node list was not fully initialized at that point yet.)
  • Small fixes to recent balancing player detection.
• alpha 3
  • Fixed players spawning in old team colors for new team after a switch.
  • Added logic to prevent the same player from being switched back and forth again and again.
  • Added logic to prevent players from switching to the larger/winning team.
  • Player PPH from previous match is remembered based on the entire IP address now.

Download
Readme

[Pegasus]

Hey there n' good to see you back again, as well as affording the CEONSS community the opportunity to offer some input on your recent UT work, Wormbo!

Regarding EvenMatch's development now, here's a few thoughts on both the latest version, as well as some additional suggestions I've had in mind about it for awhile, that might help improve the ingame experience on all servers trying it out:

First off,

[...]There is a HUD indicator now that displays Even Match's assessment of which teamn is how far in the lead. This is mainly for debugging the alpha version and I'll probably make it configurable and disabled by default for the final release. Please send me a screenshot with a short description if you think the indicator shows something blatantly wrong in a certain situation.[...]

While the developer-minded motivation might be obvious here regarding the idea of letting players monitor in realtime the association between this metric and matches' progress though a HUD indicator (especially during a beta testing stage), one should also be mindful of the potential, let's say, bias-affirming influence such a tool might have on some players' state of mind, which, in turn, could exacerbate their sense of imbalance, say, just as they're dieing alone defending a node, simply by seeing the figure tipped one way or another slightly past the 50% mark. What I'm saying here is, there's a theoretical chance this feature could needlessly contribute to an increase in ingame acrimony among already short-tempered people with a history of knee-jerk imbalance assessments, and even spreading this additional frustration across the rest of the playing crowd, thereby hampering ingame experience.
Just so I'm not misunderstood here, I'm not suggesting this isn't an informative measurement to have for everyone participating in EvenMatch's development, rather that it might be a more prudent approach for now, at least ingame community management-wise, to consider placing a few more steps in getting it enabled (such as having it disabled by default and requiring a client-side manual .ini file alteration for that to change, or just having it server-side toggleable), or even temporarily limiting access to it to, say, just ingame admins until it gets dialed in a bit more. Limiting the availability of the HUD indicator could reduce the number of feedback from ingame observers in a proportional manner as a direct consequence of course, so it wouldn't be a cost-free decision, but potential impact from introducing this element in online play could IMO be significant enough to merit some consideration at this stage.

[...]Extended the "important player" check to exclude drivers of vehicles with passengers from forced switching.
[...]
Excluded players from mid-game balancing that are currently contributing to their team's progress, e.g. by driving a key vehicle or healing or attacking a node.[...]

Hmm. It might likely not even be the full list you're sharing here, but there's several other kinds of circumstances in which players might be involved that could reasonably merit them being labeled "key" and/or not suitable for swapping I could think of: them being in a single-seat vehicle (like the Paladin), but directly contributing to a vital node's defense; attacking/defending a core; being a gunner/linker to a high-value vehicle embroiled in a mid-map fight; carrying a rare/valuable pickup; being in possession of a stolen important vehicle; being in a >5 spree/kill streak, etc.. In the interest of making sure nothing obvious, but gameplay-significant, got left out, might you be able to make the full list of "key" player exemptions available to us for a quick go-over? TiA.

[...]Player PPH from previous match is remembered based on the entire IP address now.[...]

Probably just scratching an idle curiosity itch with this, but is a player's IP the sole determinant of their identity for EvenMatch or does any other kinda personally identifying data play a role to that as well (say, their GUID)?

To close with a couple of suggestions now, for one thing, you repeatedly bring up a mid-game balancing cycle, which, along with past personal experience, suggests that EvenMatch's interference with teams' composition is far less frequent than that of other similar solutions - one obvious reason for that being server resource conservation. Given that other ONS[Plus] communities have for years now been accustomed to the "instant satisfaction" factor of saying or inputting a specific console command and seeing a rebalance check happen in the next second (for the Omnis, that's been simply text chatting "teams"; for the DW ONS server, it's been the console command "mutate teambalance"), would EvenMatch now aim to accommodate such expectations through a similar text/command event watch (perhaps offering it as a server-configured toggleable feature), or will it just be sticking to its established 2 cycles per match (one pre-, one mid-) behaviour? Can't help but admit I've sometimes found the "teams" cries getting immediately answered to be a pretty nice feature that CEONSS has been missing myself .

Secondly, perhaps it's not a widely known fact, but EvenMatch's short round restarts have been linked to server crashes when its code would interact with some mapper-placed emitter's properties on certain operating system environments. While counteracting that has been feasible, the practical way to do so has involved stripping maps of (sometimes cool looking) emitters, and it's also been a solution that does not scale with size, meaning it has had to be done (or proof-tested) by hand for every map. None of that is Wormbo's fault, of course, as the same kind of crashes would still naturally occur in an EvenMatch-free, multi-round match context on the same kind of susceptible servers, but the introduction of EvenMatch into the equation IMO does present an opportunity to deal with this minor issue, even though it wouldn't fall directly within its mission statement, and only because the solution is such a small deviation in size from the rest of the mod's body of code.
Essentially, what I'm proposing here is for EvenMatch's next version to attempt to embed an already existing one-class, two-function, standalone fix for this problem that was offered here over four years ago and has had its code reuploaded last year. If Wormbo's okay with this and it works, it could save the staff's content maintaining efforts a good chuck o' time, as well as bypassing the whitelist problem of running that mutator on its own.,If it doesn't, well, no real cost incurred, right?


Anyway, that's all I could think of for now - hope some of it helps with the mutator's development. Oh, and welcome back again, mr. Coding Dude .

[Wormbo]

While the developer-minded motivation might be obvious here regarding the idea of letting players monitor in realtime the association between this metric and matches' progress though a HUD indicator (especially during a beta testing stage), one should also be mindful of the potential, let's say, bias-affirming influence such a tool might have on some players' state of mind, which, in turn, could exacerbate their sense of imbalance, say, just as they're dieing alone defending a node, simply by seeing the figure tipped one way or another slightly past the 50% mark. What I'm saying here is, there's a theoretical chance this feature could needlessly contribute to an increase in ingame acrimony among already short-tempered people with a history of knee-jerk imbalance assessments, and even spreading this additional frustration across the rest of the playing crowd, thereby hampering ingame experience.
Just so I'm not misunderstood here, I'm not suggesting this isn't an informative measurement to have for everyone participating in EvenMatch's development, rather that it might be a more prudent approach for now, at least ingame community management-wise, to consider placing a few more steps in getting it enabled (such as having it disabled by default and requiring a client-side manual .ini file alteration for that to change, or just having it server-side toggleable), or even temporarily limiting access to it to, say, just ingame admins until it gets dialed in a bit more. Limiting the availability of the HUD indicator could reduce the number of feedback from ingame observers in a proportional manner as a direct consequence of course, so it wouldn't be a cost-free decision, but potential impact from introducing this element in online play could IMO be significant enough to merit some consideration at this stage.

I didn't see it that way before. The indicator really only was supposed to be a tool to evaluate the old (after it seemed fishy in the log output) and new team progress calculations. Keep in mind that this isn't meant to be a balance indicator, but a progress indicator. The balance in a game can only be created approximately. It will never be perfect, so at some point the game must tip over to one side or the other. A match to the very end with overtime ending 0% vs 1% in terms of core health would be rare, even in the most balanced setup you could imagine.

The indicator is always-on for this particular alpha build exclusively to compare the mutator's sense of the game to what a human intuitively sees. The progress doesn't really take much influence from things that aren't immediately obvious from the HUD and radar map. The things you can't (usually) see on the radar (i.e. node health) doesn't have much influence on the calculation anyway and I might even eliminate it again.
Considering the limited new information the indicator gives, and taking your concerns about its misuse into account, I will probably remove it before a final release or at least turn it off by default.

Hmm. It might likely not even be the full list you're sharing here, but there's several other kinds of circumstances in which players might be involved that could reasonably merit them being labeled "key" and/or not suitable for swapping I could think of: them being in a single-seat vehicle (like the Paladin), but directly contributing to a vital node's defense; attacking/defending a core; being a gunner/linker to a high-value vehicle embroiled in a mid-map fight; carrying a rare/valuable pickup; being in possession of a stolen important vehicle; being in a >5 spree/kill streak, etc.. In the interest of making sure nothing obvious, but gameplay-significant, got left out, might you be able to make the full list of "key" player exemptions available to us for a quick go-over? TiA.

There are many factors that determine whether a player is considered a candidate for balancing teams during a round:

• First candidates always are those who didn't pick a team yet. Players who have just connected or are joining from spectator state can get assigned a team up to the point when they actually spawn.
• Players who were team-switched less than a minute ago are preferably not picked to be switched that soon again.
• Dead players may be team-switched during soft-balancing unless they are deemed "valuable" to the team. Here "valuable" means "among the top x% scorers on the team", which is configurable and excludes bots by default.
• When forced balancing kicks in, "key players" (and I just realized I'm no longer checking valuable players here) are excluded.
  To determine whether a player is a key player, the following things are checked:
  1. Is the player dead? -> not a key player
  2. Does the player drive an "important" vehicle (tanks and hover tanks [except Firebug], Paladins [probably including Aegis, etc.], Leviathans [includes Kraken, Perses, etc.], Badgertaur [at least my version]) or one that has occupied passenger seats? -> key player
  3. Player damaged a node within the last second? -> key player
  4. Player healed a node within the last half second? -> key player
  5. Find the closest relevant node or core (within 2000UU) for the player. A node is considered relevant if: (let's see, how deep these lists can nest... )
     • Not disabled (i.e. must be part of the link setup),
     • Owned or attackable by the player's team, and
     • Attackable by the enemy team or under construction.
     If such node/core exists, is it under attack or owned by the enemy? -> key player
  6. Not a key player.

As mentioned before, that check should probably also exclude the "valuable" players of a team.

Probably just scratching an idle curiosity itch with this, but is a player's IP the sole determinant of their identity for EvenMatch or does any other kinda personally identifying data play a role to that as well (say, their GUID)?

Players are identified by their full IP and the first eight chracters of their GUID. PPH information consists of that identification, a Unix timestamp of when it was saved and the PPH value as floating point value "score/play time". Data is kept for about two days, i.e. 48 hours, and currently stored in the main configuration file. (I should probably make that configurable either as server commandline parameter or mutator config option.)

To close with a couple of suggestions now, for one thing, you repeatedly bring up a mid-game balancing cycle, which, along with past personal experience, suggests that EvenMatch's interference with teams' composition is far less frequent than that of other similar solutions - one obvious reason for that being server resource conservation. Given that other ONS[Plus] communities have for years now been accustomed to the "instant satisfaction" factor of saying or inputting a specific console command and seeing a rebalance check happen in the next second (for the Omnis, that's been simply text chatting "teams"; for the DW ONS server, it's been the console command "mutate teambalance"), would EvenMatch now aim to accommodate such expectations through a similar text/command event watch (perhaps offering it as a server-configured toggleable feature), or will it just be sticking to its established 2 cycles per match (one pre-, one mid-) behaviour? Can't help but admit I've sometimes found the "teams" cries getting immediately answered to be a pretty nice feature that CEONSS has been missing myself .

IIRC CEONSS only uses the team randomization that happens at match start or after a short round. The mid-game balancing features are disabled here, probably because they were found to be too intrusive. I'd blame that on the insufficient progress calculation that was used before today's release. Even Match attempts to make a "teams" call redundant by evaluating the team balance on its own - if you allow it to do so.
One of the features in today's release is explicit balancing by connecting players, using the mutator's global progress and team size evaluation. That's because the game's own decision considers bots as players and prefers red without regard to the game state.

However, I could imagine a scenario where the automated balance checks are configured to be less strict to only catch very obvious imbalances (e.g. 5-2 players, optionally filled up with bots) and leave it to players to call "teams" before it gets that bad. I think an important feature of Even Match is that it can ignore bots. It probably doesn't ignore them everywhere yet (I'll have to verify that. Keep in mind, I picked it up after a break of almost exactly four years.), but still it's a feature that seems to be neglected in other team balancers. (I did read a few complaints about that at the Omni forums.)

Secondly, perhaps it's not a widely known fact, but EvenMatch's short round restarts have been linked to server crashes when its code would interact with some mapper-placed emitter's properties on certain operating system environments. While counteracting that has been feasible, the practical way to do so has involved stripping maps of (sometimes cool looking) emitters, and it's also been a solution that does not scale with size, meaning it has had to be done (or proof-tested) by hand for every map. None of that is Wormbo's fault, of course, as the same kind of crashes would still naturally occur in an EvenMatch-free, multi-round match context on the same kind of susceptible servers, but the introduction of EvenMatch into the equation IMO does present an opportunity to deal with this minor issue, even though it wouldn't fall directly within its mission statement, and only because the solution is such a small deviation in size from the rest of the mod's body of code.
Essentially, what I'm proposing here is for EvenMatch's next version to attempt to embed an already existing one-class, two-function, standalone fix for this problem that was offered here over four years ago and has had its code reuploaded last year. If Wormbo's okay with this and it works, it could save the staff's content maintaining efforts a good chuck o' time, as well as bypassing the whitelist problem of running that mutator on its own.,If it doesn't, well, no real cost incurred, right?

I see. IIRC last time I wanted to look at that file, it was unavailable, so good to know it's back. That's indeed a really simple fix and technically it would affect Emitters, xEmitters and AmbientSounds, though only the (x?)Emitters really seem to cause problems with garbage collection. There's no problem including that fix in Even Match, and in fact, there's no problem if multiple mods attempt to apply that fix, as it really only disables a certain property of those actors that prevents them from being deleted on dedicated servers. Since UT2004 "knows" the OS it runs on (actually, the OS it was compiled for), I could even disable the fix on Windows systems.

BTW: The crash fix really should have been a server actor. It doesn't use any mutator features, it only derives from the Mutator class. Also, there's no point turning it on or off or cluttering the mutator list with it. It should have been a basic, always-on fix to specify in UT2004.ini. Unfortunately, it isn't.

[Cat1981England]

Thanks for your work Wormbo. Just for the record, we're currently using EvenMatchV2a5

I've tried it on the testing server and everything seems to be working well. I'll put it on the main server tonight or tomorrow morning with TitanTeamFix disabled and the following settings,

[EvenMatchV2a7.mutTeamBalance]
ActivationDelay=10
MinDesiredRoundDuration=5
bShuffleTeamsFromPreviousMatch=True
bRandomlyStartWithSidesSwapped=False
bConnectingPlayersBalanceTeams=False
bAlwaysIgnoreTeamPreference=True
bAnnounceTeamChange=True
bIgnoreBotsForTeamSize=True
SmallTeamProgressThreshold=0.500000
SoftRebalanceDelay=10
ForcedRebalanceDelay=30
SwitchToWinnerProgressLimit=0.700000
ValuablePlayerRankingPct=75
MinPlayerCount=2
bDebug=False

-----

Would it be possible for the PPH information to be stored in a separate file or does it have to be in ut2004.ini?

Also, maybe once a month the server crashes with the following error. Is this something that could possibly be fix?

EvenMatchRules: Shuffling teams from previous match...
Critical: EvenMatchRules ONS-SilvaBETA5.EvenMatchRules (Function EvenMatchV2a5.EvenMatchRules.GetPointsPerHour:00C5) Runaway loop detected (over 10000000 iterations)

Thanks again

[Wormbo]

Currently PPH cannot be moved anywhere else, but it's on my TODO list.
About that crash, I'll have to look into optimizing access to the data during shuffling. There seems to be quite a lot of redundant extra work, especially with lots of known players.

[Cat1981England]

Thank you^

-----

This error is showing up in the server.log on every map,

Error: mutTeamBalance ONS-UP-OperaHouse-GL-SP1.mutTeamBalance (Function EvenMatchV2a7.mutTeamBalance.CheckBalance:0466) Accessed array 'Candidates' out of bounds (19/0)

I'll enable debug mode tonight.

[Wormbo]

Hmm, any other errors? I found a place that may be responsible for it (looks like a copy/paste error), but that one should have been generating more errors, then.

[Butze]

Fehler? ein bissl. balancer schiebt mich in blaues team. ich spielte und nach ca 10-15 schiebt er mich wieder ins rote team (gewinner team) das ist bestimmt nicht so gewollt.
Kann man nicht für kurze zeit ein bot hinzufügen oder entfernen, damit ein spieler nicht aller 10 sekunden verschoben wird?

[Pegasus]

Thanks to the miracle of modern pharmaceuticals, I am now, and maybe for the next hour or so, able to take a short break from my 3-day, flu-inflicted stupor and form a few cogent thoughts that might even be relevant to this thread's efforts. Hooray!

- Okay, so after seeing the complete breakdown of the selection loop that picks balancing candidates while a match is underway, my only remaining recommendation here would be that maybe one additional criterion should be introduced between steps 2 and 3 that examines whether a player is in possession of a superweapon (through a check for possession of any InventoryGroup 0 gun, or via specific classname matches?) or a damage amp that's more than, say, 5 secs away from expiration.
- Seeing as this is now a cross-community development effort, I've been keeping an eye out for feedback from across the pond, too, and indications from there seem to reinforce a suspicion I had previously about the clarity of one specific and important configurable parameter's role, namely bConnectingPlayersBalanceTeams. It kinda comes across as ambiguous about what it actually does, so unless and until server admins consult relevant threads or documentation each time they're rechecking (or backing up) their EvenMatch configuration, I think you can expect people to be coming back and asking you for clarification on what exactly it does again n' again in the future. So, to prevent that, and considering how quick n' straightforward its true function is when one hears it from you, might I recommend its renaming to something a bit more clear, like, say, bTeamAssignmentByEvenMatch or bJoinersTeamAssignedByEvenMatch?
- It seems the new EvenMatch version has had some oddities/bugs crop up regarding people getting switched mid-match that should have been exempt as key players, causing some (premature) frustration and skepticism about the mutator. While bugs are to be expected of course, as this is still a project in alpha state, I was wondering whether the debug mode you mention includes outputting to the server log of the reasoning behind each balancing decision, and whether that could be useful as a diagnostic tool towards spotting where the code is going off-script. If that assumption is correct, would it be prudent to advise all server admins to keep that option enabled, despite any (presumably minor) performance impact, for the time being so as to boost generation of useful data and thereby expedite bug quashing? Only asking because my guess right now is that both servers are keeping debug modes disabled, and you're trying to address complaints pretty much in the dark.
- Lastly, when it comes to the Linux crash fix (which, I believe, is caused only by Epic's Emitter class map-placed instances), you explained why it might be a better approach to convert it from a mutator to a ServerActor. Could that still make it practical to include it in the EvenMatch package (which is a client-side mutator loaded within a game session), and have its ServerActor part referenced from the same package through the server's UT2004.ini, or am I misunderstanding something here? If both can work, LinuxFix ServerActor within a new EvenMatch version seems the way to go. Alternatively, would implementing this as a standalone ServerActor resource have any impact on the server's whitelist standing? I know the answer to that is somewhere in my head, but right now... ugh.


Anyway, that's all I got. Thanks for your ongoing efforts with this, W.

[Wormbo]

*takes notes* super weapon, amp

bConnectingPlayersBalanceTeams - hmm. I'll have a look at the name and description again.

Debug mode currently doesn't add much information to the reasoning behind team switching. I'll add that as well as enabling debug mode for the next alpha.

The thing about the Linux crash fix being better implemented as ServerActor was about its standalone version. When included in EvenMatch, there's no point separating it from the mutator's initialization, as that happens even sooner than a ServerActor's initialization.

Fehler? ein bissl. balancer schiebt mich in blaues team. ich spielte und nach ca 10-15 schiebt er mich wieder ins rote team (gewinner team) das ist bestimmt nicht so gewollt.
Kann man nicht für kurze zeit ein bot hinzufügen oder entfernen, damit ein spieler nicht aller 10 sekunden verschoben wird?

Ich weiß, das Balancing funktioniert noch nicht wie es soll. Zum Beispiel sollte auch nicht der Spieler mit den meisten Punkten das Team wechseln. Da gibt's einfach noch einiges an Arbeit. (Sorry für die Unannehmlichkeiten.)