MULTIbalancer [1.1.6.0] 30-MAR-2015 + BFHL

[ImportBot]

Originally Posted by PapaCharlie9*:

 

PapaCharlie9

 

With my settings would you recommend I change to ClanTagOnly and RoundScore?

 

I think I may have asked you before but I see you recommend RoundScore for conquest. I am just not sure what the advantages and disadvantages of that is.

 

RoundScore does seem like it would be better but I don't know how it handles new joins and people who crash during round change which seems to happen a lot and then they rejoin.

 

Sorry if I have asked you this before. I just want to try and keep the games as close as possible without messing to much with the players in game. BattelogSPM to me seems like that value is always there (well except when stats go offline). RoundScore seems to me that it only would work for players that do make it from round to round. Again though I know most of the problems we have are nothing to do with this plugin.

 

Let me know what ya think.

Thanks

It depends. How much do you believe that Battlelog stats reflect player strength at this point in BF4's launch cycle? I said in November that it was way too soon for stats to be accurate for the general player population. In January, maybe there's enough info now?

 

What matters is hours played. If the average player has 100+ hours (WAG - an accurate value would require analyzing the variance of stats versus hours played across the player population that visits your server), Battlelog SPM should be good for Conquest Large -- provided you tend to have average players rather than noobs or pros on your server. This is also assuming most of those 100 hours were playing Conquest Large. If they have 100 hours of TDM or Rush, how applicable is their SPM to Conquest?

 

Ideally, you would make the decision on whether to use IAR stats or Battlelog average stats based on the number of hours played by each player. Hmmm, maybe I could add that to MB? If you use any Battlelog stat, like BattlelogSPM, it would only apply the Battelog stat if the number of hours played is greater than some plugin setting, defaulted to 100 hours, otherwise it would use the IAR equivalent.

 

IAR stats, like RoundScore, have their own problems. If a good player has a bad early round or is working on an unlock or assignment, they might get categorized incorrectly. Likewise, if a noob gets lucky early or is riding on the coattails of a pro (gunner in a chopper or gunboat, for example), they might get categorized as strong. There's no perfect answer for individuals, its all about averages.

[ImportBot]

Originally Posted by DWG-Jambi*:

 

It depends. How much do you believe that Battlelog stats reflect player strength at this point in BF4's launch cycle? I said in November that it was way too soon for stats to be accurate for the general player population. In January, maybe there's enough info now?

 

What matters is hours played. If the average player has 100+ hours (WAG - an accurate value would require analyzing the variance of stats versus hours played across the player population that visits your server), Battlelog SPM should be good for Conquest Large -- provided you tend to have average players rather than noobs or pros on your server. This is also assuming most of those 100 hours were playing Conquest Large. If they have 100 hours of TDM or Rush, how applicable is their SPM to Conquest?

 

Ideally, you would make the decision on whether to use IAR stats or Battlelog average stats based on the number of hours played by each player. Hmmm, maybe I could add that to MB? If you use any Battlelog stat, like BattlelogSPM, it would only apply the Battelog stat if the number of hours played is greater than some plugin setting, defaulted to 100 hours, otherwise it would use the IAR equivalent.

 

IAR stats, like RoundScore, have their own problems. If a good player has a bad early round or is working on an unlock or assignment, they might get categorized incorrectly. Likewise, if a noob gets lucky early or is riding on the coattails of a pro (gunner in a chopper or gunboat, for example), they might get categorized as strong. There's no perfect answer for individuals, its all about averages.

Ahh awesome info. You're the best man. This kind of confirmed my thoughts also. I know for sure my BattelogSPM doesn't really reflect my play. I sometimes will spend the round not doing anything because I am waiting for the teams or games to somewhat even up. This I am sure is rare for most players. Most just want to destroy the other side but I feel I get much more points when the game goes back and forth. I have also had the same thoughts about players who may play a lot of like tdm and then jump on for a round or 2 of Conquest. I think SPM is all about Conquest but yeah not exactly for TDM which is more about K/D.

 

Last night I was spectating. I was watching them play a round of locker. The game was great is was pretty much back and forth only separated by about 15-20 tickets the whole time. Then right around the 400 ticket mark the RU side lost about 3 players at once. One player was a fellow clan member. He chatted me and asked if the server crashed and I said no everyone is still playing. He said O I had the directx crash. lol Welcome to battlefield. I don't know what happened with the other 2 players. Not sure if they quit or crashed. At that same time people were in the que but of course it took them a bit to load into the game. Once all this happened the RU team could never recover and the score ended US 295 - RU 0

 

