This is an orphaned plugin! It is no longer supported by the original author. It is maintained by community contributors (see list above). Donations are purely voluntary, without minimum or maximum requirement, and go to the original author, not to the community contributors.

Description

This plugin is a customizable limits/rules enforcer. It allows you to setup and enforce limits based on player statistics, and server state.

It tracks extensive Battlelog stats and round stats. If you feel that there is a stat, or aggregate, or information that really needs to be included, post feedback on this thread. The plugin supports events like OnKill, OnTeamKill, OnJoin, OnSpawn, etc. You are able to perform actions triggered by those events.

Version 0.9.4.0 and later is optionally integrated with a MySQL server (using the Battlelog Cache plugin). This enables caching of Battlelog stats fetching, which over time should reduce the delay caused by restarting Procon/enabling Insane Limits when your server is full. This should also reduce load on Battlelog, which in turn will reduce the number of Web errors and exceptions. This version is compatible with TrueBalancer and other plugins that use stats fetching.

By default, the plugin installs with virtual_mode set to True. This allows you to test your limits/rules without any risk of accidentally kicking or banning anyone. Once you feel your limits/rules are ready, you can disable virtual_mode.

Think this plugin is awesome? You can buy me a beer.

Twitter Live Feed

The live feed shows the plugin state, kicks, and bans for servers that elected to tweet this data.

If you are careless with the rules, sometimes you can end up hurting more than helping. Having said that, it's not up to me or anyone to judge the merit of a limit/rule, otherwise this can become a flame war. Be polite when replying to posts in this thread, and don't flame others because you don't like their rules. I just give you the tool, and you (the server admin) make the rules.

My advise is, think creatively when coming up with the rules, and be open minded. If you do not know how to express your limit ideas in C#, ask in this thread. The data is there, available, ready to be consumed ... you just have to come up with the ideas.

Installation Instructions

Download the zip file containing the plugin source

Extract the source file InsaneLimits.cs

Copy the source file to ProCon's Plugins/BF3 directory

Minimum Requirements

This plugin requires you to have sufficient privileges for running the following commands:

serverInfo

mapList.list

mapList.getMapIndices

admin.listPlayers all

punkBuster.pb_sv_command pb_sv_plist

punkBuster.pb_sv_command pb_sv_ban

punkBuster.pb_sv_command pb_sv_kick

Additionaly, you need to have Read+Write file system permission in the following directories:

<ProCon>/

<ProCon>/Plugins/BF3

<ProCon>/Plugins/BF4

Supported Limit Evaluations

OnJoin - Limit evaluated when player joins

OnLeave - Limit evaluated when player leaves

OnSpawn - Limit evaluated when player spawns

OnKill - Limit evaluated when makes a kill (team-kills not counted)

OnTeamKill - Limit evaluated when player makes a team-kill

OnDeath - Limit evaluated when player dies (suicides not counted)

OnTeamDeath - Limit evaluated when player is team-killed

OnSuicide - Limit evaluated when player commits suicide

OnAnyChat - Limit evaluated when players sends a chat message

OnIntervalPlayers - Limit evaluated (for all players) every evaluation_interval number of seconds

OnIntervalServer - Limit evaluated once every evaluation_interval number of seconds

OnRoundOver - Limit evaluated when round over event is sent by PRoCon

OnRoundStart - Limit evaluated after round over event, when first player spawns

OnTeamChange - Limit evaluated after player switches team (admin move not counted as team-switch)

Note that limit evaluation is only performed after the plugin has fetched the player stats from Battlelog.

When you enable the plugin for the first time in a full server, it will take a couple of minutes to fetch all player stats

Limit Management

Creation - In order to create a new limit, you have to set new_limit variable to True.

This creates a new limit section with default values that you can change.

Deletion - In order to delete a limit, you have to set the variable delete_limit to the numerical id of the limit you want to delete.

Each limit has an id number, you can see the id number in the limit name, e.g. Limit #5.

Limit Definition

At its basic, there are four fields that determine the structure of a limit. These fields are state, action, and first_check, and second_check.

stateEnabled - the limit will be used by the plugin threadDisabled - the limit will be ignored by the plugin threadVirtual - the limit will be used, but actions will be done in virtual_mode

