Suggestion Does This Stop the Alt Account Exploit

Return to plugin
PPlank

PPlank

We have used several Raid Protection plugins, but the exploit has always been the same and has never been fixed by the devs.

How it works. An alt account logs in, builds a base and logs out. Real account logs in and lets themselves in through the codelocked door. They are not allies, team mates or friends with the original alt account. Their base is now impervious to raids while they're logged in.

Does this plugin address that scenario and stop players from doing this? I imagine it could be done by checking the codelock for usage if that were possible. Thanks. :)
 
Recent First Highest Voted
Not gonna lie, it took me a minute to fully understand the loophole you meant 😅

So currently the shield activates purely based on whether the owner, tc auth, team, friends, or clan members are all offline (after the configured delay). If a non-ally is inside even if they know the door code it doesn't deactivate the shield

So in the exact case you described, yeah, the base would still be protected while that outsider is inside

If we want to patch that loophole, I could definitely add some optional safeguards, like:
  • If a non-ally is inside the same tc privilege area, suspend the shield
  • If a non-ally opens a door or interacts with anything inside, suspend the shield

Either rule would make the base raidable again as soon as a non-ally is actively using it

No need to track who knows the code specifically, those presence/interaction rules should be clean enough. Let me know if you'd like that added!
 
Upvote 0 Downvote
You must log in or register to reply here.
Back
Top
Chat commands start with a /, while console commands can be entered directly in the F1 console or server console. Use find <keyword> in console to search for available commands related to the plugin. Parameters in < > are required, while [ ] are optional.
This plugin uses Oxide's permission system. Grant or revoke permissions using oxide.grant and oxide.revoke. You can assign them to individual players or groups using their Steam id or group name.
Settings are stored in the config file found under the config/ directory. You can edit this file manually, then reload the plugin to apply your changes.
Persistent data is saved in the data/ directory. This includes things like saved settings, usage stats, or player progress depending on the plugin. Deleting a data file will reset stored progress or customizations.
Language files are located in the lang/ folder. To translate messages, copy the en.json file into your target language folder (e.g. fr, de) and edit the values. Reload the plugin after changes to apply new messages.
This section lists public methods exposed by the plugin for use in other plugins. You can call these via the CallHook method. Ensure the plugin is loaded before calling its API to avoid null reference errors.
These are custom hooks that other plugins can listen for. Simply define a method with the same name and expected parameters in your plugin to handle the event. Hooks are triggered at key moments and are useful for extending or reacting to plugin behavior.
These hooks are injected into the game's code using Harmony. They let the plugin run code at key points in the game's internal logic. You can return values to block or modify behavior. Use with caution — these are powerful and can affect core mechanics.
Cart

Cart

Total -