[Plug-in] Area Protection

    Area Protection Plug-in 1.0.7 released! (2018-08-06)


    The Java Area Protection plug-in is 'officially' released and available. Download link at the end


    Current features:

    • Compatible with the old Area Protection 3 LUA script: existing areas are kept as it can read the old data base directly.
    • 30 different permissions can be turned on / off independently.
    • Each area can have its own general permissions with any combination of those 30 permissions.
    • Each area can also assign specific permissions to each server group (overriding the area general permissions).
    • Each player can have his own specific permissions for each area (overriding the group permissions and the area general permissions).
    • Old LUA script Groups can be reused (once renamed), either with no modification or edited as preferred, as presets, i.e. sets of player (or group) permissions ready to use "with one click" but configurable if needed.
    • Selected non-admin players can be appointed by admins as "area managers", with full authority on area management.
    • Fully GUI operated.
    • A setting in the config file allows to choose whether to use the position of the event or the position of the player to determine whether an event can be permitted or not; the former is more precise, avoids any "reach-in effect", it is the default but it is slower, the latter induces a "reach-in effect" but it is (much?) faster.
    • Also runs in Single Player mode.
    • Makes several methods available to other plug-ins to query permissions and more (refer to the javadoc in the source).

    You want to try it?
    Adventurous server owners can download it, install it in their servers and try it. Please remember that it is new code: it has been tested by generous server owners, but it may have bugs and may crash!


    In any case, please read the manual: it is in the ZIP file and it can also be downloaded separately below; it is only 8 pages with a lot of images! Please read it!


    And this is the manual: AreaProtection_Manual_jpg.pdf please read it!


    Problems?
    If you try it and meet problems, please report the issue in this thread with enough information to reproduce it: if I cannot reproduce it, I cannot fix it!
    Thanks to anybody who already helped and anybody who will help polishing this plug-in! :thumbsup:


    Source code
    The source code for this plug-in is available on my github plug-in repository .


    P.S.: Did I say please read the manual? :rolleyes:


    Change log:
    1.0.7:
    - [new] Added a search box to area lists and to player lists: by entering at least 2 characters and pressing the Search icon, the list is shortened to the entries contains that sequence of characters
    - [new] Better explosion control (please read the relevant manual paragraph; feedback welcome)
    - [new] With blueprint events ("Create Blueprint" and "Place Blueprint") spanning several areas, to determine if the blueprint can be created/plced, the permissions of the areas are ANDed again
    - [fix] various bug fixes, including a nasty bug with permission ORing


    1.0.6: not distributed


    1.0.5:
    - [new] Added area extent editing while creating an area and after creation; all the 6 boundaries can be edited
    - [new] When within multiple areas, total permissions are united (OR) rather than intersected (AND)
    - [new] Added chat shortcuts for each main menu item (see manual for details)
    - [new] Admin privilege ON/OFF status shown in area status text of admins/managers
    - [new] Compensated for an oddity in event notification order from the plug-in API (see here for details)
    - [fix] Fixed exception on editing area manager list
    - [fix] Fixed exception on some combinations of list selection and scrolling


    1.0.4:
    - When a player is added to / removed from an area and he is within it, his permissions are updated immediately, without requiring any longer he exits and re-enter the area
    - Changed the collation used in SQL queries to be compatible with both SQLite and MySQL (technically: it now uses "ORDER BY LOWER(`Name`)" instead of the previous "ORDER BY `Name` COLLATE NOCASE)
    - It is now configurable whether the plug-in uses the event position or the player position to check for relevant permissions: the former is more precise, avoids any "reach-in effect" (and it is the default) but it is slower, the latter is less precise and introduces a "reach-in effect" but is much faster


    1.0.3: not distributed


    1.0.2:
    - fine tuned what the "Admin no Priv" flag turns off
    - "Go to area" now lists all areas rather than owned areas only
    - Adding/removing a player to/from an area is now immediately active, rather than after plug-in reload
    - Areas a flying player is in at spawning are now detected immediately (by-passing a RW bug)
    - Corrected a few bugs in group management


    1.0.1: Fixed bug in new area addition


    1.0.0: Initial release

    Nice one :)


    Just a small comment from my side, I don't think pressing Return to create an area is the right way to go. While creating areas I need to be able to communicate with the player I am creating the area for and as such I need to use the Return key to send chat messages (e.g. about the area name they want, or some special topology to be included, etc.)

    Quote from Minotorious

    Just a small comment from my side, I don't think pressing Return to create an area is the right way to go. While creating areas I need to be able to communicate with the player [...]

    Good point. This is pretty much true for any alpha-numeric character then. A Ctrl or SHIFT + RETURN would be handy, but they are a mess to detect.


    What about a high function key (F10 or F11 or F12) or INSERT?

    hmmm F keys are a bit of a nuisance to use as many overlays and other for instance recording programs use them e.g. steam screenshot is F12, GeForce Experience screenshot is Alt + F1, record Alt + F8, instant replay Alt + F10, etc. for other software


    I would recommend simply adding a create area button (maybe next to the area name textbox) clickable by mouse if that is something you would consider.

    Hi there ;D


    Run the plugin only on a server ? I have the plugin test in sp, as the world load is the game crashed.


    Quote from Minotorious


    I would recommend simply adding a create area button (maybe next to the area name textbox) clickable by mouse if that is something you would consider.

    Hmmm... I suggest you try and see for yourself which are the possible options.


    While you are defining the area extent, RW is working as usual (you can move around, interact with the environment, type in the chat, etc...) and, as with usual RW working, there is no mouse cursor to click with. Only keys can be used to steer the area creation process.


    I understand why the RETURN key might not be the best choice but, at that stage, a key to go on and a key to cancel have to be agreed upon anyway.

    @Bogus: I'll check that crash but, in principle, yes, the very concept of Area Protection only makes sense in a multiplayer environment (if there is only you, from whom are you protecting what?)


    EDIT: for the moment being, to overcome that crash, create a permissions/groups folder in your Single Player RW, similar to the MP server setup.


    It may crash further down, though, as the plug-in expects the MP server setup; However, if you want to try, I would be grateful...

    Quote from Miwarre

    Hmmm... I suggest you try and see for yourself which are the possible options.


    While you are defining the area extent, RW is working as usual (you can move around, interact with the environment, type in the chat, etc...) and, as with usual RW working, there is no mouse cursor to click with. Only keys can be used to steer the area creation process.


    I understand why the RETURN key might not be the best choice but, at that stage, a key to go on and a key to cancel have to be agreed upon anyway.

    Yes indeed thought of that but that comes with another important thing I wanted to ask @red51 about a key to temporarily show the cursor on the player's screen, many games have that option and I find it very convenient especially if I have clickable Gui elements permanently on the side of my screen.


    But you are correct for now there aren't that many options to make this happen other than to agree on a key or to make the key configurable in the settings file you have :)


    Maybe go with the ?// key next to RShift I think that is for sure not used for anything :D (kidding keep return for now and we can see later it is not that important for the time being:) )

    Quote from Miwarre

    @Bogus: I'll check that crash but, in principle, yes, the very concept of Area Protection only makes sense in a multiplayer environment (if there is only you, from whom are you protecting what?)


    EDIT: for the moment being, to overcome that crash, create a permissions/groups folder in your Single Player RW, similar to the MP server setup.


    It may crash further down, though, as the plug-in expects the MP server setup; However, if you want to try, I would be grateful...

    I can test the plugin in SP mode and prepare a world before uploading it to a server.;D

    Quote from Minotorious

    But you are correct for now there aren't that many options to make this happen other than to agree on a key or to make the key configurable in the settings file you have :)


    Maybe go with the ?// key next to RShift I think that is for sure not used for anything :D (kidding keep return for now and we can see later it is not that important for the time being:) )

    While configurable keys may sound nice, I suspect they would be more a nuisance than other; in addition to the complexities of recognising them in config files (huuuge switches if we go textual, as in "create_key=KEY_KANJI" (I like that key =O !) ) and the ease for errors both with textual and numeric representations ("create_key=148"), two practical problems arise:


    1) dynamically constructing the key name to output it in the modal window while creating the area extent would be far from easy


    2) if someone is admin (maybe unlikely) or area manager (much more likely) in two different servers with two different key configurations, a lot of confusion would be ensured.


    I prefer to find a suitable key and stick with it. I still believe that the INSERT key is a reasonable choice: not used by anything else (as far as I know), unlikely to be hit by accident and still vaguely mnemonic (to create => add => insert a new area...).


    In case, I prefer to change it as soon as possible, before habits build up.

    The only thing I am not sure about with Insert is if it can alter input outside of the game after being pressed. Since insert usually (in text editors etc.) alters input from placing a character to replacing a character. It is worth a try anyway :)

    Quote from Minotorious

    The only thing I am not sure about with Insert is if it can alter input outside of the game after being pressed. Since insert usually (in text editors etc.) alters input from placing a character to replacing a character. It is worth a try anyway :)

    Good point, but I suspect it does not.


    It may depend on the OS, but I am pretty sure the key is a local event and not a system event in both Linux and Windows (only the active window will receive it).


    As OSX is ultimately a Unix system, it should also work the same (unless they screwed it up in more ways than I know...)

    Great work, this looks very promising! :thumbup: If there are no serious issues with the plugin, the final release could serve as a replacement for the old Lua AP script, so we can eventually get rid of the Lua API :whistling:

    Quote from Minotorious

    Nice one :)


    Just a small comment from my side, I don't think pressing Return to create an area is the right way to go.

    Well, apparently, this is not a concern: even while creating a new area, once you enter the chat with [T], you can press [Return] at the end of a chat line and it will not affect the area creation process; another [Return], 'outside' of the chat, is needed for the area creation process to go on.


    So, I will not change this. Comments?
    ____________________


    @Bogus: I have run a test session in Single Player and, with a simple change, the plug-in runs in SP too. I'll upload the change to github soon; I believe we can consider this solved... ^^

    Quote from Miwarre

    Well, apparently, this is not a concern: even while creating a new area, once you enter the chat with [T], you can press [Return] at the end of a chat line and it will not affect the area creation process; another [Return], 'outside' of the chat, is needed for the area creation process to go on.


    So, I will not change this. Comments?

    oh ok this is unexpected :/ So opening the chat ignores all listeners for key input? @red51 can you confirm if this is true?

    Version 0.12.0, a.k.a. Release Candidate 2 is available from the github repository pointed to in the top post.


    Changes:


    *) Fixed running in Single Player ( @Bogus, this is for you and thanks for the report!)
    *) Fixed a pair of buglets in the GUI
    *) Adjusted access levels of classes and methods: other plug-ins can access Are Protection public methods to check for permissions and other (refer to the javadoc in the source for this).

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!

Create Account Login