This field is useful if you want to temporarily disable a limit from being used, but still want to preserve its definition.

Also note that each of these actions have a target player. You have to be careful on what target is for each action.

For example, during a Kill event, the target of the action is the Killer. But, during a Death event, the target of the action is the player that was killed. You don't want to accidentally Kick/Ban the wrong player!

first_checkDisabled - the limit does not evaluate anything in the first step of evaluationExpression - the limit uses a C# conditional expression during the first step of evaluationCode - the limit uses a C# code snippet (must return true/false) during the first step of evaluation

second_checkDisabled - the limit does not evaluate anything in the second step of evaluationExpression - the limit uses a C# conditional expression during the second step of evaluationCode - the limit uses a C# code snippet (must return true/false) during the second step of evaluation

Depending on the selected check type, an extra field will be shown for specifying the Expression, or Code text.

Both Expressions, and Code snippets must be syntactically correct in accordance to the C# language.The plugin compiles your Expression/Code in-memory with the Microsoft C# Compiler. If there are compilation errors, those are shown in the plugin log.

If you do not know what C# is, or what an expression is, or what a code snippet is ... do not worry. Study the examples in the Insane Limits - Examples thread. Then, if you are still unclear, how to write an expression or a code snippet, ask for help in this thread.

Limit Evaluation

After compilation, limit evaluation is by far the most important of all steps this plugin goes through.

Limit evaluation is comprised of three steps:

first_check Evaluation

During this step, the plugin executes the Expression/Code in first_check to get a True or False result.

If the result is False, the plugin does not perform any action, and quits. But, if it's True, it keeps going to the next step

second_check Evaluation (optional)

Next, the plugin runs the Expression/Code for the second_check, if it's enabled. If it's not enabled, it keeps going to next step.

action Execution

If the final result of the limit evaluation is True, the plugin then executes the action associated with the limit.

If the final result of the limit evaluation is False, no action is executed.

Objects

When writing a limit Expression or Code snippet, there are several globally defined objects that can be used. These are server, player, killer, victim, kill, plugin, team1, team2, team3, team4, and limit. These objects contain values, and functions that can be accessed from within the Expressions, or Code snippets.

Limit Object

The limit object represents the state the limit that was just activated. This object is only available during the second_check. The limit object implements the following interface:

The KillReasonInterface object represents the friendly weapon name, broken down into separate fields:

Code:

public interface KillReasonInterface
{
String Name { get; } // weapon name or reason, like Suicide
String Detail { get; } // BF4: ammo or attachment
String AttachedTo { get; } // BF4: main weapon when Name is a secondary attachment, like M320
String VehicleName { get; } // BF4: if Name is Death, this is the vehicle's name
String VehicleDetail { get; } // BF4: if Name is Death, this is the vehicle's detail (stuff after final slash)
}

Player, Killer, Victim Objects

The player object represents the state of player for which the current limit is being evaluated. The player object implements the following interface:

The Data object is a nested dictionary of key/value pairs that you can use to store custom data inside the plugin, server, limit, player, killer, and victim objects. The Data object implements the following interface:

This plugin supports an extensive list of message text replacements. A replacement is a string that starts and ends with the percent character %. When you use them in the text of a message, the plugin will try to replace it with the corresponding value. For example:

The message

Code:

%k_n% killed %v_n% with a %w_n%

becomes

Code:

micovery killed NorthEye with a PP-2000

Below is a list of all the replacements supported. Some replacements are not available for all types of events. For example, Killer-Name replacement is not available for OnSpawn event.

Code:

// Killer Replacements (Evaluations: OnKill, OnDeath, OnTeamKills, and OnTeamDeath)
/* Legend:
* k - killer
* n - name
* ct - Clan-Tag
* cn - Country Name
* cc - Country Code
* ip - IPAddress
* eg - EA GUID
* pg - Punk Buster GUID
*/
%k_n% Killer name
%k_ct% Killer clan-Tag
%k_cn% Killer county-name
%k_cc% Killer county-code
%k_ip% Killer ip-address
%k_eg% Killer EA GUID
%k_pg% Killer Punk-Buster GUID
%k_fn% Killer full name, includes Clan-Tag (if any)
// Victim Replacements (Evaluations: OnKill, OnDeath, OnTeamKills, and OnTeamDeath)
/* Legend:
* v - victim
*/
%v_n% Victim name,
%v_ct% Victim clan-Tag
%v_cn% Victim county-name
%v_cc% Victim county-code
%v_ip% Victim ip-address
%v_eg% Victim EA GUID
%v_pg% Vitim Punk-Buster GUID
%v_fn% Victim full name, includes Clan-Tag (if any)
// Player Repalcements (Evaluations: OnJoin, OnSpawn, OnAnyChat, OnTeamChange, and OnSuicide)
/* Legend:
* p - player
* lc - last chat
*/
%p_n% Player name
%p_ct% Player clan-Tag
%p_cn% Player county-name
%p_cc% Player county-code
%p_ip% Player ip-address
%p_eg% Player EA GUID
%p_pg% Player Punk-Buster GUID
%p_fn% Player full name, includes Clan-Tag (if any)
%p_lc% Player, Text of last chat
// Weapon Replacements (Evaluations: OnKill, OnDeath, OnTeamKill, OnTeamDeath, OnSuicide)
/* Legend:
* w - weapon
* n - name
* p - player
* a - All (players)
* x - count
*/
%w_n% Weapon name,
%w_p_x% Weapon, number of times used by player in current round
%w_a_x% Weapon, number of times used by All players in current round
// Limit Replacements for Activations & Spree Counts, Current Round (Evaluations: Any)
/* Legend:
* th - ordinal count suffix e.g. 1st, 2nd, 3rd, 4th, etc
* x - count, 1, 2, 3, 4, etc
* p - player
* s - squad
* t - team
* a - All (players)
* r - SpRee
*/
%p_x_th% Limit, ordinal number of times limit has been activated by the player
%s_x_th% Limit, ordinal number of times limit has been activated by the player's squad
%t_x_th% Limit, ordinal number of times limit has been activated by the player's team
%a_x_th% Limit, ordinal number of times limit has been activated by all players in the server
%r_x_th% Limit, ordinal number of times limit has been activated by player without Spree value being reset
%p_x% Limit, number of times limit has been activated by the player
%s_x% Limit, number of times limit has been activated by the player's squad
%t_x% Limit, number of times limit has been activated by the player's team
%a_x% Limit, number of times limit has been activated by all players in the server
%r_x% Limit, number of times limit has been activated by player without Spree value being reset
// Limit Replacements for Activations, All Round (Evaluations: Any)
/* Legend:
* xa - Total count, for all rounds
*/
%p_xa_th% Limit, ordinal number of times limit has been activated by the player
%s_xa_th% Limit, ordinal number of times limit has been activated by the player's squad
%t_xa_th% Limit, ordinal number of times limit has been activated by the player's team
%a_xa_th% Limit, ordinal number of times limit has been activated by all players in the server
%p_xa% Limit, number of times limit has been activated by the player
%s_xa% Limit, number of times limit has been activated by the player's squad
%t_xa% Limit, number of times limit has been activated by the player's team
%a_xa% Limit, number of times limit has been activated by all players in the server
// Other replacements
%date% Current date, e.g. Sunday December 25, 2011,
%time% Current time, e.g. 12:00 AM
%server_host% Server/Layer host/IP
%server_port% Server/Layer port number
%l_id% Limit numeric id"
%l_n% Limit name""

Advanced Replacements

In addition to the simple %key% replacments, this plugin also allows you to use a more advanced type of replacement. Within strings, you can use replacements that match properties in known objects. For example, if you use player.Name within a string, the plugin will detect it and replace it appropriately.

A common usage for advanced replacements is to list player stats in the Kick/Ban reason. For example:

use_direct_fetchTrue - if the cache is not available, fetch stats directly from BattlelogFalse - disable direct fetches from Battlelog