We have had a lot of games like this. I think for now I will just keep the settings at BattlogSPM. As far as the added feature I think that would be awesome. That is totally up to you though. No pressure. I still believe that when more time goes by and SPM is more of a real value and the crashes stop happening only then will games stay close round after round. Until then we will just deal with the problems.

 

Thanks again for your hard work and time.

[ImportBot]

Originally Posted by originalhandy*:

 

Weve had it where it was 23+1 vs 23, the team with the commander was winning and it took a player from them making it 22+1 vs 24. Id rather it leave teams instead of that.

 

The +1 is the commander.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Weve had it where it was 23+1 vs 23, the team with the commander was winning and it took a player from them making it 22+1 vs 24. Id rather it leave teams instead of that.

 

The +1 is the commander.

That doesn't make sense. 24 vs 23 is considered balanced no matter what your settings are, so no one should have been moved. Are you sure it wasn't 21 (20+1) vs 23? Are you sure it was MULTIbalancer that moved a player? It might have been Battlelog Join on Friend.

 

Also, prior to Procon 1.4.1.4 (the latest), no plugin could tell the difference between commanders/spectators and regular players, so 23+1 is just 24 as far as all plugins were concerned, including MB. The next version of MB will use the new Procon feature and be able to exclude commanders and spectators. But for now, balance might be off by the number of commanders+spectators on teams.

[ImportBot]

Originally Posted by originalhandy*:

 

It had SYSOP as the admin did it so I presume it was the bot. Ill upgrade as soon as the next update is out. The other stuff you told me to do has it working much smoother like I wanted. I appreciate your help.

 

Sent from my SCH-I535 using Tapatalk 2

[ImportBot]

Originally Posted by PapaCharlie9*:

 

It had SYSOP as the admin did it so I presume it was the bot.

I don't think the name "SYSOP" appears anywhere in the MULTIbalancer code. Never seen that before, myself.

[ImportBot]

Originally Posted by Chilace*:

 

I don't think the name "SYSOP" appears anywhere in the MULTIbalancer code. Never seen that before, myself.

"SYSOP" not related to MULTIbalancer. It appears in procon events tab. For example, if a Latency Manager kicked someone it also appears as sysop.

[ImportBot]

Originally Posted by originalhandy*:

 

Ok, if a user moves themselves does it show sysop or does sysop only show when a procon script does something?

 

Sent from my SCH-I535 using Tapatalk 2

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Ok, if a user moves themselves does it show sysop or does sysop only show when a procon script does something?

The SYSOP part isn't the important part. The event type is what matters. PlayerSwitchedTeams is the player moving himself or the game server moving him (initial join or between round team swap). PlayerMovedByAdmin is something else, either a plugin or a manual admin move using Procon or a console command. Not definitive proof it was specifically MULTIbalancer.

 

But there's no need for guesswork. MULTIbalancer tells you what it is doing in the plugin.log. If you've got plugin.log enabled, you can tell for sure what it did and why.

 

If you have Log Chat set to True, MULTIbalancer will also log all the chat messages it sends to players in the chat.log (window), and it always sends a message when it moves someone.

[ImportBot]

Originally Posted by ColColonCleaner*:

 

Can you explain ticket difference %, and why it is so high every time even after good matches?

 

800 ticket server and match ends with 70 tickets left. Ticket difference % is 5000...which is supposed to mean maximum baserape if i'm thinking about it correctly. It's always 5000 unless there are only like 10 tickets left between teams after 800, which is just ridiculous. Can this be explained?

[ImportBot]

Originally Posted by HexaCanon*:

 

would love clarification for the language used in unstacking settings.

 

max unstacking swaps per round : 4

 

each 1 means one player from team 1 and 1 player from team 2 getting swapped around ?

or

each 2 means one player from team 1 and 1 player from team 2 getting swapped around ?

 

number of swaps per group : 2

 

each 1 means one player from team 1 and 1 player from team 2 getting swapped around ?

or

each 2 means one player from team 1 and 1 player from team 2 getting swapped around ?

 

 

