MULTIbalancer [1.1.6.0] 30-MAR-2015 + BFHL

[ImportBot]

Originally Posted by PapaCharlie9*:

 

The setting of "Enable whitelisting of Reserved Slots list". I had it set to "True". However, reserved slot players were selected for unstacking. I had to manually update the "Whitelist" below the previous setting and only then those players (Reserved slot list) were immune. Is this intended for the feature in bold? If so, it just increases the amount of manual labour needed to maintain "immune" people as we have a script that updates all reserved slots players every x minutes based on donations received.

Two things to watch out for.

 

* The timing and sequence of changes is important

 

* The Reserved Slots List is only requested once by MB, at plugin enable time, in order to reduce network load

 

It's easy to update things in the wrong order, which causes the Reserved Slots List to be ignored.

 

Here's the sequence you need to use to insure that everything updates correctly.

 

1) Enable MB and wait at least 3 seconds. It's even better to wait for 30 seconds, but at least 3. That allows enough time for the game server to reply with the reserved slots list.

 

2) Change the Whitelist. That forces the internal data model to update, including merging the reserved slots list.

 

You can verify that the Whitelist is what you intended by using the lists command in Show Command In Log. It dumps out what the plugin thinks all the lists are after all expansions and merges. If the server is occupied, you can also use the whitelist command to apply the Whitelist to the current list of players in the server to see who gets what kind of exclusion. This is best for testing option codes.

 

Note that while MB only asks for the reserved slots once, it listens to every list command. So if you had a separate plugin that sent reservedSlotsList.list every x minutes AND after 3 seconds, sets MB's Whitelist to the same value it had before (or add a dummy name), you could contrive to make it all work automatically.

 

Assuming Reserved Slots is working, do you have anything in the Whitelist explicitly? Does it change often? If the answer to either of those questions is "no", I could write you an Insane Limit that would do the automation for you. It would just set the Whitelist to a dummy value every x minutes, as well as send the reservedSlotsList.list command. If yes to either, you'll need a separate plugin and you'll have to define your Whitelist in that auxilliarly plugin, and let it set the value in MB for you.

 

EDIT: hmm, maybe it would be best for me to just change MB so that when the reserved slots are updated by anything (somebody else did a reservedSlotsList.list), it updates the data model for whitelist also if Enable Whitelist Of Reserved Slots List is true. MB probably ought to do that anyway. If you want, I can give you a private version that does that (1.0.4.1).

[ImportBot]

Originally Posted by EBassie*:

 

It's possible that even though it looks like the player's tag has been updated, the stats page that the plugin uses might not have been. Any delay in getting the player's tag will of course cause tag-based exclusions to fail.

 

Keep an eye on it and let me know what you find.

 

EDIT: what's your average stats fetch time? Assuming you are not using Battlelog Cache, it shows up in plugin.log as:

 

Code:

Thread(fetcher):  TIME took 1.32 secs, url: http://battlelog.battlefield.com/bf3/user/-MGX-2strong4u

And if he's using Battlelog cache it could be the record was not expired yet and thus not updated with the new tag... (just thinking out loud here)

[ImportBot]

Originally Posted by kcuestag*:

 

I do use Battlelog Cache.

 

So far it has not happened again.

[ImportBot]

Originally Posted by dyn*:

 

Just wanted to make a note that we too have experienced who we thought were whitelisted vip's being teambalanced. The explanation you provided makes perfect sense. We would see the issue after adding someone to the server's vip list and then not restarting procon / MB.

 

I've also been very busy with other items and haven't had a chance to properly test the VERY configurable whitelist feature. Hopefully that will be done soonish. TY

[ImportBot]

Originally Posted by OscarMike*:

 

EDIT: hmm, maybe it would be best for me to just change MB so that when the reserved slots are updated by anything (somebody else did a reservedSlotsList.list), it updates the data model for whitelist also if Enable Whitelist Of Reserved Slots List is true. MB probably ought to do that anyway. If you want, I can give you a private version that does that (1.0.4.1).

Thanks for the info on how MB deals with the whitelists & reserved slot lists! It does explain a few things that I had been wondering about. If you could send that 1.0.4.1 private version it would be great PapaCharlie9, it would eliminate a lot of fiddling around with settings for us

[ImportBot]

Originally Posted by Jaythegreat1*:

 