If the Battlelog Cache plugin is installed, up-to-date and enabled, it will be used for player stats regardless of the setting of this option. If the Battlelog Cache plugin is not installed, not up-to-date or disabled, setting use_direct_fetch to True will act as a fallback system, fetching stats directly from Battlelog. Otherwise, stats fetching will fail since the cache is not available and this setting is False. In other words, when Battlelog Caches is available, it is used for stats fetching always. When it is not available, you can enable or disable fetching of stats directly from Battlelog with this setting.

Visible only if use_direct_fetch is set to True. Fetching weapon stats from Battlelog takes a long time, 15 seconds or more per player. By default, this slow fetch is disabled (False), so that your Procon restart or initial plugin enable time on a full server won't be delayed or bogged down while fetching weapon stats. However, if you have limits that use the GetBattlelog() function, you must set this value to True, or else stats will not be available. Also, see rcon_to_battlelog_codes.

NOTE: by default, use_slow_weapon_stats is set to False. If you set use_direct_fetch to False also, you will not see this setting. If you are using Battlelog Cache, you will not get per player weapon stats unless you do the following: temporarily set use_direct_fetch to True, set use_slow_weapon_stats to True, then set use_direct_fetch back to False.

use_stats_logTrue - log Battlelog stats to the battle.log fileFalse - do not log Battlelog stats to the battle.log file

If set to True and stats fetching is enabled and stats are fetched successfully, all the stats that were fetched will be logged in a file that follows the standard logging file name pattern: procon/Logs/<server-ip>_<server-port>/YYYYMMDD_battle.log (text file).

player_white_list(string, csv) - list of players that should never be kicked or banned

clan_white_list(string, csv) - list of clan (tags) for players that should never be kicked or banned

virtual_modetrue - limit actions (kick, ban) are simulated, the actual commands are not sent to serverfalse - limit actions (kick, ban) are not simulated

console(string) - you can use this field to run plugin commands

For example: !stats micovery will print the player statistic for the current round in the plugin console.

Note that plugin commands, are currently supported only inside ProCon, and not In-Game.

Visible only if use_slow_weapon_stats is True. Lets you define mappings from RCON weapon codes to Battelog weapon stats codes. Useful when new unlocks or DLC are released and in-use before the next update of this plugin is available. You can also override incorrect mappings built-in to the plugin, if any.

smtp_port(String) - Address of the SMTP Mail server used for Mail action

smtp_port(integer > 0) - port number of the SMTP Mail server used for Mail action

smtp_account(Stirng) - mail address for authenticating with the SMTP Mail used for Mail action

smtp_mail(Stirng) - mail address (Sender/From) that is used for sending used for Mail action

This is usually the same as smtp_account ... depends on your SMTP Mail provider.

smtp_ssltrue - mail sent using secure socket (use this only if your SMTP provider requires it)false - mail sent without using secure socket

say_interval(float) - interval in seconds between say messages. Default value is 0.05, which is 50 milli-seconds

The point of this setting is to avoid spam, but you should not set this value too large. Ideally it should be between 0 and 1 second.

update_interval(float) - interval in seconds between updates to certain player and server properties

In order to avoid lagging your Procon client or layer, certain values like plugin.IsSquadLocked and server.FriendlyFire are only updated every update_interval seconds, which must be 60 or more.

auto_hide_sectionstrue - when creating a new section, it will be hidden by defaultfalse - when creating a new section, it will not be hidden

twitter_reset_defaultstrue - resets the Twitter's access_token, and access_token_secret back to default values

twitter_setuptrue - initiates the Twitter configuration, it will show a link that you have to visit to get the verification PIN

twitter_verifier_pin(String) - this field is displayed for you to enter the Twitter verification PIN, it disappears as soon as you enter it

After entering your PIN, the plugin will try to exchange the PIN for a Twitter access_token, and access_token_secret. If the verifcation stage fails, you must re-initiate the Twitter setup process.

wait_timeout(int) - interval in seconds to wait for a response from the game server

If you get several Timeout(xx seconds) expired, while waiting for ... exceptions in plugin.log, try increasing the wait_timeout value by 10 seconds. Repeat until the exceptions stop, but you should not exceed 90 seconds.

Plugin Commands

These are the commands supported by this plugin. You can run them from within the console field. Replies to the commands are printed in the plugin log.

The plugin will fail to load and will not show up in your Plugins list unless you use Procon 1.4.2.1 or later.

