[Plug-in] Area Protection

    Quote from Miwarre

    I was expecting comments on this point, but none was made so far. The current solution allows to reduce the load on the server significantly, can you elaborate why it is such a big problem and why for creative servers in particular?

    I understand the reducing load problem as with your Area Attribute solution you save a lot of computations from iterating over all areas as red51 told me a few days back. But is it so bad to iterate over 1000-5000 areas? Java is slow but it is not thaaat slow :D


    I said for creative servers mostly as for PvP servers destroying other people's stuff is part of the game so even if they use some AP settings most of it should be fair game to destroy from inside or outside the area.


    Now it is a big problem as when I give a player an area 200x200 blocks they expect it to not be able to be griefed in its whole not have a small 2-3 block perimeter where it can be dug or their builds destroyed :/ Also when I want to protect roads or portals I want to be able to have small areas around them to allow for the rest of the space for player areas but such small areas with the reach-in issue would lead to all our roads and portals destroyed by a griefer :/


    Edit PS: our server is quite big and we constantly only have about 2000 areas as we remove old areas after 30-40 days of inactivity

    Quote from Minotorious

    But is it so bad to iterate over 1000-5000 areas? Java is slow but it is not thaaat slow

    Well, Java is not particularly slow (and anyway faster than LUA!).


    Anyway, iterating over 5000 areas in itself, should only take a few milliseconds. The point is that, for each area, it has to be computed if the point when the action happens is within the area or without (which implies up to 12 comparisons); then for each area the action is within there are 3 Map lookups, 2 player attribute lookups, several tests and various "logic sugar".


    This for each pickaxe stroke (or similar repetitive action): if a dozen players are digging at the same time, I expect the server latency to increase somewhat and the player starting to notice some (additional) lagging.


    In the current implementation, all the above computation is reduced to just one single bitwise AND!


    However, the code for the above, real action point, implementation is already there (it is used to check for explosions; for the moment being disregard that explosion events have some problem); making a test version where it is used for all events should not be very complex and then it can be tested "on the field" if the overload is acceptable.

    Quote from Miwarre

    Well, Java is not particularly slow (and anyway faster than LUA!).

    I meant it in the sense that Java is much slower than C++ for example :P

    Quote from Miwarre

    The point is that, for each area, it has to be computed if the point when the action happens is within the area or without (which implies up to 12 comparisons); then for each area the action is within there are 3 Map lookups, 2 player attribute lookups, several tests and various "logic sugar".

    Quote from Miwarre

    In the current implementation, all the above computation is reduced to just one single bitwise AND!

    I know that it will be more computationally expensive to do the area checking but for us and I presume quite a few others the reach in issue is something we cannot accept in an area protection plugin as it defies its purpose, it does not protect our whole areas :/


    We can at least try it get on a server (or a steam p2p game) create 1000 tiny areas everywhere and then start mining, we could gather 10-12 people for testing at a convenient (evening for europe lunch time for the US would probably work the best I think) time I think :)

    this is an issue as creative and survival/pve servers have folks that build rt to the edge of the claim. I understand and agree with minotorious here. I was going to bring it up but he did a much better job then I would have done. :)


    If you need an extra body and I am available, I am willing to help test things. I really want to see how a claim inside a claim works as I only have the option for a private network. I need to know if I need to remove some areas or not.

    Version 1.0.4 released!


    Version 1.0.4 is available from the thread top post.


    1.0.4 Change log:


    - 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-enters 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


    - fixed a bug with player lists


    Enjoy!

    So, it may or may not have been asked before, but because I have an issue with actually trawling through loads of bumph only to find my particular problem has not been addressed I will ask my question regardless of fucking repetition,


    I am currently using Reds Lua area protection script if I use yours will I need to redefine all the areas.. If I do, why the f**k can't you take the settings from the Lua script into the plugin that I have orgasmic delight in applying, only if, I can convert to your plugin without a balls ache shitload of trash to do


    PS..... I AM NOT A PROGRAMMER JUST A NON GEEK TRYING TO HAVE FUN.....oh and I might be drinking whisky (spelt the correct way) ....


    :thumbup:

    I think he is asking for this bit @Miwarre

    Quote from Miwarre

    Compatible with the old Area Protection 3 LUA script: existing areas are kept as it can read the old data base directly.

    @Smudger This is literally the first line in the features list in the first post of the thread and written in bold letters. How on earth did you not see it? :/

    and area protection 3 is compatible with red's area protection they are both lua and I think area protection 3 is the upgrade to reds area protection. so it should work on both. But don't hold me to that, I am not a programmer either. :)

    OK! It appears that things are working correctly with my MySql world! But....


    All of the areas converted from my LUA DB have players like "<playername> (Custom)" instead of getting one of the presets (owner, friend, etc.). I noticed that the original ".group" files were named with "title case" (Owner, Friend, etc.) instead of the lower case of the .preset files (owner, friend, etc.). Is this why it did not assign the players defined in the LUA areas to one of the .presets? Is there some way to get the conversion to assign the players in one of the old .groups to one of the new .presets instead of making the "(Custom)"?


    It also appears that when editing an existing player, there is no option to select a preset. Only check or uncheck permissions. It would be helpful if you want to change a player from one preset to another or change a "custom" to a preset.


    Something I noticed right off is that it is difficult to add a player to an area for our world as we have several thousand players and it is slow to scroll through the entire list to find the one you want. Can a search and/or filter or a "find as you type" feature be done? This would also be needed for the areas list as we have several hundred areas.


    Looking good so far! Going to try some more testing performance wise regarding the "event position" and "reach in" issue.

    Hmmmm. I am getting the below error when attempting to select a playername to add to an area (happening with most selections, but not all)... I am not seeing any pattern as yet as to why some playernames are working and some (most) are not.


    PLUGIN EXCEPTION (org.miwarre.AreaProtection, 1.0.4, Maurizio M. Gavioli aka Miwarre) ---->
    java.lang.ArrayIndexOutOfBoundsException: -10
    at org.miwarre.ap.gui.GuiScrollList.getChildFromId(GuiScrollList.java:290)
    at org.miwarre.ap.gui.GuiScrollList.selectItem(GuiScrollList.java:135)
    at org.miwarre.ap.GuiTwoListsSelector$DlgHandler.onCall(GuiTwoListsSelector.java:99)
    at org.miwarre.ap.gui.GuiModalWindow.onClick(GuiModalWindow.java:155)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at pluginapi.PluginEventHandler.triggerEvent(SourceFile:206)
    at G.c.a(SourceFile:2908)
    at G.c.messageReceived(SourceFile:189)
    at de.jiw.network.server.core.ServerTcpChannel.onMessageReceived(ServerTcpChannel.java:97)
    at de.jiw.network.server.core.AbstractServerChannel.dispatchTCP(AbstractServerChannel.java:62)
    at de.jiw.network.server.session.TcpSessionHandler.channelRead0(TcpSessionHandler.java:79)
    at de.jiw.network.server.session.TcpSessionHandler.channelRead0(TcpSessionHandler.java:15)
    at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:105)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
    at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
    at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:310)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:284)
    at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
    at io.netty.channel.AbstractChannelHandlerContext.access$600(AbstractChannelHandlerContext.java:38)
    at io.netty.channel.AbstractChannelHandlerContext$7.run(AbstractChannelHandlerContext.java:353)
    at io.netty.util.concurrent.DefaultEventExecutor.run(DefaultEventExecutor.java:66)
    at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:858)
    at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:138)
    at java.lang.Thread.run(Unknown Source)

    Ok..... Testing is proceeding. I want to give you a few more feedback items to ponder:


    - would it be possible to allow all of the old LUA script text chat commands or at least some (/showareainfo, /arealist, /addplayertoarea /removeplayerfromarea, etc.)? Maybe with some shorter commands (/info, /addplayer, /removeplayer, etc.)?


    - It appears that chest and blueprint protection works properly even when trying to "reach in". Furnace protection appears to work properly as far as either destroying them or operating them, but it appears anyone (from either in or out of the area) can take/put ore and ingots. This is no worse however than the current LUA script.


    - Minor nit and not everyone may agree with me, but the "Admin priv: ON/OFF" item seems backwards to me. IMO that line should display what it is currently set to (either ON or OFF) and toggle to the other. It appears that it now displays what it would be set to if you click on it. Also minor, but think it would look better as "Admin Priv:" versus "Admin priv:" (Priv capitalized). Also a chat command to toggle this would be handy (/adminpriv). Also a display of the current setting on-screen for admins (maybe under the area name).


    A quicker way to navigate and find player and/or area names in the lists is by far the more important thing that I feel needs fixing.


    More feedback to come :)

    Quote from Jon_miner

    OK! It appears that things are working correctly with my MySql world!

    :thumbup:

    Quote from Jon_miner

    All of the areas converted from my LUA DB have players like "<playername> (Custom)" instead of getting one of the presets (owner, friend, etc.). I noticed that the original ".group" files were named with "title case" (Owner, Friend, etc.) instead of the lower case of the .preset files (owner, friend, etc.). Is this why it did not assign the players defined in the LUA areas to one of the .presets? Is there some way to get the conversion to assign the players in one of the old .groups to one of the new .presets instead of making the "(Custom)"?

    Well, first of all, naming of files is totally irrelevant; you could name them "file01.preset", File02.preset" " FILE03.preset"... and it would (should?) not change anything. What matter are:


    1) The permissions turned on in each preset: if the permissions of a player match those in a preset, the preset name is shown near the player name. If the permissions of a player for an area do not match the permissions of any preset, then " (Custom)" is shown.


    2) The preset name is declared in the "GroupName=" line of it.


    Maybe this might already allow you to diagnose why all these players are "Custom" in your particular case. It is also possible that some more set-up might be necessary to convert not only the actual permissions (they should already be correct) but also the naming.

    Quote from Jon_miner

    It also appears that when editing an existing player, there is no option to select a preset. Only check or uncheck permissions. It would be helpful if you want to change a player from one preset to another or change a "custom" to a preset.

    Nice suggestion. I'll add the the list.

    Quote from Jon_miner

    Something I noticed right off is that it is difficult to add a player to an area for our world as we have several thousand players and it is slow to scroll through the entire list to find the one you want. Can a search and/or filter or a "find as you type" feature be done? This would also be needed for the areas list as we have several hundred areas.

    A search box option is already in the to do list. It should be there soon ( :whistling: ).


    I'll try to understand that error about player selection.


    Quote from Jon_miner

    ould it be possible to allow all of the old LUA script text chat commands or at least some (/showareainfo, /arealist, /addplayertoarea /removeplayerfromarea, etc.)? Maybe with some shorter commands (/info, /addplayer, /removeplayer, etc.)?

    Well, I understand you experienced admins are accustomed to those commands, but I am against them, for several reasons:


    1) all commands which require a name (of an area or of a player) will have problems if the name contains spaces (and possibly non-ASCII characters which may be difficult to type with the keyboard available to the admin).
    Selecting from a list does not have this problem and also avoids any typo (I have a old LUA DB kindly provided by @sharkbitefischer with area names like "Meow and Traps Palace (meowxdrawr and TrapLord)" or "Shazza & pocket (ShazzaGalore & pocketdeath1)": not the easiest string to type correctly).
    Once the search box implemented, list selection should be not significantly slower than a chat command, taking the time lost in typos into account.


    2) Several of those commands have other kind of problems: chat commands like "/info" are too generic: any plug-in may define such a generic string! So, the command has to be "/ap info <area_name>" in the best case. "/ap arealist" may list hundreds of items, barely useful; and so on.


    3) I do not like chat commands!


    So, for the moment being, the answer is "I understand, but no" :evil: .



    Quote from Jon_miner

    - It appears that chest and blueprint protection works properly even when trying to "reach in". Furnace protection appears to work properly as far as either destroying them or operating them, but it appears anyone (from either in or out of the area) can take/put ore and ingots. This is no worse however than the current LUA script.

    I'll check it, but I suspect the plug-in is not notified of the ingot movement by RW, in which case, there is nothing I can about it, at least with the current plug-in API. I'll let you know the outcome.

    Quote from Jon_miner

    - Minor nit and not everyone may agree with me, but the "Admin priv: ON/OFF" item seems backwards to me. IMO that line should display what it is currently set to (either ON or OFF) and toggle to the other. It appears that it now displays what it would be set to if you click on it. Also minor, but think it would look better as "Admin Priv:" versus "Admin priv:" (Priv capitalized). Also a chat command to toggle this would be handy (/adminpriv). Also a display of the current setting on-screen for admins (maybe under the area name).

    Hmmm... strange you find this item backward and not the very first one, which uses the same strategy "Hide areas" when they are shown and "Show areas" when they are hidden). Would "Turn admin priv. ON / OFF" clearer?


    As my own language (Italian) only capitalises the first letter of a sentence in whatever context, I never understood the "Title Capitalisation" of English. But feel free to suggest any linguistic improvement you may prefer: English is not my native language.


    Again, not "/adminpriv" but "/ap adminpriv"... Admin setting on screen added to the to do list...

    Quote from Jon_miner

    A quicker way to navigate and find player and/or area names in the lists is by far the more important thing that I feel needs fixing.

    As I said, already in the to do list (actually it is the second item, after the ability to change the extent of an exiting area).

    when I have turned admin priv off and I am in an area I do not have privileges to, I can still add or delete players and managers to the area and edit the area's permissions as well as player permissions without turning on admin priv, it seems.


    and admin priv shows on when it is off and off when it is on :)

    Quote from Miwarre

    Well, I understand you experienced admins are accustomed to those commands, but I am against them, for several reasons:

    Ok, I understand the not using them for commands that require a name (ie /addplayertoarea, etc.) and agree (provided the search player/area lists is implemented). I also understand making too generic a command (like /info). Would a compromise be possible (I like command line myself :) ) and provide the commands:


    /ap showareas (to stay consistent with the next ones)
    /ap hideareas (to stay consistent with the next ones)
    /ap areainfo (no input required)
    /ap arealist (no input required, with it ordered by order of creation, this is handy for checking out newly created areas)
    /ap adminpriv (as you mentioned above)


    Quote from Miwarre

    1) The permissions turned on in each preset: if the permissions of a player match those in a preset, the preset name is shown near the player name. If the permissions of a player for an area do not match the permissions of any preset, then " (Custom)" is shown.

    Ok, I think I understand how this import/conversion is working now. I think I can setup the original .group files to match what is in the .presets and get the import/conversion to do what I think we need. Will check it out.


    Quote from Miwarre

    Hmmm... strange you find this item backward and not the very first one, which uses the same strategy "Hide areas" when they are shown and "Show areas" when they are hidden). Would "Turn admin priv. ON / OFF" clearer?

    I see your point here... Maybe if you make the clickable line say either "Turn Admin Priv ON" or "Turn Admin Priv OFF" (and yes I prefer the capitalization shown here :) ). It would be nice too if, for admins, the current state of "Admin Priv" be displayed on the screen just under the area name (something like "Admin Priv: ON" or "Admin Priv: OFF) and this would be a status only not clickable.



    Something I noticed when trying to test out how nested areas work... When in a nest area (ie: BigArea|NestedArea), and you go to edit while in that nested area, the area that is brought up to edit is the "BigArea". How would one edit the "NestedArea"?


    I am not sure I understand how nested/intersecting area permissions work yet, but I don't think it works the way I believe they would be used and I want to check it out, but can't edit the areas individually as I'd like to test it.

    Quote from sharkbitefischer

    when I have turned admin priv off and I am in an area I do not have privileges to, I can still add or delete players and managers to the area and edit the area's permissions as well as player permissions without turning on admin priv, it seems.


    and admin priv shows on when it is off and off when it is on

    I think you are saying the same thing that I was saying above... The clickable line in the /ap menu should indicate what clicking on it will do, ie: "Turn Admin Priv ON" or "Turn Admin Priv OFF". The way it currently displays, it appears to show the current status of Admin Priv setting (backwards). I also think that what Admin Priv is currently set to should be displayed below the area name on the main screen when in an area (for admins).

    Another quick feedback...


    It appears when creating an area the N-S sides of the area appear to be be created shifted one block to the South compared to the area drawn out. The E-W sides appear to be created as drawn out.


    I think this has been discussed already, but it would be nice when creating an area to be able to adjust/set the N-S-E-W sides of the area as well as the TOP-BOTTOM. This should also be available when editing an existing area (to change it's size) not just when creating.

Participate now!

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

Create Account Login