[Plug-in] Area Protection

  • @Bogus:


    1) while drafting this plug-in, @red51 asked me not to rely on any external or third party library or plug-in; as the pug-in is going to be kind of "official".


    In fact, after some discussion, a decision was made to even duplicate a part of RW-Gui into this plug-in, rather than require RW-Gui itself.


    So, I assume it is not the case to rely on SprachAPI. However, this does not exclude support for any language; the plug-in is shipped with a few languages, but anyone can rather easily add any other language: the locale/readme.txt explains how.


    2) Bug: Am I correct in assuming that that bug shows up in Single Player? Debugging SP is difficult, but I suspect there is a bug in RW Single Player code which does not call some of the initialisation steps of plug-ins.


    The workaround I found is to issue the reloadplugins console command right after starting an SP session. With this, plug-ins work correctly and the bug you describe does not happen. Without this, for instance, the GPS does not even shows its small info window.


    I'll check with @red51 if my diagnose is correct. For the time being, the workaround should work.

  • First off I wish to say that I like where this plugin is going. It is looking nice and is rather easy to use but,


    when deleting an area there needs to be a confirmation screen to make Shure you want to delete and area. As it is you just click on a name and it is gone. This can lead to many claims being deleted by mistake and can cause areas to be lost altogether. This can cause more work for the admin not reduce it.


    Also there needs to be some sort of a areatp function to get to particular claims. When dealing with 700 claims on a server it is hard to go 1 by 1 to find a particular claim. I guess we could use the coordinates with the goto console command to get around. It looks like south and east are negative numbers but it would be easer if the coordinates would be shown in RW native format.


    Also when in the edit screen and you go to add a player to the area the player names are not in alpha numeric order making it hard to find player names. 1 way around this would be to add a text entry box so we can type the name desired into the box, but it would be better if we could have the list in alpha numeric order as well as having the entry box available.

  • First off I wish to say that I like where this plugin is going. It is looking nice and is rather easy to use

    I am very glad to hear this; there is quite a good deal of code behind it and I am also glad that you do not seem to have had big problems (crashes, data wipes, etc.): this seems reassuring.

    when deleting an area there needs to be a confirmation screen to make Shure you want to delete and area. As it is you just click on a name and it is gone. This can lead to many claims being deleted by mistake and can cause areas to be lost altogether. This can cause more work for the admin not reduce it.

    1) Deletion confirmation: Sure!

    Also there needs to be some sort of a areatp function to get to particular claims. When dealing with 700 claims on a server it is hard to go 1 by 1 to find a particular claim. I guess we could use the coordinates with the goto console command to get around. It looks like south and east are negative numbers but it would be easer if the coordinates would be shown in RW native format.

    2) Go to area:


    Questions:


    a) To which point of the claim? The geometric centre? (it may well be underground...)


    b) Is this aimed at admins/managers only or at regular players as well?


    c) Can you describe a common use case? Is it a separate function ("I just want to go there")? Or is it a prerequisite for some other function (for instance, "I want to go there to edit the claim")?


    I am asking to try to understand the most useful context and workflow.


    d) Would a new menu item "Go to area" which shows the list of areas enough?


    3) Search box ?


    Not sure I can implement it quickly, but it might make sense to have, at the top of the list of areas, a text box where to enter a few characters, press a "Search" button and having the area list reduced to names matching (no regex! Just 'regular character' matching). Would this make sense?


    4) Geographic coordinates:



    Coming from 20 years in the flight simulation and geo-mapping fields, I find RW native coord format rather disconcerting and dis-orienting! (to orient myself, I have to swap the two numbers and flip the sign of one of them, never remember which! :S )



    But I understand it may be convenient to be consistent with the F3 display. I'll change them.

    Also when in the edit screen and you go to add a player to the area the player names are not in alpha numeric order making it hard to find player names. 1 way around this would be to add a text entry box so we can type the name desired into the box, but it would be better if we could have the list in alpha numeric order as well as having the entry box available.

    5) Finding player names:


    Ok; alphabetic order makes a lot of sense.


    I am less convinced of text entry box: player names tend to be funny, with uncommon orthographies, graphic tricks and so on; you do not type it 100% correct and the DB will not find it and nothing will happen (in the best case; in the worst case, horrible things could happen!).


    Couldn't the text box be a search box as described above for areas?


    Anyway, thanks for the great suggestions!

  • goto area


    1- to the center of the claim would be good but would need fly mode to be required.


    2. This is mainly for admin use but an option to allow regular players is not objectionable as long as we can turn it off for regular players if so desired.


    3. colmon use would be to ease in finding a claim if needed to be removed dew to inactivity, or do an expansion or other editing.


    4 A menue item "Go to area" which shows the list of areas, would be helpful as long as the coordinates are in a form easily used by the goto function in the console. The way it is now we have to switch the positions of everything and decide witch numbers have to be negative. It would seem, I would think, that a tp function would be more convieniant as well as intuitive in this case.


    Search Box


    a box to search for the claims would be nice but where the real problem lies with the player names list when adding a player to the claim. A search system similar to the mailing plugin would be advised where you type in a few letters of a name and it gives you a list of players, starting with that letter or set of letters, to choose from. This could be used for claim names too, but you already seem to have the claim list alphabetized.


    Players Names


    Question, will this plugin accept 2 part names? I mean names containing 2 or more words or will we still have to require them to remove spaces in there player names, as we do now?


    Geographic coordinates:


    I understand about real life conditions and use of coordinates but the game system only accepts native rw coordinates to teleport and not the normal system you seem to be using. I understand the normal system is easer to understand but if the game does not accept the cords then what good is it? We still will have to swich things around if we want to use goto to get to the claim in question. Isn't it easer just to use the same system the game uses?


    Finding player names:


    A search box for this was a secondary thought but it would be nice to have something like the mail system to find players, but an alpha numeric list is really all that is needed.

  • goto area


    1- to the center of the claim would be good

    Otherwise?

    but would need fly mode to be required.

    This would be true of any point of area, as its geography cannot be known in advance (any point could be underground, under water, high in the sky...). The code would then be:

    Java
    player.setFlying(true);
    player.setPosition(areaCentre);

    2. This is mainly for admin use but an option to allow regular players is not objectionable as long as we can turn it off for regular players if so desired.

    Once the code is there, deciding who has access to a function is another matter. I would start by reserving this function to admins/managers only, as this should not become a duplicate of a proper teleport plug-in (which this plug-in is not intended to be) and as it requires setting player fly mode, which a 'common' player may not be entitled to.

    3. colmon use would be to ease in finding a claim if needed to be removed dew to inactivity, or do an expansion or other editing.

    So, it is either a separate task or ultimately a separate (or separable) step of a process; then, a separate menu item makes sense.

    4 A menue item "Go to area" which shows the list of areas, would be helpful as long as the coordinates are in a form easily used by the goto function in the console. The way it is now we have to switch the positions of everything and decide witch numbers have to be negative. It would seem, I would think, that a tp function would be more convieniant as well as intuitive in this case.

    If there is a "Go to area" menu item, there would be no need to issue any console command and obey any syntax:

    • Select the menu item,
    • find the area name in the list (this is where a search function may come handy with 700 area names to choose from)
    • select it: => be placed there (with flying mode turned on).

    this would be all; nothing to actually type.

    The area list is retrieved from the data base in alphabetic order only at server start up, newly created areas are added at the end of the list; for the moment being, I am trying to avoid a DB operation each time that list is displayed; so, area list alphabetic order is usually approximated, but it is not guaranteed at the moment.


    In any case, with a list several hundreds of items long, scrolling 20 items at a time to reach "Zug Castle" would be a pain; I think a search option would be more useful for areas than for players, as the former may be much more than the latter.


    Alphabetizing the list of players might be even more resource demanding, as the player list is maintained in the world DB which is an additional step away than the plug-in DB. The plug-in is maintaining a player list of its own, mostly to avoid a DB query each time a name <=> ID conversion is needed; I'll try to have it kept in alphabetical order.


    Also note that, generally speaking, alphabetical order is much less obvious a concept than it may appear at first sight...

    Players Names


    Question, will this plugin accept 2 part names? I mean names containing 2 or more words or will we still have to require them to remove spaces in there player names, as we do now?

    Special characters in player names (or whatever) only are a concern when you have (well, the plug-in has!) to extract it from a longer / more complex string, like a chat command. Once you get rid of chat commands and go GUI, the problem is gone.

    Geographic coordinates:


    I understand about real life conditions and use of coordinates but the game system only accepts native rw coordinates to teleport and not the normal system you seem to be using. I understand the normal system is easer to understand but if the game does not accept the cords then what good is it? We still will have to swich things around if we want to use goto to get to the claim in question. Isn't it easer just to use the same system the game uses?

    In my perspective, there should ultimately be no need to use the goto or any other console command in relation with this plug-in and I still (unreasonably?) hope the goto command will one day accept coordinates in the "right" format.


    But for the moment being, yes, I see the validity of your point.

  • I appreciate your assessment of these situations and understand your responses. I like your workarounds and defer to your judgement. However you decide to deal with these things is up to you, I was just bringing them to your attention. I do think the teleport aspect should be kept to admin and management also but was willing to have the possibility open to all in the setting if so desired. Thanks for considering my ideas.

  • Released!


    Version 1.0.0 is available from the thread top post, the manual can also downloaded separately.


    Latest change log:


    0.12.0:


    - fixed running in Single Player mode
    - improved class and method access levels and javadocs


    1.0.0 (mostly suggestions from @sharkbitefischer):


    - added confirmation message box before deleting an area
    - improved alphabetical order of area and player names in lists
    - added "Go to area" feature
    - area coordinates are now displayed in the RW "native" format


    Enjoy!

  • Ok , let's see if I can get it correct this time. After creating an area no area names show on the bottom left above the health bar from any area until the server is restarted. This makes it hard to edit an area since edit does not go automatically to that area's info to edit and it is needed to hunt the name in the list. I know this is not supposed to be this way but... hope this helps



    Also how do you change the area dimensions after it is created? I think you need to make a dimensions button under the edit screen to be able to alter the dimensions after creation and have it an admin feature only.


    next thing to figure out is your permissions system lol

  • Ok , let's see if I can get it correct this time. After creating an area no area names show on the bottom left above the health bar from any area until the server is restarted.

    This is very strange: no server restart should be needed. I'll run some specific checks.

    Also how do you change the area dimensions after it is created? I think you need to make a dimensions button under the edit screen to be able to alter the dimensions after creation and have it an admin feature only.

    This is not possible at the moment. I plan to add this feature in a next version, but I would like the current code to be more tested / reliable first (the old script didn't have this feature either, if I am correct)

    next thing to figure out is your permissions system lol

    It is exactly as the old system, except for:

    • Pick vs Destroy Vegetation and Chest access which have been adjusted and are described in detail at the end of the manual
    • new permissions which follow the events the plug-in API provide to plug-ins

    Hope this help.

Participate now!

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