Posts by Jon_miner

Quote from sharkbitefischer

we still need a way to edit secondary areas while within them. A go to area list button would be very handy.

If you go outside all areas to an "open" area and do a "/ap edit" or do "/ap" and click "edit area" it will present you with a list of areas to find the intersecting one that you want to edit... A little "awkward" but works.

Quote from Miwarre

Very probably this is due to the same API bug about 1 block off coordinate conversions.

I'm not sure the "BP right to the edge" is the same "negative coord shift" issue as the "BP to the edge" issue happens whether the coord you are at is negative or not.

Quote from sharkbitefischer

The fuse burns but no boom and you can't remove the tnt after it is lit. F7 removal tools will not remove the tnt either.

To start, I was able to give a player the right to explode dynamite in an area. As far as removing an un-exploded dynamite, I was able to remove as a server admin with or without F7, but it didn't show as being gone until a re-log. Think this is a general game issue for @red51

Didn't get around to testing things until Monday morning...

Quote from Miwarre

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

This seems to work well. I noticed that newly created areas are always at the top of the list (not sorted alphabetically) until the server is restarted. Not a big deal, but can they be sorted right away?

Quote from Miwarre

- [new] Better explosion control (please read the relevant manual paragraph; feedback welcome)

This appears to work. Did not find anything about it in the manual? There is a little weirdness with removing dynamite that has been set but doesn't go off even by server admin?

Quote from Miwarre

- [new] With blueprint events ("Create Blueprint" and "Place Blueprint") spanning several areas, to determine if the blueprint can be created/placed, the permissions of the areas are ANDed again

This seems to work well. It appears that you can't quite put a BP right to the edge of an area that you have BP permission (can put one block in). This may be by design and should be fine.

Quote from Miwarre

- [fix] various bug fixes, including a nasty bug with permission ORing

As with the "pre-release" you gave me, the permissions all appear to be working right as far a intersecting areas.

Did you change something? Now changes to permissions appear to be taking affect right away instead of having to re-log on my test server now. Yeah!

Definitely still some issues, probably related to the "negative coordinates API issue", with setting things in the "Edit Extent" GUI.

I spoke too soon. Now it appears that NONE of the protections are working. If I try anything in an area that has all permissions turned off (except Enter - Leave) with a player (non-admin) that has no special permissions in that area, it lets me do ANYTHING (place, destroy, BP, etc.). Maybe this is a result of changing to the "ORing" of areas but would not see why this would be. I did not replace my actual "ap-XXXXXX.db" file, .preset files nor my settings.properties file with the update, just the other files including the .jar, but do not see how that would matter.

Any ideas??

MY BAD! I had not replaced the "Locale" and "Resources" directories when I installed the new version.

So far looking good!

I do hope though that @red51 can get an update out to fix the API issue with negative coodinates and resolve the shifting of area creations/edits

I am seeing a number of things that appear wrong with this 1.0.5 release that makes me wonder if you actually released the right version. There a number of things that I am seeing that are not consistent with your Change log and/or manual.

- [new] Added area extent editing while creating an area and after creation; all the 6 boundaries can be edited
I do not see an "Edit Extent" button on the Edit area GUI and instead see a "Coming Soon" button and the resulting GUI showing the boxes to edit the area sides has numbers and buttons that do not seem right at all.

There are more things that I am finding that do not appear to work right, but I will hold off on posting these to be sure that I have installed the right update/release.

Quote from Miwarre

Well, I have not answered but I did not miss it; I made a few checks and I noticed an API problem which I reported in this post. I think it is not that N/S edges are shifted, but that you happened to notice this in a case where the N/S coordinate was negative; if you try in a place where the W/E coordinate is negative you'll find W/E edges shifted.

While I could in principle correct for this API error in the plug-in code, I prefer not to do this right now: many small code additions would be necessary and would become armful once the API error corrected; so, unless the API correction is going to take a lot of time, I prefer to keep things as their are for the moment being.

Ah ok. Hopefully the API error will be resolved soon.