Before downloading, read these IMPORTANT Frequently Asked Questions:

If you post a question that is answered by this FAQ section, then I know you didn't take the time to read this #1 post, so why should I take the time to reply to you? Fair is fair, you need to put effort into helping yourself first if you want me to put effort into helping you.

Q: I downloaded the ZIP, but how do I install it?A: Extract the InsaneLimits.cs file from the zip, that is the only file you need. Upload/copy it into either (or both) procon/Plugins/BF3 or procon/Plugins/BF4. Restart Procon. I you use a layer, all of the above must happen on your layer host, not on your local client.

Q: I get EXCEPTION: System.Security.SecurityException! Why?A: Insane Limits is a plugin that needs to run without restrictions. Change your Procon settings as follows:

If you already have that set, make sure your Procon layer host has write permission for the entire Procon installation folder.

Q: I get ERROR: X errors compiling Expression! Why?A: Probably because you set first_check to Expression instead of what the instructions in the post told you to set it to, probably Code.

Q: All my limits are gone after I restarted Procon! -or- Why does it keep asking me to accept permissions after I restart Procon, I already accepted them!?A: See this post for details about what you should and should not do when you are in this situation: https://forum.myrcon.com/showthread....l=1#post106210

Additional Details

NOTE: I've changed the version numbering scheme to allow for pre-release testing (last digit). From now on versions will be 0.Major.Minor.TestRevision, where TestRevision is 0 for a released version. If at some point backwards compatibility with existing limits is broken, the first digit will be 1 instead of 0.

As I make design and implementation decisions, I'll tweet them. Feel free to give immediate feedback, but don't no promises that I'll change anything.

Changes made for 0.9.17.0 (REQUIRES Procon 1.5.1.1 or later!)
Added initial support for Battlefield: Hardline. Support is not complete and testing was done on only a few modes.

NOTE: I did NOT update the documentation in post #1 nor in the plugin. You will find no references to BFHL in the docs yet.

NOTE: As of R1/R2, there is a known game server bug where game modes other than Conquest do not report ticket counts. Don't blame Insane Limits, it is DICE's fault.

Fixed clan tag and Battlelog stats fetching

Fixed InsaneLimits.dll location for compilation

Removed commands used only by BF4

Used 0 instead of NaN for stats that failed to fetch

Fixed ratio function

Changes made for 0.9.16.0 (REQUIRES Procon 1.4.2.1 or later!)
Added a Category field to KillInfoInterface. For OnKill, OnDeath, etc., limits, in addition to kill.Weapon, you can now test for kill.Category. The category is taken from BF3.defs and BF4.defs. This should make it easier to limit entire categories of weapons, like all sniper rifles, all handguns (pistols), all explosives, etc.

For example, for a BF4.defs entry like this:

Code:

procon.protected.weapons.add Recon "U_L96A1" Primary SniperRifle

The kill.Weapon would be the String "U_L96A1" and the kill.Category would be the String "SniperRifle".

Also improved plugin.FriendlyWeaponName by extending the KillReasonInterface object to include VehicleName and VehicleDetail. These fields are always null for BF3, but for BF4, if the reason.Name is "Death", you can check the reason.VehicleName and reason.VehicleDetail to see if they have friendly names. For example, for this rather gnarly and long weapon code "Gameplay/Vehicles/RU_FJET_T-50_Pak_FA/RU_FJET_T-50_Pak_FA", the plugin.FriendlyWeaponName function would return a KillReasonInterface object with reason.VehicleName set to "Jet T-50 Pak FA". Much shorter and easier to read in chat. The replacement code %w_n% will always use the reason.VehicleName for BF4 if the kill.Weapon is a vehicle.

For example, a call with {"Test", "double", "TestFloat", "3.14"} would have the same effect as this line of code in a limit:

Code:

plugin.Data.setDouble("TestFloat", 3.14);

Old change log:

Changes made for 0.9.14.0
Improved support for BF4 Battlelog stats. Now at the same level of detail as BF3, including all weapon stats. Also switched to using a more efficient player ping system. Added the following BF4 properties to the server object:

GameVersion - either "BF3" or "BF4", so you can tell which version the game server is