Just curious... how are people sorting and scrambling by? What do you all find to be most effective?

[ImportBot]

Originally Posted by OscarMike*:

 

Just curious... how are people sorting and scrambling by? What do you all find to be most effective?

I'm mainly running 800tkt Conquest Large servers and for 4. Scrambler I have:

 

Only On New Maps: False

Only On Final Ticket Percentage >= 120

Scramble By: RoundSPM

Keep Squads Together: True

Divide By: none

Delay Seconds: 50

 

I find that going with RoundSPM is more accurate than the Battlelog stats options. Even highly skilled players have "bad rounds" and "low skill" players might occasionally play better than usually. Player score also varies by map/gamemode.

[ImportBot]

Originally Posted by Jaythegreat1*:

 

I'm mainly running 800tkt Conquest Large servers and for 4. Scrambler I have:

 

Only On New Maps: False

Only On Final Ticket Percentage >= 120

Scramble By: RoundSPM

Keep Squads Together: True

Divide By: none

Delay Seconds: 50

 

I find that going with RoundSPM is more accurate than the Battlelog stats options. Even highly skilled players have "bad rounds" and "low skill" players might occasionally play better than usually. Player score also varies by map/gamemode.

I've noticed that too with battlelogSPM, I've been switching between BattlelogSPM, RoundSPM, and Rank to see what is most effective.

[ImportBot]

Originally Posted by kcuestag*:

 

Personally I unstack by RoundSPM and Scramble by Rank to try and keep the ranks on both teams even at round start.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

I do use Battlelog Cache.

 

So far it has not happened again.

I think EB's diagnosis is the correct one. The cache needs up to 24 hours before it will update again.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

I've noticed that too with battlelogSPM, I've been switching between BattlelogSPM, RoundSPM, and Rank to see what is most effective.

For TDM or SQDM, I recommend using RoundKills.

[ImportBot]

Originally Posted by kcuestag*:

 

I think EB's diagnosis is the correct one. The cache needs up to 24 hours before it will update again.

So restarting the Layer updates it instantly?

[ImportBot]

Originally Posted by Jaythegreat1*:

 

For TDM or SQDM, I recommend using RoundKills.

We run Conquest Domination, and Conquest Large.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

So restarting the Layer updates it instantly?

No. You'd have to purge the player's entry from the MySQL database connected to Battlelog Cache.

[ImportBot]

Originally Posted by MorpheusX(AUT)*:

 

No. You'd have to purge the player's entry from the MySQL database connected to Battlelog Cache.

Or change the timestamps to something > 24 hours.

[ImportBot]

Originally Posted by kcuestag*:

 

I see, thanks PC9 and MorpheusX!

[ImportBot]

Originally Posted by wishmaster2002uk*:

 

maybe throw in a pre balance yell that autobalance is starting just so the odd few whingers cant complain they were not warned.

 

otherwise very happy with mb and all its features

 

thankyou for your hard work.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

maybe throw in a pre balance yell that autobalance is starting just so the odd few whingers cant complain they were not warned.

 

otherwise very happy with mb and all its features

 

thankyou for your hard work.

The balancer itself is always on. If you mean when autobalancing is activated, that's a bit tricky to do. Sometimes the activation only lasts a few seconds, it could deactivate before the yell itself finishes showing. Sometimes it goes on for minutes. Sometimes it could activate/deactivate several times a minute. I don't think you want a yell several times a minute.

 

For now, I suggest you use the Spambot plugin to send a message periodically. That's probably as good as whatever I could come up with in MB anyway.

[ImportBot]

Originally Posted by wishmaster2002uk*:

 

ok thats fine but could you tell me why the balancer unbalances teams

i have it set to balance only if we play 3v3 it swaps 1 player so it becomes 4v2 i have altered population settings but regardless of what i do it happens.

 

currently low population is 4 high is 16 on a 32 player server running ctf/tdm/conquest large

[ImportBot]

Originally Posted by RadicalMode*:

 

PapaCharlie you did a very good job. Congratulations!!!

 

[18:47:17 90] [MULTIbalancer]:2 FINAL STATUS FOR PREVIOUS ROUND:

[18:47:17 90] [MULTIbalancer]:0 Status: Map = Operation Metro, mode = Conquest Large, time in round = 00:30:30, tickets = 91/0