sorry even when i read what i have written above i dont get it, i am confused

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Can you explain ticket difference %, and why it is so high every time even after good matches?

 

800 ticket server and match ends with 70 tickets left. Ticket difference % is 5000...which is supposed to mean maximum baserape if i'm thinking about it correctly. It's always 5000 unless there are only like 10 tickets left between teams after 800, which is just ridiculous. Can this be explained?

Looks like it is a bug in MULTIbalancer.

 

The percentage is the ratio of winning tickets to losing tickets. In countdown modes, the losing team's tickets at the end of a round are always zero. To avoid divide by zero errors, the ratio is computed as winner/Math.Max(1, loser). The ratio of winner tickets/loser tickets is capped at 50.0 in order to keep percentages at reasonable levels, otherwise, a rout on a 1600 ticket server where the final values are 1234 vs 0 would be 123400%, which is a stupidly large number.

 

The bug is that it should be using the countdown mode normalized calculation for percentage, which is (goal-loser)/Math.Max(1, (goal-winner)), where goal is the maximum number of tickets. In that case, the 1234 vs 0 situation would be (1600-0)/Math.Max(1, (1600-1234)) = 4.37, or 437%, a much more reasonable number than 5000%. The normalized value is what is used for deciding if the Scrambler should be activated.

 

I'll fix this for the next update, which is waiting for the Procon update for team factions.

[ImportBot]

Originally Posted by ColColonCleaner*:

 

Looks like it is a bug in MULTIbalancer.

 

The percentage is the ratio of winning tickets to losing tickets. In countdown modes, the losing team's tickets at the end of a round are always zero. To avoid divide by zero errors, the ratio is computed as winner/Math.Max(1, loser). The ratio of winner tickets/loser tickets is capped at 50.0 in order to keep percentages at reasonable levels, otherwise, a rout on a 1600 ticket server where the final values are 1234 vs 0 would be 123400%, which is a stupidly large number.

 

The bug is that it should be using the countdown mode normalized calculation for percentage, which is (goal-loser)/Math.Max(1, (goal-winner)), where goal is the maximum number of tickets. In that case, the 1234 vs 0 situation would be (1600-0)/Math.Max(1, (1600-1234)) = 4.37, or 437%, a much more reasonable number than 5000%. The normalized value is what is used for deciding if the Scrambler should be activated.

 

I'll fix this for the next update, which is waiting for the Procon update for team factions.

Yeah, it's scrambling after every match which is causing very random and unpredictable results. Glad this is being fixed.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

would love clarification for the language used in unstacking settings.

 

max unstacking swaps per round : 4

 

each 1 means one player from team 1 and 1 player from team 2 getting swapped around ?

or

each 2 means one player from team 1 and 1 player from team 2 getting swapped around ?

 

number of swaps per group : 2

 

each 1 means one player from team 1 and 1 player from team 2 getting swapped around ?

or

each 2 means one player from team 1 and 1 player from team 2 getting swapped around ?

 

 

sorry even when i read what i have written above i dont get it, i am confused

TBH, I get confused too.

 

The problem is that there are three concepts that need to be understood and each needs an understandable name.

 

1) Swap: always a pair of single-player moves, one weak player and one strong player that exchange places on teams

 

2) Group: a number of swaps done during an unstacking activation

 

3) Delay: seconds between each group

 

Unstacking needs to be done in groups. A single swap (2 moves) is not enough, usually, to affect team unstacking. Therefore several swaps need to be done in a single group.

 

These concepts map directly to the corresponding settings:

 

Max Unstacking Swaps Per Round

Number Of Swaps Per Group

Delay Seconds Between Swap Groups

 

Let's look at some examples:

 

Max Unstacking Swaps Per Round: 6

Number Of Swaps Per Group: 2

Delay Seconds Between Swap Groups: 300

 

The total number of swaps allowed in a round is 6. That means at most 12 players will be moved, 6 weak and 6 strong.

 

Each time unstacking is detected, 2 swaps will be done (total of 4 moves), up to the maximum of 6 -- the 2 swaps form a group.

 

After a group of swaps is completed, if unstacking is still needed, at least 5 minutes (300 seconds) must elapse before the next group of swaps is attempted, again, up to a maximum of 6 swaps.

 

So at time 10:00, Group 1 of swaps is done:

 

