Persist Antiban Settings to profile.json to avoid manual reconfiguration

[chsami]

Proposal: Save Antiban Settings to profile.json

Summary

Currently, all antiban settings (Rs2AntibanSettings) are static booleans, integers, and doubles that reset on every client restart. Users must reconfigure them manually each time.
This proposal introduces persistence by saving and loading these settings to/from a profile.json file.

Goal

• Allow antiban settings to persist across sessions.
• Store settingsto be added in (profile.json) in the client config directory.
• Auto-load settings on startup, auto-save when values are changed.

Example of settings in the profile.json

{
  "antibanEnabled": true,
  "actionCooldownActive": false,
  "microBreakActive": false,
  "takeMicroBreaks": true,
  "microBreakDurationLow": 3,
  "microBreakDurationHigh": 15,
  "actionCooldownChance": 0.1,
  "microBreakChance": 0.1,
  "moveMouseRandomlyChance": 0.1,
  "moveMouseOffScreenChance": 0.1,
  "naturalMouse": true,
  "moveMouseOffScreen": false,
  "moveMouseRandomly": false,
  "simulateFatigue": false,
  "simulateAttentionSpan": false,
  "behavioralVariability": false,
  "dynamicIntensity": false,
  "dynamicActivity": false,
  "contextualVariability": false,
  "profileSwitching": false,
  "universalAntiban": false,
  "devDebug": false,
  "overwriteScriptSettings": false
}

[Bolado]

Currently, more than 20 different plugins interact with Rs2AntibanSettings, and overwriteScriptSettings only prevents templates from being applied as far as I know. This raises the question of how effective it would be in the current setup, as some plugin values are directly modified regardless. However, it’s clear that it would still benefit plugins that don’t tinker with Rs2AntibanSettings during startup, and only changes made through the panel could be written to the file.

[Bolado]

Right, that is a pretty clear violation of user preferences. As far as I understand the antiban is opt-in, right? Meaning GOTR breaks due to it choosing to implement returning early when Rs2AntibanSettings.actionCooldownActive is true? Or am I missing something and is Rs2Antiban implemented deeper into the API? I was scanning quickly through the code but couldn't find anything that pointed towards that. I'd say that if antiban functionality is opt-in, it makes sense to disable altering user' set preferences from other plugins. If that's not the case and antiban has effect on scripts that did not choose to partake, we cannot enforce something that breaks scripts.

GOTR was just an example; users who faced the issue could simply disable the antiban feature, and the plugin would work again. For GOTR, disabling that specific antiban function in the code would "quick-fix" the problem, not that it's the only fix. I’m not aware of any antiban feature that completely stops a plugin from functioning properly, and if it does, it’s likely due to incorrect use of its functions or issues like the natural mouse not being fast enough. In such cases, it’s clearly the user’s fault for not understanding the required speed for the activity. However, templates could still be used to tackle that, but it needs to be changed so the settings applied through a template is temporary and only used during plugin runtime.

[Krulvis]

I'm still wondering what the coupling is between plugins and antiban. Is antiban opt-in and can we make it opt-out or is it deeply integrated in api calls that affect plugin's performance regardless of whether they choose to be affected by it? From your message I understand that mouse movements is affected by antiban, which I guess interferes with any kind of game interaction. Are there more antiban 'forced' changes like that?
I agree with you that in the case of mouse movements being altered by antiban we can easily say that the user should just change the antiban settings when they see interaction is "too slow" for any plugin to work. If there are no other examples of antiban forcefully changing behaviour and everything else is opt-in then I say we can limit plugins' ability to change antiban settings.

[Bolado]

From your message I understand that mouse movements is affected by antiban, which I guess interferes with any kind of game interaction. Are there more antiban 'forced' changes like that?
Currently, mouse movements are only active if you enable Natural Mouse on the Antiban panel, so it's not exactly forced. The same applies to action cooldowns, if the Antiban panel is disabled, the entire system, including action cooldowns and natural mouse, is essentially turned off.

Antiban isn't perfect, largely due to issues we've discussed in the GH thread:

• User-tweaked settings lack persistence and are overwritten by 20+ plugins whenever they run.
• No functionality for "settings to apply during a plugin's runtime."
• Setting values aren't private, so making them private with public getters could let plugins read them for user warnings (even maybe calling stopPLugin if an antiban feature is 100% not supported by the plugin`.