Commander - for vars.commander

MaxSpectators - for vars.maxSpectators

ServerType - for vars.serverType

IMPORTANT NOTE: Since it is still early in the release of BF4, not all of the RCON weapon codes have been matched up with their corresponding Battleog weapon code names for weapon stats. At this writing, China Rising weapon unlocks (e.g,, MTAR-21, MP7, L85A2, L96A1, etc.) are available to some players, but since the DLC has not been officially released yet, there are no corresponding Battlelog stats yet. Also, since the code names are different and not always obvious, some matches may be incorrect. To deal with this situation, a new plugin setting, rcon_to_battlelog_codes has been added. You can use this table to assign RCON codes to Battlelog codes, either when new weapons are available and the plugin hasn't been updated yet, or if the plugin's definition is later found to be incorrect. Your settings override the plugin's built-in definitions. The format of the String[] Array setting is a simple RCON=BATTLELOG code assignment, one per line/item. For example:

Code:

U_LIGHTSABER=WARSAW_ID_P_INAME_LUKE
U_BFG=WARSAW_ID_P_WNAME_DOOM

Changes made for 0.9.13.0
Ported to BF4. Stats fetching updated to BF4 format. Added FriendlyWeaponName function to plugin, works for both BF3 and BF4. Details of the function signature are in post #1. The definition of the KillReasonInterface object is:

Changes made for 0.9.11.0
Due to changes in Battlelog stats around June 15, 2013, Insane Limits needs to be updated. The kdRatio property is being returned as null, where before it had the KDR. Now Insane Limits ignores the kdRatio value and computes the ratio from kills/deaths.

Fixes NullReferenceException during stats fetch of overviewStats

Make player.idleDuration check respect update_interval

Changes made for 0.9.10.0

Fixed problems with player.Ping

Added player.MaxPing

Added player.MinPing

Added player.AveragePing, from 2 to 5 samples

Added player.MedianPing, of 5 samples

Added a new plugin setting, update_interval, which specifies the number of seconds between updates for certain new properties and player/squad values that have been added (see below). The minimum value is 60 seconds. The update_interval insures that your client and layer are not overloaded or lagged by too many requests.

Added server.BulletDamage (vars.bulletDamage)

Added server.FriendlyFire (vars.friendlyFire)

Added server.GunMasterWeaponsPreset (vars.gunMasterWeaponsPreset)

Added server.IdleTimeout (vars.idleTimeout)

Added server.SoldierHealth (vars.soldierHealth)

Added server.VehicleSpawnAllowed (vars.vehicleSpawnAllowed)

Added server.VehicleSpawnDelay (vars.vehicleSpawnDelay)

Added plugin.IsSquadLocked function

Added plugin.GetSquadLeaderName function

All of the new properties and functions are read-only. In order to set them for your server, use the plugin.ServerCommand function. Keep in mind that until the OnJoin limit for the player has been evaluated, the player and squad properties will not be updated. Even after that time, it will take at least update_interval seconds before the value is updated. If you just enabled Insane Limits, it will take several minutes before everything catches up.

Changes made for 0.9.9.0

Incorporated some new features of BF3 R-38 and Procon 1.4.0.7.

Added player.Ping (returns int)

Added server.GameModeCounter (returns double)

Added server.CTFRoundTimeModifier (returns double)

Added plugin.CheckPlayerIdle(String name) function (returns double)

Note about the use of plugin.CheckPlayerIdle

This function is a bit tricky to use. In order to reduce load on the game server and layer, a player's idle is only checked if their current round Score is 0 and their current round Deaths is 0. This check is performed periodically (OnListPlayers). For all other cases, the idle is returned as 0. This means that a player who started to play the round and then went idle will have an idle time of 0. If the name of the player is not recognized, -1 is returned.

Each call to CheckPlayerIdle that returns 0 will request an update from the server, so that the next time you call the function for the same player, you will have an updated idle time. That said, it doesn't do any good to do this in a single limit:

The second call will also return 0, because the game server hasn't had a chance to process the request yet.

Instead, this function is best used in OnIntervalServer limits. Each interval, you can check a list of players, calling plugin.CheckPlayerIdle just once. Eventually, the call will return an updated value -- which may be 0 if the player is indeed not idle!