Swap #1: Strong1 to losing team, Weak1 to winning team

Swap #2: Strong2 to losing team, Weak2 to winning team

 

Unstacking is still needed, so 5 minutes later at 10:05, Group 2 of swaps is done:

 

Swap #3: Strong3 to losing team, Weak3 to winning team

Swap #4: Strong4 to losing team, Weak4 to winning team

 

Unstacking is still needed, so 5 minutes later at 10:10, Group 3 of swaps is done:

 

Swap #5: Strong5 to losing team, Weak5 to winning team

Swap #6: Strong6 to losing team, Weak6 to winning team

 

Unstacking is still needed, but unfortunately, the maximum number of swaps (6) has been done already, so no more swaps may be done for the rest of the round.

 

 

Max Unstacking Swaps Per Round: 12

Number Of Swaps Per Group: 3

Delay Seconds Between Swap Groups: 600

 

The total number of swaps allowed in a round is 12. That means at most 24 players will be moved, 12 weak and 12 strong.

 

Each time unstacking is detected, 3 swaps will be done (total of 6 moves), up to the maximum of 12 -- the 3 swaps form a group.

 

After a group of swaps is completed, if unstacking is still needed, at least 10 minutes (600 seconds) must elapse before the next group of swaps is attempted, again, up to a maximum of 12 swaps.

 

So at time 22:00, Group 1 of swaps is done:

 

Swap #1: Strong1 to losing team, Weak1 to winning team

Swap #2: Strong2 to losing team, Weak2 to winning team

Swap #3: Strong3 to losing team, Weak3 to winning team

 

Unstacking is still needed, so 10 minutes later at 22:10, Group 2 of swaps is done:

 

Swap #4: Strong4 to losing team, Weak4 to winning team

Swap #5: Strong5 to losing team, Weak5 to winning team

Swap #6: Strong6 to losing team, Weak6 to winning team

 

Unstacking is still needed, so 10 minutes later at 22:20, Group 3 of swaps is done:

 

Swap #7: Strong7 to losing team, Weak7 to winning team

Swap #8: Strong8 to losing team, Weak8 to winning team

Swap #9: Strong9 to losing team, Weak9 to winning team

 

Unstacking is no longer needed, so nothing further happens. We did not reach the max of 12 swaps, so if unstacking were needed later, and as long as at least 10 minutes had elapsed (22:30 or later), 1 more group of 3 swaps may be attempted.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Yeah, it's scrambling after every match which is causing very random and unpredictable results. Glad this is being fixed.

I don't understand. I said the Scrambler uses the correct ticket percentage measurement. I've been doing some logging/testing recently, and Scrambler is working correctly for me. What do you mean by "very random and unpredictable results"? Provide details.

[ImportBot]

Originally Posted by HexaCanon*:

 

long post

and unstacking is one move right ?

 

Code:

[23:20:05 15] [MULTIbalancer]:2 FINAL STATUS FOR PREVIOUS ROUND:
[23:20:05 15] [MULTIbalancer]:0 Status: Map = Operation Locker, mode = Conquest Large, time in round = 00:43:46, tickets = 384/0 <- [1600]
[23:20:05 15] [MULTIbalancer]:0 Status: Ticket difference = 384, ticket ratio percentage is 5000%
[23:20:05 15] [MULTIbalancer]:0 Status: 1/63 raged, 0 reassigned, 2 balanced, [b]8 unstacked[/b], 14 unswitched, 379 excluded, 252 exempted, 0 failed; of 2038 TOTAL
[23:20:05 15] [MULTIbalancer]:0 Status: Team counts [60] = 31(US) vs 31(RU), with 2 unassigned

since i have max swaps per round at 4.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

and unstacking is one move right ?

 

Code:

[23:20:05 15] [MULTIbalancer]:2 FINAL STATUS FOR PREVIOUS ROUND:
[23:20:05 15] [MULTIbalancer]:0 Status: Map = Operation Locker, mode = Conquest Large, time in round = 00:43:46, tickets = 384/0 <- [1600]
[23:20:05 15] [MULTIbalancer]:0 Status: Ticket difference = 384, ticket ratio percentage is 5000%
[23:20:05 15] [MULTIbalancer]:0 Status: 1/63 raged, 0 reassigned, 2 balanced, [b]8 unstacked[/b], 14 unswitched, 379 excluded, 252 exempted, 0 failed; of 2038 TOTAL
[23:20:05 15] [MULTIbalancer]:0 Status: Team counts [60] = 31(US) vs 31(RU), with 2 unassigned