[18:47:17 90] [MULTIbalancer]:0 Status: 2/52 raged, 27 reassigned, 3 balanced, 5 unstacked, 11 unswitched, 190 excluded, 67 exempted, 0 failed; of 1328 TOTAL

[18:47:17 90] [MULTIbalancer]:0 Status: Team counts [62] = 30(US) vs 32(RU), with 2 unassigned

[ImportBot]

Originally Posted by PapaCharlie9*:

 

ok thats fine but could you tell me why the balancer unbalances teams

i have it set to balance only if we play 3v3 it swaps 1 player so it becomes 4v2 i have altered population settings but regardless of what i do it happens.

 

currently low population is 4 high is 16 on a 32 player server running ctf/tdm/conquest large

Set Low Population to 6 and set the corresponding Balance Speed to Stop?

[ImportBot]

Originally Posted by PapaCharlie9*:

 

PapaCharlie you did a very good job. Congratulations!!!

 

[18:47:17 90] [MULTIbalancer]:2 FINAL STATUS FOR PREVIOUS ROUND:

[18:47:17 90] [MULTIbalancer]:0 Status: Map = Operation Metro, mode = Conquest Large, time in round = 00:30:30, tickets = 91/0

[18:47:17 90] [MULTIbalancer]:0 Status: 2/52 raged, 27 reassigned, 3 balanced, 5 unstacked, 11 unswitched, 190 excluded, 67 exempted, 0 failed; of 1328 TOTAL

[18:47:17 90] [MULTIbalancer]:0 Status: Team counts [62] = 30(US) vs 32(RU), with 2 unassigned

Wow. For Metro, that's amazing.

[ImportBot]

Originally Posted by wishmaster2002uk*:

 

ty will try it

[ImportBot]

Originally Posted by xFaNtASyGiRLx*:

 

hi, I'm not sure how to post this but today, my US servers all moved over to a different machine, including procon. anyways- I'm now seeing this on my servers:

 

metro:

 

[

14:02:09 75] [MULTIbalancer] REASSIGNING new player Goldy_76 from US team to RU team because difference is 0

[14:02:10 01] [MULTIbalancer] Thread(fetcher): (FETCH) no more requests in Battlelog request queue

[14:02:12 52] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:12 98] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:13 55] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:14 11] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:14 78] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:15 51] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:16 21] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:16 79] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:17 58] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:18 18] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:18 95] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:19 61] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:20 24] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:20 81] [MULTIbalancer] UNSWITCHING [EHN]Goldy_76 from US back to RU

[14:02:28 11] [MULTIbalancer] Thread(fetcher): (FETCH) no more requests in Battlelog request queue

[14:02:43 12] [MULTIbalancer] Thread(fetcher): (FETCH) no more requests in Battlelog request queue

end game cq:

14:04:42 57] [MULTIbalancer] BALANCE moving dav94ne from RU team to US team because difference is 3

[14:04:42 96] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:43 53] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:44 27] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:44 83] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:45 40] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:45 96] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:46 58] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:47 16] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:47 73] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:48 30] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:48 86] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:04:49 56] [MULTIbalancer] UNSWITCHING dav94ne from RU back to US

[14:05:14 80] [MULTIbalancer] Thread(fetcher): (FETCH) no more requests in Battlelog request queue

I'm not using the very latest version because tbh, I am happy with the one before the latest patch and just didn't bother updating. I'm using 1.0.3.0

 

Do you think something got corrupted in the copy to the new box?

 

EDIT: appears to be something with the new box cause spambot/insane limits/asp are doing double stuff :S but the provider can only see one instance of procon.

[ImportBot]

Originally Posted by Singh400*:

 

I'm not using the very latest version because tbh, I am happy with the one before the latest patch and just didn't bother updating. I'm using 1.0.3.0

 

Do you think something got corrupted in the copy to the new box?

 

EDIT: appears to be something with the new box cause spambot/insane limits/asp are doing double stuff :S but the provider can only see one instance of procon.

Make sure the other layer is turned off. The best way to ensure that only one layer is running (in my experience) is to change the server admin password and then change the password on your new layer. The other instance, where ever it is will now be unable to connect.

[ImportBot]

Originally Posted by SnotGoblin*:

 

Just curious, is it possible in a future version to add for the scramble function a scramble by Battlelog Skill Level?

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Just curious, is it possible in a future version to add for the scramble function a scramble by Battlelog Skill Level?