Changes made for 0.9.8.0:

Added plugin.GetReservedSlotList function

Added plugin.CheckAccount function

Added use_stats_log plugin setting

Fixed NullReferenceException errors when using Battlelog Cache. In general, reduced the amount of logging spam when using Battlelog Cache for debug_level 3 or lower.

NOTE: since logging of error messages has been reduced, you have to increase your debug_level in order to see warnings and errors that you used to see at level 3. If you want to see why stats fetching is failing, you have to set your debug_level to 4.

Usage of plugin.GetReservedSlotList()

Code:

List<String> GetReservedSlotsList();

You can now use your reserved slots list in your limit code. You can use it instead of whitelist or custom lists. For example, the first time a player on the reserved slots lists spawns, send a yell to all players with this OnSpawn second_check Code:

NOTE: The list is only fetched once, at plugin activation time. If you edit the reserved slots list in the middle of a game session while Insane Limits is active, the update will not be recognized unless you disable Insane Limits, wait a few seconds, and then enable Insane Limits again. Alternatively, if you don't want to disable Insane Limits, you can go to the Console tab in Procon and type this RCON command to the game server:

You can now check to see if a player has an account on your Procon instance and what privileges they have. A player with an account that has canKick privilege may be treated as an admin from your limit code. If the function returns False, the player is not currently joined on the server or the player does not have an account in your Procon instance.

Fixed "overviewStats not found" WARNING for players with ps3 or xbox profiles

Added failed url to StatsException error message

NOTE: since logging of error messages has been reduced, you have to increase your debug_level in order to see warnings and errors that you used to see at level 3. If you want to see why stats fetching is failing, you have to set your debug_level to 4.

Changes made for 0.9.6.0:

Fixed a serious problem with moving players introduced in 9.5

Fixed OnLevelLoaded spurious log of aborted round reset

Fixed round start and round end detection problems

NOTE: since logging of error messages has been reduced, you have to increase your debug_level in order to see warnings and errors that you used to see at level 3. If you want to see why stats fetching is failing, you have to set your debug_level to 4.

Changes made for 0.9.5.0:

Stats fetching speed-up, shaved 3 to 5 seconds off of every fetch

Added plugin.FriendlyMapName to convert "MP_001" to "Grand Bazaar"

Added plugin.FriendlyModeName to convert "TeamDeathMatch0" to "TDM"

Reduced logging spam, particularly for stats fetch errors

Major overhaul of handling of TeamChange events/limits

Tons of minor bug fixes

General clean-up

NOTE: since logging of error messages has been reduced, you have to increase your debug_level in order to see warnings and errors that you used to see at level 3. If you want to see why stats fetching is failing, you have to set your debug_level to 4.

Changes made for 0.9.4.0:

Added Yell action

Enabled player Say action (was already present, but would show an error if attempted to be used -- now it works without an error)

Fixed long-standing problem with advanced replacements, e.g., player.Spm being used when player.SpmRound was specified

Fixed problems with detecting OnRoundOver when round is ended by admin command or Procon GUI

Added use_direct_fetch plugin setting

Pre-release of Battlelog Cache capability (see below)

NOTE: A future version of Procon will enable optional integration with a MySQL database server. When the future version of Procon is released, this version (0.9.4.0) of Insane Limits will be able to take advantage of that integration, by way of a new plugin (yet to be released) called Battlelog Cache. Stay tuned for more details about MySQL integration and Battlelog Cache.

In the mean time, if your debug_level is set to 3 or higher, you may see messages logged in plugin.log that look like this:

Simply ignore these messages for now. If you don't like seeing them, reduce your debug_level to 2 or lower.

Insane Limits 0.9.4.0 is completely compatible with the current version of Procon (1.4.0.4) and has been tested against pre-release versions of the future version of Procon.

When used with the current version of Procon (1.4.0.4), the new use_direct_fetch setting may be used to disable stats fetching altogether. Setting use_direct_fetch to False without the presence of Battlelog Cache amounts to disabling stats fetching. This means that no player will have a clan tag, since clan tags are fetched from Battlelog. Be sure you know what you are doing if you set this to False.