since i have max swaps per round at 4.

In the Status messages, X unstacked is the number of moves, not swaps, so yes, "one move".

[ImportBot]

Originally Posted by HexaCanon*:

 

In the Status messages, X unstacked is the number of moves, not swaps, so yes, "one move".

nice thank you

 

you know you could update the FAQ for the plugin.

[ImportBot]

Originally Posted by ColColonCleaner*:

 

I don't understand. I said the Scrambler uses the correct ticket percentage measurement. I've been doing some logging/testing recently, and Scrambler is working correctly for me. What do you mean by "very random and unpredictable results"? Provide details.

I mean it's scrambling after every match, so if teams are generally equally matched it will still scramble them the next round leading to higher chance of imbalance.

 

One thing i have noticed also is that it seems to favor swapping one player over and over, not during the same match but each subsequent match they are in the server it will again choose them to be balanced, causing some rage. Any way to stop this from happening?

[ImportBot]

Originally Posted by Strudaklitt*:

 

Awesome plugin that works very good! I have a quick question though, how do I make the plugin to stop forcing friends into the same teams, even though that team is/will become bigger than the other one?

[ImportBot]

Originally Posted by PapaCharlie9*:

 

you know you could update the FAQ for the plugin.

Good idea. Done!

[ImportBot]

Originally Posted by PapaCharlie9*:

 

I mean it's scrambling after every match, so if teams are generally equally matched it will still scramble them the next round leading to higher chance of imbalance.

Perhaps your percentage setting needs adjustment then? I just logged 4 different servers for 24 hours, all with scrambling enabled, BF3 Conquest, BF4 Conquest, BF4 TDM and BF4 Rush. All of them scrambled according to the percentage setting as expected.

 

Here's an example of correctly deciding not to scramble (BF4 Rush):

 

Code:

[15:51:25] [MULTIbalancer]:6 (SCRAMBLER) Ratio T1/T2: 0 vs 11 <- [74]: 74/63 = 1.17
[15:51:25] [MULTIbalancer]:6 (SCRAMBLER) Only On Final Ticket Percentage >= 120%, but ratio is only 117%
[15:51:26] [MULTIbalancer]:2 FINAL STATUS FOR PREVIOUS ROUND:
[15:51:26] [MULTIbalancer]:0 Status: Plugin state = Active, game state = RoundEnding, Only Move Weak Players, Unstacking Disabled, Logging Only Mode Enabled
[15:51:26] [MULTIbalancer]:0 Status: Map = Operation Locker, mode = Rush, stage = 2, time in round = 00:08:37, tickets = 0/65450(11) <- [74]
[15:51:26] [MULTIbalancer]:0 Status: Ticket difference = 11, ticket ratio percentage is 117%

Here's an example of correctly deciding to scramble (BF4 Rush):

 

Code:

[15:23:38] [MULTIbalancer]:6 (SCRAMBLER) Ratio T1/T2: 0 vs 51 <- [75]: 75/24 = 3.13
[15:23:38] [MULTIbalancer]:6 (SCRAMBLER) Only On Final Ticket Percentage >= 120% and ratio is 313%
[15:23:38] [MULTIbalancer]:6 (SCRAMBLER) Scrambling teams by RoundScore in 55 seconds
[15:23:38] [MULTIbalancer]:2 FINAL STATUS FOR PREVIOUS ROUND:
[15:23:38] [MULTIbalancer]:0 Status: Plugin state = Active, game state = RoundEnding, Only Move Weak Players, Unstacking Disabled, Logging Only Mode Enabled
[15:23:38] [MULTIbalancer]:0 Status: Map = Golmud Railway, mode = Rush, stage = 1, time in round = 00:05:53, tickets = 0/65511(51) <- [75]
[15:23:38] [MULTIbalancer]:0 Status: Ticket difference = 51, ticket ratio percentage is 313%

One thing i have noticed also is that it seems to favor swapping one player over and over, not during the same match but each subsequent match they are in the server it will again choose them to be balanced, causing some rage. Any way to stop this from happening?

