Let us see. when you add or remove a player to an area you are required to move out of the area and back into the area for the permissions to take hold. Logging out and back in does nothing to set the permissions for the claim. if you were added to the claim you still must exit and reenter the area before you can work the claim. I did not try restarting the server.
The ability to grief in fly mode on login has been fixed 
@sharkbitefischer: thank for testing! 
I'll check it of course, but for the moment being, I think I'll leave as it is in any case, waiting a few days for more testing of other features and cumulating updates; having to get out and back into an area might be annoying but it is not a "show stopper" (as the need to reload the plug-in or restarting the server would be).
I am also working on adding a search box and the ability to modify the area extent after the fact.
this sounds worth waiting for. This bug is the only 1 I can realy find so far, left. we can waite for editing the area dimensions after creation for a fix. please continue and we can come back to this later and the surch box will be a great addition too I think.
I was asked to ask this question.
Is there a way that the ability to create claim areas could be given to a non admin person or group? or is this an admin only function?
I almost forgot. My test server is throughing this error
PLUGIN EXCEPTION (org.miwarre.AreaProtection, 1.0.2, Maurizio M. Gavioli aka Miwarre) ---->
java.lang.NullPointerException
at org.miwarre.ap.Db.getPlayerNameFromId(Db.java:839)
at org.miwarre.ap.GuiPlayersEdit$PlayersEditPanel.<init>(GuiPlayersEdit.java:246)
at org.miwarre.ap.GuiPlayersEdit.<init>(GuiPlayersEdit.java:78)
at org.miwarre.ap.GuiAreaEdit$DlgHandler.onCall(GuiAreaEdit.java:256)
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)
here is the full log
this error happens when you go into edit area and click on edit player.
this sounds worth waiting for. This bug is the only 1 I can realy find so far, left. we can waite for editing the area dimensions after creation for a fix. please continue and we can come back to this later
Ok. Area extent editing is more complex than it may seems, as RW does not allow to change the extent of an existing area; so, I need to destroy the area with everything is attached to it (the visible box, the permissions, etc...), recreate it with the new extent, recompute all cumulative permissions of players (who may pass from inside to outside the area or vice versa) and reattach a new visible box... But it is definitely worth the effort.
Question: the dialogue box where the values of the area extent is edited can be organised in various ways:
1) By min/max boundaries:
2) By centre point and extents:
3) A mix of the two:
Which do you think it would be more useful?
I was asked to ask this question.
Is there a way that the ability to create claim areas could be given to a non admin person or group? or is this an admin only function?
...(read the manual)...
"Area managers" are exactly that: regular, non-admin players who have full area managing abilities. Only admins can make a player an area manager, but once appointed, that player can work on areas exactly like admins.
I decided not to use a group, as a player can belong to only one group and I doubt all the area managers would be equal under all other respect.
I'll look into that error. Thanks for the log.
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)
Sorry for the delayed response... Your query resulted in: "Error Code: 1273: Unknown collation 'NOCASE'
The following query worked with 3821 rows returned with valid ID & Names.
SELECT `ID`,`Name` FROM `Player` ORDER BY `Name`;
I did notice that I have some players in the DB with spaces in their names with some of them even having a leading space...
Sorry for the delayed response... Your query resulted in: "Error Code: 1273: Unknown collation 'NOCASE'
The following query worked with 3821 rows returned with valid ID & Names.
SELECT `ID`,`Name` FROM `Player` ORDER BY `Name`;
I did notice that I have some players in the DB with spaces in their names with some of them even having a leading space...
I was starting to suspect something like this: collations are different from MySQL and SQLite. Which collations are implemented /installed / configured also changes from one version of MySQL to another and from one installation to another.
I could do something like:
if I can safely assume the latin1_general_ci collation be present on all versions and installations of MySQL.
Otherwise "SELECT `ID`,`Name` FROM `Player` ORDER BY LOWER(`Name`)" should be correct in any SQL context, but I have no idea how it would work with accented characters.
In SQL, I am more a "final user" than else; has anyone with a stronger knowledge something to suggest?
Display MoreOk. Area extent editing is more complex than it may seems, as RW does not allow to change the extent of an existing area; so, I need to destroy the area with everything is attached to it (the visible box, the permissions, etc...), recreate it with the new extent, recompute all cumulative permissions of players (who may pass from inside to outside the area or vice versa) and reattach a new visible box... But it is definitely worth the effort.
Question: the dialogue box where the values of the area extent is edited can be organised in various ways:
1) By min/max boundaries:
2) By centre point and extents:
3) A mix of the two:
Which do you think it would be more useful?
I am not shure of what I am looking at but the 3rd choice looks like the better one I think.
On the x, y cords is that the cords of the center point and the width is set in both directions from that as well as the depth? then you set the bottom and the top elevation? so for a 120x120x120 claim it would be width 60, depth 60, bottom height 60 and top height 60 measured from the center point in all directions? Or are they set from the center point as 120 and the game divides the area on both sides of the center point?
example
we will work from spawn with cords of 0 0 0 for ease of talking.
with the x width being 60 does the width get placed in both directions from the point or is it split between both directions to be 30 blocks on both sides of the point?
will regular players be able to delete there own claims? or just the sub claims they set within there claim?
are regular players allowed to set sub claims?
I have read most the manual but can't remember the anser
Display MoreI am not shure of what I am looking at but the 3rd choice looks like the better one I think.On the x, y cords is that the cords of the center point and the width is set in both directions from that as well as the depth? then you set the bottom and the top elevation? so for a 120x120x120 claim it would be width 60, depth 60, bottom height 60 and top height 60 measured from the center point in all directions? Or are they set from the center point as 120 and the game divides the area on both sides of the center point?
example
we will work from spawn with cords of 0 0 0 for ease of talking.
with the x width being 60 does the width get placed in both directions from the point or is it split between both directions to be 30 blocks on both sides of the point?
In my idea, width is width, from one edge to the other! Not half-width. This is what interests players (and admins), I think, how wide along the x (or deep along the y) is the area; to arrange that width (and depth) around the centre is the job of the code!
(this raise the point of what to do with odd widths, like 75, as there cannot be half blocks; but I'll see).
The difference between 2) and 3) is in the height:
in 2) height is treated like the other two dimensions: a span around a centre
in 3) height is expressed in absolute coordinate (as in 1), as in "Bottom: -600 | Top: 400"
I think 3) makes more sense than 2): "Bottom: -600 | Top: 400" is more clearly understood than "Centre H: -47 Height: 1000" (assuming the surface is at height 53 in the centre point).
will regular players be able to delete there own claims?
No, only admins (and managers)
or just the sub claims they set within there claim?
are regular players allowed to set sub claims?
No, at the moment. And, while possibly useful in special cases (which the admins/managers can always set up if needed), area splitting into sub-areas seems to me rather Baroque as a general concept available to everyone.
Display MoreIn my idea, width is width, from one edge to the other! Not half-width. This is what interests players (and admins), I think, how wide along the x (or deep along the y) is the area; to arrange that width (and depth) around the centre is the job of the code!
(this raise the point of what to do with odd widths, like 75, as there cannot be half blocks; but I'll see).
The difference between 2) and 3) is in the height:
in 2) height is treated like the other two dimensions: a span around a centre
in 3) height is expressed in absolute coordinate (as in 1), as in "Bottom: -600 | Top: 400"
I think 3) makes more sense than 2): "Bottom: -600 | Top: 400" is more clearly understood than "Centre H: -47 Height: 1000" (assuming the surface is at height 53 in the centre point).
I think I understand but have my questions and will waite to see how you are getting it to work before I ask them.
No, only admins (and managers)
cool, I agree on this. it prevents the normal player from deleting there claim and we have to come back and fix it. Am experianceing this with the present lua ap.
No, at the moment. And, while possibly useful in special cases (which the admins/managers can always set up if needed), area splitting into sub-areas seems to me rather Baroque as a general concept available to everyone.
this will be fun checking on the already set areas that are overlapping or just plain inside other areas. Although it is not often done there are still specialized areas that will need testing. Thanks for the heads up and can't waite to see what you have come up with. I will figure a way around the problem if it arises.
request:
could we have a "goto area name list" button, from the edit window, when we are standing in an area? This would make hunting for a sub area claim easier by, not having to leave the mother claim to look for the subclaim's name, to be able to adjust permissions or add a player to the sub claim "only". I have several large areas that have much smaller areas inside of them that need to be able to adjust there permissions.
how would I set up a main claim, with a sub area that I wanted another player to be able to work in, without allowing them access to the rest of the claim? and could I remove access to the smaller area for the owner of the larger area without looseing access to the smaller area by the second person?
ATM I can not allow internet access to my test server and I need more bodies to test some of this
this will be fun checking on the already set areas that are overlapping or just plain inside other areas.
This is not a problem for the plug-in: areas can intersect or be one completely inside another freely, each with its own permissions, player list and group list.
how would I set up a main claim, with a sub area that I wanted another player to be able to work in, without allowing them access to the rest of the claim? and could I remove access to the smaller area for the owner of the larger area without looseing access to the smaller area by the second person?
Well, this IS a problem: areas can intersect freely, but what each player can do within the intersection is the (logic) intersection of the permission he has for each area; in other words, if in area 1 he can do action A but not action B and in area 2 he can do action B but not action A, in the intersection of the two areas (if any) he cannot do either action, action B because he is within area 1 and action A because he is within area 2.
In other words yet, areas cannot have "holes", portions inside them where the area restriction do not hold, as this would make things very complex to manage for admins (and managers) and for the plug-in to compute.
could we have a "goto area name list" button, from the edit window, when we are standing in an area?
Possibly I do not understand. By "go to" you mean:
1) Being physically moved from the current area to another area you select on the list? This does not seem to me very useful, as while working in a dialogue box you cannot look around or move around and then being in a point or in another makes little difference.
2) Leave the editing of the current area and open the editing of another area you select in the list? In case, do you want changes to the current area saved automatically before switching?
to be able to adjust permissions or add a player to the sub claim "only"
Currently, the plug-in has no concept of "sub-claim" or "sub-area"; there are areas which simply overlap. And I am reluctant to add it, as it would quickly make a mess of hierarchical relationships difficult to manage for the players and slower to compute for the plug-in.
Otherwise "SELECT `ID`,`Name` FROM `Player` ORDER BY LOWER(`Name`)" should be correct in any SQL context, but I have no idea how it would work with accented characters.
In SQL, I am more a "final user" than else; has anyone with a stronger knowledge something to suggest?
@Miwarre This SQL statement worked, at least on my MySql server. I do not have time at the moment (real life work has me really busy) to follow and respond to this topic as much as I'd like, but hope to to be able to get back to it soon. I think @red51 is hoping to use this plugin to replace the LUA script version and drop LUA script support, which I can understand, however ATM, this would NOT be viable replacement. This is looking VERY promising if the MySql issue and the "reach in" issue can be addressed.
Keep up the good work!!
Possibly I do not understand. By "go to" you mean:
1) Being physically moved from the current area to another area you select on the list? This does not seem to me very useful, as while working in a dialogue box you cannot look around or move around and then being in a point or in another makes little difference.
2) Leave the editing of the current area and open the editing of another area you select in the list? In case, do you want changes to the current area saved automatically before switching?
my request is number 2 I think. I wanted to leave the current editing page and open another area's editing page from the list. and autosaving changes to the first area when changing pages to edit would be good.
Well, this IS a problem: areas can intersect freely, but what each player can do within the intersection is the (logic) intersection of the permission he has for each area; in other words, if in area 1 he can do action A but not action B and in area 2 he can do action B but not action A, in the intersection of the two areas (if any) he cannot do either action, action B because he is within area 1 and action A because he is within area 2.
In other words yet, areas cannot have "holes", portions inside them where the area restriction do not hold, as this would make things very complex to manage for admins (and managers) and for the plug-in to compute.
ok so the permissions of the second person in the smaller claim is dependent on the first player's permissions for the larger area and the first person's permissions are restricted by the second player's permissions in the smaller area when in the smaller area?
after setting an area manager, is the manager position transferred to all areas thus allowing them to assist with the setting of areas/claims? or are they restricted to making changes to the existing areas only?
When altering area dimensions, will there be an easy way to move the center point or will we have to guess and enter numbers? I would think a select center point button on the area dimension edit screen would be advised. click on the button, then maybe the window closes and you click on where you want the center point to be and the area dimension edit window reappears? Basically I want to know how we would expand a claim in a particular direction rather then expanding it in 2 directions at the same time?
ok so the permissions of the second person in the smaller claim is dependent on the first player's permissions for the larger area and the first person's permissions are restricted by the second player's permissions in the smaller area when in the smaller area?
Well, not exactly: each player is separate; 1st person permissions for the larger area and 1st person permissions for the smaller area intersect each other; while 2nd person permissions for the larger area and 2nd person permissions for the smaller area intersect each other. But permissions of 1st person and permissions of 2nd person are completely independent.
(Of course, this assumes each player is given specific permissions for area A and/or B; by default each area has its own "generic" permissions which apply to any player without specific permissions, but any player can be given specific and independent permissions for each area).
after setting an area manager, is the manager position transferred to all areas thus allowing them to assist with the setting of areas/claims? or are they restricted to making changes to the existing areas only?
An area manager has authority on all areas, past, present and future! 
When altering area dimensions, will there be an easy way to move the center point or will we have to guess and enter numbers? I would think a select center point button on the area dimension edit screen would be advised. click on the button, then maybe the window closes and you click on where you want the center point to be and the area edit window reappears?
This would be very nice, but for sure it will not be there in the first implementation, and I am not sure the API would allow it (but I'll see if something of the kind is possible).
This SQL statement worked, at least on my MySql server.
Well, it should work, being part of the SQL spec!
This is looking VERY promising if the MySql issue and the "reach in" issue can be addressed.
The MySQL issue can surely be solved; it is all a matter of deciding which collation is general enough and still provide reasonable results.
Sorry, I looked in the previous posts, but I cannot understand which the "reach-in issue" is. Would you mind reminding me? 
"reach-in issue"
people outside an area hitting inside it for a short range biiiiiig problem for pve/creative servers unfortunately
people outside an area hitting inside it for a short range
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?
Don’t have an account yet? Create a new account now and be part of our community!