In my opinion, a good approach would be addressing the points mentioned above while implementing persistence through a JSON file and modifying the plugins to accommodate this change. In the past I even made modifications to plugins that were enforcing micro-breaks 🙉. To be honest, I'm guilty of this myself. In one of my plugins, I enforce natural mouse movement and action cooldown because I wanted to design it around some Antiban features 🤷🏼‍♂️...

Rs2Antiban.setActivity(Activity.GENERAL_COOKING);
Rs2AntibanSettings.naturalMouse = true;
Rs2AntibanSettings.actionCooldownActive = true;
Rs2Antiban.setTIMEOUT(Rs2Random.betweenInclusive(1, 4));

I’d much rather create an activity myself and use a function that only applies during the plugin’s runtime. I even considered the idea of "saving user configuration on startup > setting the optimal one for the plugin > restoring the user’s settings on shutdown," but just look at what Vox did to achieve that, it’s not a great experience, in my opinion.

Microbot/runelite-client/src/main/java/net/runelite/client/plugins/microbot/VoxPlugins/schedulable/example/SchedulableExampleScript.java

Lines 247 to 289 in 2239281

	private void setupAntibanTesting() {
	if (antibanInitialized) {
	return;
	}
	Microbot.log("Setting up antiban testing...");
	// Store original antiban settings
	antibanOriginalTakeMicroBreaks = Rs2AntibanSettings.takeMicroBreaks;
	antibanOriginalMicroBreakChance = Rs2AntibanSettings.microBreakChance;
	antibanOriginalMicroBreakDurationLow = Rs2AntibanSettings.microBreakDurationLow;
	antibanOriginalMicroBreakDurationHigh = Rs2AntibanSettings.microBreakDurationHigh;
	antibanOriginalActionCooldownActive = Rs2AntibanSettings.actionCooldownActive;
	antibanOriginalMoveMouseOffScreen = Rs2AntibanSettings.moveMouseOffScreen;
	// Apply test configuration
	if (config.enableMicroBreaks()) {
	Rs2AntibanSettings.takeMicroBreaks = true;
	Rs2AntibanSettings.microBreakChance = config.microBreakChancePercent() / 100.0;
	Rs2AntibanSettings.microBreakDurationLow = config.microBreakDurationMin();
	Rs2AntibanSettings.microBreakDurationHigh = config.microBreakDurationMax();
	Microbot.log("Micro breaks enabled - Chance: " + (config.microBreakChancePercent()) +
	"%, Duration: " + config.microBreakDurationMin() + "-" + config.microBreakDurationMax() + " minutes");
	}
	if (config.enableActionCooldowns()) {
	Rs2AntibanSettings.actionCooldownActive = true;
	Microbot.log("Action cooldowns enabled");
	}
	if (config.moveMouseOffScreen()) {
	Rs2AntibanSettings.moveMouseOffScreen = true;
	Microbot.log("Mouse off-screen movement enabled");
	}
	// Set antiban activity
	Rs2Antiban.setActivity(Activity.GENERAL_WOODCUTTING);
	Rs2Antiban.setActivityIntensity(ActivityIntensity.MODERATE);
	antibanInitialized = true;
	Microbot.log("Antiban testing setup complete");
	}

[Krulvis]

I’d much rather create an activity myself and use a function that only applies during the plugin’s runtime.

Does that mean you'd rather get rid of the user defined configurations altogether and instead focus on a per-plugin based antiban implementation? Or am I misinterpreting that?

[Bolado]

Does that mean you'd rather get rid of the user defined configurations altogether and instead focus on a per-plugin based antiban implementation? Or am I misinterpreting that?

Not that aggressive, no.

For example:

• Setting ActivityIntensity to EXTREME on a bossing/dangerous PvM plugin so if the user has natural mouse on, that at least the speed of the mouse movement doesn't impact the plugin very badly.
• Setting the timeout to stay within a specific range, ensuring that if the user has it enabled, the character won't idle for around 40 ticks after an action when running a plugin like Wintertodt.

If those settings are only applied during the plugin's runtime, it seems like there could be a balance between the user's preferences and the developer's decisions. Additionally, there could be an option in Antiban to enforce user's settings no matter what.