Suggestion Twig Protection, Tugboat Support, and Non-Ally Door Unlock Questions

Evil

Customer
I just got this plugin, very excited to have one that closes the loophole! I have a couple of questions though.

Is twig protected? If so, how can I set it where twig is vulnerable? Do I just add "twig" as a keyword?

Do tugboats have protection? If so, is there a way to disable that?

I'm just looking for clarification on the non-ally loophole blocker. It says "Disable Shield When A Non-Ally Unlocks A Door (prevents alt account exploit)". Does this mean when they interact with a door? Or just when they enter the code? Does the shield reactivate after a set time if this occurs or does it stay deactivated until the team logs back on and resets it?

Our current offline protection plugin makes it to where players who log off dead, or who are killed as sleepers, the base becomes unprotected as well. That would be nice to have. Basically it makes it to where if someone makes a mistake and sleeps on their roof or rage quits after they log off, they're base can still be raided.

Lastly, can I turn off the notifications that say the base is protected? I don't like there being any notification as people will just fly around and shoot at bases until one of them is "vulnerable" then raid it. It's very annoying.

Thanks a bunch!
 
Last edited:
Is twig protected? If so, how can I set it where twig is vulnerable? Do I just add "twig" as a keyword?
All building blocks are protected regardless of their grade (twig, wood, stone, etc.), You can't make twig unprotected by adding it as a keyword because "twig" is a building grade, not a prefab of its own. I'd need to add a new config setting specifically for building grades if you want that level of control. Please make a separate suggestion thread for it so I don't forget

Do tugboats have protection? If so, is there a way to disable that?
Tugboats aren't protected right now since they aren't considered "buildings" by the plugin. I'd need to add specific support for them

I'm just looking for clarification on the non-ally loophole blocker. It says "Disable Shield When A Non-Ally Unlocks A Door (prevents alt account exploit)". Does this mean when they interact with a door? Or just when they enter the code?
It's when a non-ally successfully enters the correct code on a code lock. Just interacting with the door or trying wrong codes won't disable the shield - they actually have to unlock it with the right code

Does the shield reactivate after a set time if this occurs or does it stay deactivated until the team logs back on and resets it?
When a non-ally unlocks a door, it records the current time as "last raid damage". The shield will automatically reactivate after the Do Not Enable Shield If Base Was Damaged Within Last X Seconds time has elapsed (default is 15 minutes), as long as all other conditions are still met (owners offline, etc.). Nobody needs to log back on to reset it - it's time-based

Our current offline protection plugin makes it to where players who log off dead, or who are killed as sleepers, the base becomes unprotected as well. That would be nice to have. Basically it makes it to where if someone makes a mistake and sleeps on their roof or rage quits after they log off, they're base can still be raided.
This plugin doesn't have this feature currently. It only checks if players are offline using the Playtime Tracker plugin's logout time - it doesn't track death status or sleeping body state at all. If you want this added, open a suggestion thread and I'll consider it for a future update (y)

Lastly, can I turn off the notifications that say the base is protected? I don't like there being any notification as people will just fly around and shoot at bases until one of them is "vulnerable" then raid it. It's very annoying.
Yep, just edit the lang file and set the message to an empty string "". That'll suppress the notifications completely
 
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