Quote from Miwarre

While it would be possible to have this as a setting, applicable to all overlaps, I don't think it would be advisable, as it would make even more complex a point which already is not obvious, making user support heavier and the manual more complex. So, I greatly prefer to have it one way or the other once for all.

Having this as an option selectable for each overlap would be definitely unmanageable: the burden on the admin/managers, the complexity of the required GUI and so on make this a non-option in my perspective.

I see your point here.... I guess then that my vote would be to make it an "OR" combination (although even I might change my mind in the end)

I think you may have missed one of my previous comments and I am not sure if this is just something happening with me, but... When creating a new area, the N-S sides of the area gets shifted by one block to the South compared to what is drawn out. The E-W sides appear to get created as drawn out.

Regarding the error received when I select on some playernames in the player list... This appears to happen when I have scrolled up and down in the list a number of times and then select a player name. If I scroll straight down to the same player and select it, then the error does not come up. I am not sure is this is a result of going up/down in the list a number of times or if it is a time thing, but does not happen when i scroll straight down to the player and select. This may end up somewhat a mute point once you implement a search capability.

AH! I think I figured out when the error happens! It happens if I select a name in the list and don't complete the process of adding, then scroll to another part of the list and try and select a different name > ERROR!

I am getting an error message (below) when I click on the "Add" button to add managers to the list and no list of players comes up to select from. I suspect, since I have not seen any others complain of this, that this is another place where the SQL query needs to be modified to handle using MySql versus Sqlite.

API: REGISTER LISTENER class org.miwarre.ap.GuiPlayersEdit
Add onTextEntry
Add onClick

PLUGIN EXCEPTION (org.miwarre.AreaProtection, 1.0.4, Maurizio M. Gavioli aka Miwarre) ---->
java.lang.NullPointerException
at org.miwarre.ap.gui.GuiDefs.getTextWidth(GuiDefs.java:136)
at org.miwarre.ap.gui.GuiScrollList.addTextItem(GuiScrollList.java:171)
at org.miwarre.ap.GuiTwoListsSelector$TwoListPanel.<init>(GuiTwoListsSelector.java:176)
at org.miwarre.ap.GuiTwoListsSelector.<init>(GuiTwoListsSelector.java:62)
at org.miwarre.ap.GuiPlayersEdit$DlgHandler.onCall(GuiPlayersEdit.java:111)
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)

Quote from Miwarre

OK; as I said the change in the code to achieve this is trivial: just replace one && with one ||. I am pretty sure however that, as soon as I change it, someone will come forth complaining that he wants it the other way around!

You could be right. But, I do think that the "OR" approach would be the most prevalent approach and whichever is used you can achieve the other result by how you setup the larger area and smaller area within (as you have pointed out). My vote is to make it an "OR" approach.

Hmmm. Might it be possible to allow the admin/manager to select whether they want an intersecting area to use either "OR" or "AND" combination?

Quote from Miwarre

Good! Would you mind to write down a quick summary of the procedure you would suggest (or you know to work) for me to include in the manual? (of course, it would be properly credited to you).

Not worried at all about getting credit for this process, but the key to getting all of the existing players in all of the existing LUA script areas to get "assigned" to a new .preset combination of permissions is to make sure that the combination of permissions in the existing .group files matches exactly with one of the .preset file combination of permissions.

What I did was make a set of .preset files that have the combination of permissions that I want in the end for each of the .preset permission combinations. Then I replaced all of the .group files in the "Area Protection/Groups" folder with copies of the .preset files and renamed them as .group. This way all of the players in the original LUA script areas will match one of the .preset combination of permissions and get "assigned" as such. Attached is a set of .preset files that I used. I rearranged the permissions a bit in the file into categories, added some comment lines, moved all of the "same as" ones to the end of the file along with the "No Longer Supported" as comments just to make the files a little easier to manage/understand.