The fetch thread is in charge of monitoring the players that join the server. It fetches player statistics from battlelog.battlefield.com

The enforcer thread is in charge of evaluating Interval limits. When the enforcer thread finds that a player violates a limit, it performs an action (Kick, Ban, etc) against that player.

The two threads have different responsibilities, but they synchronize their work.

Fetch-thread Flow

When players join the server, they are added the stats queue. The fetch thread is constantly monitoring this queue. If there is a player in the queue, it removes him from the queue, and fetches the battlelog stats for the player.

The stats queue can grow or shrink depending on how fast players join, and how long the web-requests take. If you enable the plugin on a full server, you will see that almost immediately all players are queued for stats fetching. Once the stats are fetched for all players in the queue, they are added to the internal player's list.

Enforcer-thread Flow

The enforcer thread runs on a timer (every second). It checks if there are any interval limits ready to be executed. If there are, it will evaluate those limits.

Each time around that the enforcer checks for the available limits is called an iteration. If there are no players in the server, or there are no limits available, the enforcer skips the current iteration and sleeps until the next iteration.

The enforcer is only responsible for Limits that evaluate OnIterval, events. Enforcing for other types of events like OnKill, and OnSpawn, is done in the main thread when procon sends the event information.

HOW TO CLONE YOUR SETTINGS TO A NEW GAME SERVERUpdate for Procon 1.4.2.1 or later

If you add a new server or move your server to a new host (new IP address) and you don't want to re-enter all of your Insane Limits settings and long limits all over again, follow these steps.

In all of the following, ip_port refers to the numbers in file names that correspond to your game server's IP address and port number, respectively. For example, if your game server's IP address is 65.122.92.255 and your port number is 48500, your ip_port would be 65.122.92.25_48500.

The way Insane Limits works is that its general plugin settings are stored in procon/Configs/ip_port/InsaneLimits.cfg, like all other plugins. In those settings is a variable called "limits_file". That is the pointer to your limits and custom lists. By default, the name of that file is procon/Plugins/BF*/InsaneLimits_ip_port.conf, where BF* is either BF3 or BF4. The general objective here is to copy and rename your old .conf file to a new .conf file and make the new .cfg file point at the new .conf file.

2) Navigate to your procon/Configs folder and make backup copies of all of your ip_port/*.cfg files. Personally, I just make a backup copy of the whole Configs folder. Navigate to your procon/Plugins/BF* folder and make backup copies of all of your InsaneLimits_ip_port.conf files. Personally, I just make a backup copy of the whole Plugins folder.

3) Copy your old procon/Configs/OLDip_port/InsaneLimits.cfg file to a new procon/Configs/ip_port/InsaneLimits.cfg file for the new game server connection. This will clone all of your settings for all plugins from the old server to the new.

4) Open your new (cloned) procon/Configs/ip_port/InsaneLimits.cfg file in Notepad (Vista or Server 2008 or later, must be a Unicode-aware text editor).

Note: it doesn't matter if you leave a blank line or not after deleting it, just make sure you don't accidentally delete anthing else.

6) Save the file and close Notepad.

7) Navigate back to procon/Plugins/BF*. Find the InsaneLimits_OLDip_port.conf file and copy it to a new file. Name the new file InsaneLimits_ip_port.conf of the new game server. If there is already a file with the new connection name, replace it with the copy.

10) Restart Procon. Now all your old limits and custom lists should appear in the new game server settings.

If you get asked for the Privacy Policy at any step and you are sure you have already accepted it for that game server connection, disable Insane Limits, wait 60 seconds, enable it again. That should clear it. Alternatively, make sure you have some other plugin highlighted, like the one just above Insane Limits in the list. The settings or details for that other plugin should be showing in the right hand panel. Now click on the check box next to Insane Limits to enable it, without highlighting Insane Limits itself. That should skip the privacy policy check.

Last edited by PapaCharlie9; 11-04-2014 at 16:31.

Don't send me private messages (PMs) unless you really need privacy, like your game server password. If you just have a question or need help, post in one of the threads. It's extra work for me to answer questions and give help in private messages and no one else gets the benefit of the answer.