Do you mean the ELO Skill? It's possible, but why would you want to? That number isn't very useful.

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Interested in testing ticket loss ratio triggering of unstacking? I'm going to create a series of private versions of MB to work out the details for the ticket loss ratio feature.

 

The current unstacking trigger is based on ticket ratio. That's fine for a lot of cases, but the ticket ratio is a lagging indicator. It's often too late to unstack teams once the ticket ratio gets to 120% or whatever.

 

Ticket loss ratio is based on the ratio between the rate of loss of tickets between the two teams. The ticket ratio itself might only be 108%, but if one team is losing tickets 3x times faster than the other, it might be better to do unstacking now rather than wait until the ticket ratio reflects the stacked situation.

 

My idea is to introduce some settings that let you control how ticket loss ratio is calculated. The fundamental "heartbeat" for checking the ticket loss rate will be once every 5 seconds (not changeable). You get to specify how many samples the median and average are based on. The fewer samples you use, the more "responsive" the trigger will be, the more you use, the less spikes and temporary rate changes will cause false positives. The existing unstacking ratio percentages specified in Section 3 will be used. You'll have a per-mode setting that allows you to change the intepretation of Section 3 to be ticket loss rate ratio instead of ticket ratio.

 

Another addition will be a CSV log (enable true/false) that will allow you to gather statistics on ticket loss rate and unstacking triggers, so that you can fine tune and even draw graphs like the one in post #4 of this thread.

 

If you are interest in participating in the test, send me a PM with your email address. All of the testing and updates of the test will be done over email.

[ImportBot]

Originally Posted by Blitz*:

 

Hi Papa, definitely count me in.

 

Also on determining when unstacking should be triggered, thinking 3 variables here: the ticket ratio rate, amount of tickets remaining, and criteria to determine strong vs. weak players on each team (as per existing settings in MB). As you said, the real-time values for ticket loss or ticket ratio rate should probably be dampened so as not to trigger unstacking on sudden spikes in the game (maybe an median loss rate over shorter periods - perhaps an adjustable period that would determine the aggressiveness of the trigger_). An example where this could happen but may not affect the game over the long term is when a squad or godly chopper duo moves into high enemy populations and they kill many players in the process but don't actually cap a point. This example is usually short lived but could trigger a false spike.

 

Is this kinda in line with what you are going to do?

[ImportBot]

Originally Posted by PapaCharlie9*:

 

Hi Papa, definitely count me in.

 

Also on determining when unstacking should be triggered, thinking 3 variables here: the ticket ratio rate, amount of tickets remaining, and criteria to determine strong vs. weak players on each team (as per existing settings in MB). As you said, the real-time values for ticket loss or ticket ratio rate should probably be dampened so as not to trigger unstacking on sudden spikes in the game (maybe an median loss rate over shorter periods - perhaps an adjustable period that would determine the aggressiveness of the trigger_). An example where this could happen but may not affect the game over the long term is when a squad or godly chopper duo moves into high enemy populations and they kill many players in the process but don't actually cap a point. This example is usually short lived but could trigger a false spike.

 

Is this kinda in line with what you are going to do?

Yes, absolutely. Two of the variables, tickets remaining (Early, Mid, Late) and strong/weak are already in MB as you noted, those will be the same. I'm just adding the ticket loss rate variable.

 

What I need from potential users of this feature is what logging (CSV, spreadsheet data) do you want? I'll start with these columns:

 

(Log will be log rolled at midnight, so date is built into the log name, e.g., 20130713_tloss.csv)

Time: HH:MM:SS

Round: Number

Map: Text

Mode: Text

Max Players: Number

US Players: Number

RU Players: Number

US Tickets: Number

RU Tickets: Number

Samples: Number

US Average Ticket Loss: Number (looking backward for Samples)

RU Average Ticket Loss: Number (looking backward for Samples)

Strong unstacked to: Number (0 means no unstack this entry, 1 means to US team, 2 means to RU team)

Weak unstacked to: Number (0 means no unstack this entry, 1 means to US team, 2 means to RU team)

 

Anything else?

 

A new entry will be added approximately once every 5 seconds during play, so these files are going to be very big. Maybe I should divide them up by map/mode/round? No entries will be made between rounds or if there less than 4 players in the server.