However, this process made me realize a potential "issue" going forward. If one of the .preset files is changed because you want to change what permissions a particular preset has, then all of the players in all of the areas that had that preset "assigned" will now become "Custom" as they no longer match one of the .preset combinations. It seems to me that there needs to be an in-game means for changing the definitions for the presets and when these are changed, the code would update the permissions for all the existing players that had the old preset combination to the new preset combination of permissions so that all the existing players still get assigned to that preset. It might be easier to have the definitions for the presets maintained in the DB versus files and tag each player in the DB to a preset combination of permissions (or "Custom" if a custom combination is what is wanted in some cases). I would think in most cases, owners/admin would want each player to be assigned to a preset combination versus using a bunch of "Custom" as it makes it easy to see when editing the player list in an area what permission combination each player has (ie: Jon_Miner (Admin)).

presets.zip

Quote from Miwarre

Even the example you quote might be approached in another way: does the large area have restricted chests all over its extent? Chances are the restricted chests would be in specific positions, as the public chests would be. So, it should be possible to define the large area with free chest access and ore (or more?) smaller areas for the restricted chests without chest access (rather than the other way around you describe).

Yes this would work for the example that I gave for "community chests", but as @Minotorious mentioned above and "OR" approach may be the situation that would be desired more often than an "AND" approach. TBH, I don't see it as simple as either "AND" or "OR" of the permissions and it would involve whether you are AND'ing or OR'ing either the "allows" or the "denys" and/or whether deny's override allows or visa versa. But to be honest, this is starting to hurt my head.

Quote from Miwarre

This is already built-in! The general permissions defined for an area are the permissions for "everyone" who does not have personal permissions. This is repeated in several places of the manual!

DOH! This makes sense, I think. My old age brain is slow to understand even when I have read the manual a number of times.

I do believe that I have figured out how to ensure that our old LUA .groups get assigned properly to the new .presets when importing/converting the old LUA DB. The key is that the permissions in the .group files must match exactly the permissions in one of the new .presets for existing player's to get assigned to one of the .presets. This includes making sure the existing LUA .groups contain the new permissions. The approach that I took was to make the .presets the way that we want them in the end, then make sure the .group files have the exact same content as the corresponding .preset file before the import/conversion.

Still testing, but things are looking good so far for changing Artisan's Realm to the new plugin, provided some of the things that you have on your list get implemented (search in area/player lists being the biggest one IMO).

Quote from Miwarre

See the last line of my answer above!

I did not see in the link you provided here where you addressed my suggestion:

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.

Do you plan to try and provide a means to edit the sides as well as the top-bottom of areas both when creating areas and editing areas?

BTW.... Please don't take my feedback/suggestions as disliking the plugin. I am liking the way this plugin is coming along!

Quote from Miwarre

How permissions work when inside several overlapping areas is described in the penultimate page of the manual (section "Permission combining"). This is very unlikely to change, as having "holes" in the areas would make things rather complex to manage and even heavier to compute. This kind of things has been discussed in this post above.

From the manual....
Permission combining
When a player is inside several overlapping areas, he is granted the intersection of the permissions for each area; in other words, he cannot do any action which is forbidden by at least one of the areas he is within, even if the other areas allow it.

If I understand this description (have not been able to test things out yet due to not being able to edit nested areas yet), then I do not think how permissions in overlapping areas works is going to support a major reason for wanting overlapping/nested areas in our world. One scenario that we would want to be able to do (community chests) is to have a large area where "GetFromChest" is false for "everyone" (see next comment about an "everyone" group), but have a nested area within that larger area where "GetFromChest" is true. I do not see how this would be possible if "....he cannot do any action which is forbidden by at least one of the areas he is within, even if the other areas allow it.". I would think that the "desired" way intersecting area permissions should work would be that a player can do something if it is allowed in any of the overlapping areas. In other words the intersecting permissions should be the combination of all "allows" not all "denys". As I said, I have not yet been able to experiment, but this is my current understanding.

As mentioned above, it would be beneficial to have an "everyone" group available in addition to all the world permission groups to allow permissions for every player without having to add all of the world permission groups to an area.

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.

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).

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.

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

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! 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.