[Plug-in] Area Protection

    Quote from Jon_miner

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

    Ok

    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.

    Then things work as they are designed to work: an admin is still an admin and keeps the management abilities of an admin; the privileges turned off concern the permissions within areas which are only those explicitly granted (with priv. turned ON, admins have all permissions in all areas). This was changed in ver. 1.0.2; the manual is a bit outdated on this point.

    Quote from sharkbitefischer

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

    Yes, when privileges are off, selecting the menu item turn them ON and vice versa; see the discussion above about rewording this menu item.



    Quote from Jon_miner

    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"?

    Good point! Auto-selecting the area to edit should only work when the player is inside only ONE area.

    Quote from Jon_miner

    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.

    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.

    Quote from Jon_miner

    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.

    See the last line of my answer above! ;)

    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.

    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 Jon_miner

    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.

    @Jon_miner as far as editing the nested area just go outside the larger area in unowned land and you can pick the nested area to edit from the list.


    @Miwarre ok we have use of creating areas and adding players and managers but we can not alter permissions of players and managers when admin priv is turned off. shouldn't we be able to edit players and managers even with the admin priv turned off by what you said in a previous post? this is strictly for admin by the way.

    Quote from Jon_miner

    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.

    In practice, you would prefer ORing the permissions of overlapping areas rather than ANDing them as now. The change in the code would be trivial, but are we sure this other solution is more general than the current one?


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

    Quote from Jon_miner

    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.

    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!

    Quote from Jon_miner

    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?

    Yes, I do (as I said above). My idea was to allow extent editing after creation, for existing areas, but adding an "edit extent" button during initial area set-up too will not be a big deal.

    Quote from sharkbitefischer

    we can not alter permissions of players and managers when admin priv is turned off. shouldn't we be able to edit players and managers even with the admin priv turned off by what you said in a previous post? this is strictly for admin by the way.

    You should have these abilities even with admin priv. turned off. I'll check this point.

    Quote from Miwarre

    In practice, you would prefer ORing the permissions of overlapping areas rather than ANDing them as now. The change in the code would be trivial, but are we sure this other solution is more general than the current one?


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

    We would definitely prefer the OR instead of AND. Let me give you another example, I have a big area that noone can build in and I want to have 10 small areas in it one for each out of 10 players so that they can build only in their sub-area. With the current AND method I would have to add all of the players in the big area (which will mean they can also build in parts of the big area outside of their small area) and then deny 9/10 players access to the other 9 players' areas. Not really convenient imo.


    Here is a small drawing illustrating what I mean:

    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 Jon_miner

    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.

    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! X/;)

    Quote from Jon_miner

    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

    Probably, you makes it more complicate than it actually is. There is nothing else beyond "allow's" and "deny's"; so, whatever is not "allow"-ed is "deny"-ed; once you list the "allow's" of an area, anything not listed is automatically "deny"-ed.


    When multiple areas overlap, you can combine the permissions by ORing the "allow's" of both (in which case the "allow's" override the "deny's") or by ANDing them (in which case the "deny's" override the "allow's").


    The theorem of De Morgan ensures that ANDing the "deny's" is the same as ORing the "allow's" and vice versa.


    There are no other possibilities (at least as long as the 30 permissions are all equipotent, and I am rather sure nobody of us would want to cope with complexities of turning them into a hierarchical system!).


    Quote from Jon_miner

    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.

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

    Quote from Jon_miner

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

    For the search box, a few days are still needed; right now I am struggling for buglets and issues in the RW API... :S

    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

    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?

    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)

    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 got some errors


    PLUGIN EXCEPTION (org.miwarre.AreaProtection, 1.0.4, Maurizio M. Gavioli aka Miwarre) ---->
    java.lang.ArrayIndexOutOfBoundsException: -18
    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.GeneratedMethodAccessor5.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    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.fireChannelRead(ByteToMessageDecoder.java:297)
    at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:413)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:265)
    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(Thread.java:748)

    @Jon_miner: thanks for the details about the ".group" / ".preset" set-up. I'll try to arrive at a suitable text for the manual.


    I see your point about having preset changes reflected on players. I'll think about and I'll see what can be done.

    Quote from Jon_miner

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

    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.


    @Jon_miner, @PatrickBronke: I think the two errors you report to be the same and I think I know how to fix it.

    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.

    Quote from Jon_miner

    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.

    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.

    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.

    Version 1.0.5 released!


    Version 1.0.5 is available from the thread top post.


    1.0.5 Change log:


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


    Note: the images in the manual have not been updated, but the manual text should be up-to-date with the current plug-in status.


    List search box will be included in the next update.


    Enjoy!

    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.

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

Participate now!

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

Create Account Login