[Plug-in] Area Protection

  • I'm having a slight issue, I appologize if this has been adressed. I'm sure I'm doing everything properly, but maybe I'm not, It seems after adding a player to a claim as owner he can still not build/destroy anything in the claim. I'm certain I'm the correct player to the correct claim with the correct owner permission. I've tried him in the admin permission as well. I haven't tried the other groups quite yet as he had to get off. i'm using 1.0.1.

  • @mickeyjay88: Can you confirm that the permissions for that player for that area are all turned on? To check them:


    - go to that area (to speed up area selection)
    - "/ap" in the chat, then select "Edit area"
    - in the area properties, click "Edit players"
    - in the player list, select the player and then "Edit" (if the player does not appear in the list, he has not been added at all to that area)
    - check the permissions are all turned on.


    If they are not on, you probably skipped some step while adding the player.


    If they ARE on and the player still cannot edit the area contents, then something is wrong and we will need more analysis...

  • Yes everything excluding explosions is selected including owner. And no worries I'm interested in getting this sorted out whatever you need I can get you,

  • Wanted to ask for myself and my players, does this java version prevent tnt AND BPs from destroying blocks and terrain from within a claim?

    "The past is history, the future a mystery, but today is a gift, which is why we call it the Present."

  • are admin not affected by the permissions set for the area? I set an area and did not add any player to it or area manager and I was still able to dig ground and set objects.

    An easier way to turn admins (and area managers) into 'regular' area visitors (and back) is the "Admin priv. OFF" item of the main AP menu. This has the bonus that the flag is flipped immediately, without messing with the plug-in config file and with plug-in restarting or (even worse) server restarting.


    However, I noticed that currently this flag (however it is flipped) is too powerful as it removes too many admin abilities (like area editing); I am fine tuning it and it will improve in the next AP version.


    Wanted to ask for myself and my players, does this java version prevent tnt AND BPs from destroying blocks and terrain from within a claim?

    This is the idea. Protection from BP should work correctly (as far as I could test it).


    Protection from explosion should also work correctly for the most common case(s); according red51 in the current 0.9.3.3 RW version, with explosions there might be ways around this protection but I didn't find them. Anyway, the next version of RW should improve this point.


    Yes everything excluding explosions is selected including owner. And no worries I'm interested in getting this sorted out whatever you need I can get you,

    Hmmm... I run some additional tests and this works correctly here.


    One detail I noticed is that, if the player happens to be inside the area when (s)he is made owner of it, (s)he has to exit the area and then re-enter it for the new permission to take effect. I'll try to smooth this detail out in the next plug-in version.

  • ok tnt is not protected from. I managed to get the admin privileges turned off like you said. I tested just about everything and it all checks out except tnt. It will still blow holes in your buildings no matter what setting I used.


    Also when adding or removing a player from an area, it is requiring a server restart before changes are registered and work.


    also when logging in, even if you know you are in an area, it acts like there is no area until you move in any direction. example if I am on a claim that I have no permissions for and login, before I move I can dig holes in the ground at least and maybe do more then that until I move just a little bit then the area sign pops on and I am restricted from doing anything again.


    I must say it is nice to have protection from others blueprinting your stuff unless you allow it.


    Another little request. Could you make the lists able to be scrolled by hovering over it and using the mouse wheel? It would make paging through a list of 2000 names a lot quicker and not wear out our mouse buttons by clicking on the down triangle as well as not give us carpel tunnel ? :) or maybe even the ability to use pgup and pgdwn to scroll through the lists would be sufficient.

  • ok tnt is not protected from. I managed to get the admin privileges turned off like you said. I tested just about everything and it all checks out except tnt. It will still blow holes in your buildings no matter what setting I used.

    I tested dropping a light TNT tube and it is blocked. How did you test it?

    Also when adding or removing a player from an area, it is requiring a server restart before changes are registered and work.

    Well, a server restart seems to me rather extreme; possibly, as I said in a previous post, it may be necessary for the player to get out of the area and back in, if he was within the area at the moment of the change. I am fixing this, though.

    also when logging in, even if you know you are in an area, it acts like there is no area until you move in any direction. example if I am on a claim that I have no permissions for and login, before I move I can dig holes in the ground at least and maybe do more then that until I move just a little bit then the area sign pops on and I am restricted from doing anything again.

    Does this happen in SP or MP? In SP it might be kind of expected until the player connect event if fixed. In MP, this does not match my findings (I'll redo my tests to be sure, but I tested this point many times).

    Another little request. Could you make the lists able to be scrolled by hovering over it and using the mouse wheel? It would make paging through a list of 2000 names a lot quicker and not wear out our mouse buttons by clicking on the down triangle as well as not give us carpel tunnel ? :) or maybe even the ability to use pgup and pgdwn to scroll through the lists would be sufficient.

    Neither hovering nor mouse wheel movements are sent to the plug-ins, as far as I know, so unfortunately this is not possible given the current API. [PgUp] and [PgDn] might be possible, if there is only one scroll list in the dialogue box; but if there are more than one scroll list -- as in the player + preset double list -- the dialogue box handler would not know to which of them to apply the [PgUp] and [PgDn] keys. I definitely plan to implement a search box, though; this should speed up things a lot.

  • for the tnt test I placed a stick of tnt on a building and lit it. I tried all versions of the settings and the tnt set and lit all the time. I will retest to confirm.


    on the restart for activating the addition of a player, I did try moving in and out of the area to add myself to the area and I always had to restart the server to have the permissions activated.


    I have been working on a dedicated server on my internal network in multi player. I use 2 comps, 1 as server, 1 as client, to mimic my public server for testing purposes. So the occurrence of logging into a multiplayer server and the area protection not being shown until you move is what is happening. also during this time griefing can be done. As long as I don't move I can I can atleast dig dirt, I know. I will test on other things like laying block and such.


    on the scrolling of the lists could you make the lists scroll by holding the mouse button down on the arrow rather then clicking it from page to page? but a search function added to the lists would be great.


  • also when logging in, even if you know you are in an area, it acts like there is no area until you move in any direction. example if I am on a claim that I have no permissions for and login, before I move I can dig holes in the ground at least and maybe do more then that until I move just a little bit then the area sign pops on and I am restricted from doing anything again.

    Ok, I re-checked this and, in fact, the plug-in is not notified of the area the player pops into, if the player is flying. If the player is NOT flying, the plug-in is notified by RW and things work correctly since the beginning. I'll alert red51 and I'll try some work-around for the time being.

  • ok tnt is placable on block and pnb constructions and is lightable and blows things up. Confermed


    on login unprotected bug, you can place block constructions and objects as long as you don't move, and after moving, the area names appears and permissions return to normal. blueprints are not affected by this bug though. BPs will not create in the protected area. I didn't try setting a blueprint before moving after login. confirmed, only happens in fly mode.

  • I apologize if I missed the discussion about this subject, but...


    I am trying this plugin on a copy of my online multiplayer server (copy as a local dedicated server) which is using a MySql Database (not a SqLite DB). It appeared to "import" all of the areas from the old LUA script DB properly. I had copied all of the old .group files to the plugin presets folder and renamed as .preset (replacing the supplied ones). However several things do not seem right.


    - All of the Players listed in the imported areas are listed as "null (Admin), null (Friend), etc."
    - No "Owners" are showing in the imported areas. They appear to be marked as "Admin" (hard to tell as all player names are "null")
    - When I attempt to create a new area and add players, no players are listed at all.
    - When I attempt to add a group to a created area with "Friend" preset, the group gets added as "null (Friend)"


    Does this plugin only work with a SqLite database and not when using a MySql database?

  • I tried what you suggested and it seems that walking in and out doesn't work but relogging does seem to do the trick.

    Yes, I reviewed the matter and an update will be posted this evening/night (Central Europe time).

    I am trying this plugin on a copy of my online multiplayer server (copy as a local dedicated server) which is using a MySql Database (not a SqLite DB). It appeared to "import" all of the areas from the old LUA script DB properly. I had copied all of the old .group files to the plugin presets folder and renamed as .preset (replacing the supplied ones).

    Ok, this is correct for on-going AP running. But it is not correct for initial old data importing.


    As the manual says, you have to move or copy the whole folder of the old AP LUA script as it is with all its sub-folders into the new plug-in folder (refer to the manual for an illustration of the resulting folder structure) before the first run of the plug-in.


    During the import, the plug-in looks in the copied DB and in the copied Groups for data it needs. Once the data imported, you may remove/delete the copied old LUA folders, as they are no longer needed.

    However several things do not seem right.


    - All of the Players listed in the imported areas are listed as "null (Admin), null (Friend), etc."
    - No "Owners" are showing in the imported areas. They appear to be marked as "Admin" (hard to tell as all player names are "null")
    - When I attempt to create a new area and add players, no players are listed at all.
    - When I attempt to add a group to a created area with "Friend" preset, the group gets added as "null (Friend)"

    The 1st point is because the player id's listed in the old LUA DB are not defined in your local world DB; so the importing process cannot attach a name to them.
    The 2nd point is because there is no AreaProtection/Groups/owner.group in your ap plug-in folder where the old definition of owner can be looked for.
    The 3rd point is because there are no other players defined in the local world DB?
    The 4th point I do not understand; are those groups defined in your local server?

    Does this plugin only work with a SqLite database and not when using a MySql database?

    I cannot see any reason why it should not work with either SQL flavour, as this only affects the world DB; the plug-in own DB is defined internally to be SQLite and the world DB is accessed through the defined API and should then be independent from the actual DB implementation.

  • As the manual says, you have to move or copy the whole folder of the old AP LUA script as it is with all its sub-folders into the new plug-in folder (refer to the manual for an illustration of the resulting folder structure) before the first run of the plug-in.

    I did do this... But will try again without pre-copying the .group files to the presets folder.


    Not sure what you mean by "....the player id's listed in the old LUA DB are not defined in your local world DB..." or "... there are no other players defined in the local world DB". The player ID's and their associated names and UID's are defined in the "World DB" (MySql)?



    I am going to try the import/conversion again. Would love to discuss this with you real time in Discord if you have the time.

  • The 1st point is because the player id's listed in the old LUA DB are not defined in your local world DB; so the importing process cannot attach a name to them.
    The 2nd point is because there is no AreaProtection/Groups/owner.group in your ap plug-in folder where the old definition of owner can be looked for.
    The 3rd point is because there are no other players defined in the local world DB?
    The 4th point I do not understand; are those groups defined in your local server?


    Regarding #1... the player id's in the old LUA DB ARE defined in the world DB along with their names and UID's (Player Table).
    Regarding #2... OK, trying again without manually copying the old .group files to the presets folder and renaming
    Regarding #3... There are many players defined in the World DB (Player Table)
    Regarding #4... I tried to add a group (permission group) as "Friend" to a new created area and it got added but as "null (Friend)" even though picked from the list of available groups

  • Ok.... Tried the "import/conversion" again with the entire Area Protection folder/sub in the ap folder and did not copy .group files to the presets folder and rename to .presets. And this is what I see for the Players in an area.


    null (Custom)
    null (Custom)
    null (Custom)
    null (Custom)
    null (Custom)
    null (Custom)

  • @Jon_miner: I understand that you are working on a copy from a (rented?) on-line server with MySQL World DB into a local dedicated server also using MySQL World DB. Correct?


    If this is correct, then how did you move the world DB? I might be wildly mistaken, but simply copying the <WorldName>.db file (if it exists) from the on-line server to the local server is not going to work, as both use MySQL DB, and MySQL servers usually store the DB in a specific directory, not easily accessible.


    If, on your on-line server, you have access to either PhpMyAdmin or the mysql client programme, then you could generate a textual DB dump to download and import into your local MySQL server. I really believe that otherwise no player (except perhaps yourself) is defined in your local MySQL World DB.


    About the group names, you are correct: there is a bug in the list display; it will be fixed in the next release in a few hours. Thanks for the report!

  • There is no <worldname>.db file at all. I indeed use PhpMyAdmin and do a DB dump and then import into my local MySql server. This all works fine with the old LUA AP script and the MySql World DB is indeed populated with all player id, name, UID, etc. All the areas display (/showareainfo) all of the player names when using the LUA AP script. After installing the AP plugin and letting the "Import" of the script DB happen, no names are getting "resolved" at all. "nulls (Custom)" are displayed in existing areas (that did get imported) and when trying to add players to new areas there are no player names listed at all (there are some 4000 actually in the World MySql DB).

  • Hmm, this sounds weird. It looks like the MySQL DB is defined differently than the SQLite DB. Would you mind executing this query on your local MySQL server and see if it works as one would expect:


    "SELECT `ID`,`Name` FROM `Player` ORDER BY `Name` COLLATE NOCASE"


    (this is one of the queries the plug-in is executing on the World DB)

Participate now!

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