Is the player a "must move" player, meaning some Disperse Evenly rule applies to them? Dispersal pools tend to be smaller (like 4 players total in the server, if that many) and dispersal is higher priority than normal moves, so that can lead to the same person getting moved a lot over the course of several hours.

 

Even if not a "must move" player, if the player tends to be really bad or really good (unless you have Top Scorers excluded, in which case those that are good but not great), they will be more likely to be selected for moving.

 

For normal players (not "must move", they don't benefit from this exclusion), the frequency of moves is controlled by the Minutes After Being Moved exclusion. Set that to a higher number if you want players to be moved less frequently. For example, if you want a player that has been moved to be free of being moved again for the next 3 hours, set it to 180.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Awesome plugin that works very good! I have a quick question though, how do I make the plugin to stop forcing friends into the same teams, even though that team is/will become bigger than the other one?

Not possible for BF4. Battlelog Join on Friend may make teams unbalanced and there is nothing we can do about that.

 

Eventually, other players that did not join on friends will get moved for balance, but there is no way to stop people from joining on friends through the plugin.

[ImportBot]

Originally Posted by AlienTaker*:

 

PapaCharlie i would like to know how do i create a "Enable Disperse Evenly List" because on some modes the balancing doesn't work right

[ImportBot]

Originally Posted by chesterfield*:

 

Papa any better options for Rush 300% Tickets 64player?

 

Multibalancer Rush.jpg

[ImportBot]

Originally Posted by HexaCanon*:

 

PapaCharlie i would like to know how do i create a "Enable Disperse Evenly List" because on some modes the balancing doesn't work right

settings for each mode has "enable disperse evenly list", thats why it might work on some modes and not the other for you

9z9a.png

[ImportBot]

Originally Posted by PapaCharlie9*:

 

PapaCharlie i would like to know how do i create a "Enable Disperse Evenly List" because on some modes the balancing doesn't work right

I need more information. How exactly does "balancing not work right_" The Disperse Evenly List doesn't have anything to do with balancing, unless you mean that you have a list but it isn't dispersing evenly.

 

What are you using the Disperse Evenly List for?

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Papa any better options for Rush 300% Tickets 64player?

 

Multibalancer Rush.jpg

Better for what? Is there something specific you are trying to do, like minimize complaints, or are you just looking for a sanity check?

 

In terms of a sanity check, the only changes I would suggest are in the high/low and early/late settings. Try this, given that your server is 64 player and 300% tickets, which should be 225 per stage, right?

 

Definition Of High Population For Players >=: 40

Definition Of Low Population For Players : 20

 

Definition Of Early Phase As Tickets From Start: 50

Definition Of Last Phase As Tickets From End: 100

 

Also, change your Section 3 balance speeds to this:

 

Early Phase: ... : Fast, Fast, Fast

 

What these changes mean is that at the beginning of every round and every stage, you spend the first 50 tickets balancing aggressively, then you ease off and balance normally for the middle part of the stage, then you shut down the balancer for the last 100 tickets and let things play out. These settings will minimize complaints, at the cost of occasionally having some losers quit and unbalance teams towards the end of lopsided stages/rounds.

[ImportBot]

Originally Posted by chesterfield*:

 

THX a lot Papa

Will test it today

[ImportBot]

Originally Posted by PapaCharlie9*:

 

MULTIbalancer Volunteers Needed

---

UPDATE: Conquest testing is just about complete. Now I need an SQDM server to test on, BF3 or BF4.

 

I'm testing a new feature that enables using forced moves (admin kills) to balance the server when it is grossly out of balance. Up until now MULTIbalancer only moves players when they die, but due to popular demand, I'm finally going to relent and add the much requested feature to force move players for balance (god help us all!) BF4's Join on Friends, command/spectator's muddying the team count waters, and other factors have now made this feature a necessity.

 

I need a BF4 Conquest SQDM server of at least 40 slots that is usually full, but not always full, for testing. Best case is a server that loses a lot of players at end of a round then takes some time to fill up again. You will need to provide me, privately, with connection details for your game server. While I am testing, you will need to disable MULTIbalancer or any other balancer plugin you might be using, in order not to interfere with testing. Ideally, you'd give me both your layer access info and your game server info and I'd do the enabling/disabling for you.

 

Please PM me (PapaCharlie9) if you are interested in helping out.