Posts by Miwarre

Quote from sharkbitefischer

goto area

1- to the center of the claim would be good

Otherwise?

Quote from sharkbitefischer

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:

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

Quote from sharkbitefischer

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.

Quote from sharkbitefischer

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.

Quote from sharkbitefischer

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.

Quote from sharkbitefischer

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.

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.

Display More

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

Quote from sharkbitefischer

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.

Quote from sharkbitefischer

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 kind of remember having already raise this point, but I cannot find where...)

It might be just a problem of mines more than anybody else, but I keep hitting it.

Coming from 20 years of work in the flight simulation and geo-mapping fields, I find the RW coordinate display in the F3 window and in the console goto command disconcerting and disorienting! Coordinates are listed in the 'wrong' order and one of them has the 'wrong' sign. To orient myself, I have to swap the numbers and flip the sign of one of them (and I never remember which one! ).

When I had to output 'real' geographic coordinates (in my GPS plug-in) I had no doubt to have them in the 'right' order and with the 'right' signs (note: of course, there is not a 'right' or a 'wrong' order or sign: they are just conventions. The fact is however that, since centuries, geographic coordinates are listed in the N/S, E/W (, opt. h) order and with S and W being negative and N and E positive, which establishes a largely preferred practice).

Of course, the F3 display has a different aim: it is not a geographic mapping display, it is a programming debug display which outputs its info as convenient for another goal. So, I thought: "Should RW ever display coordinates with a real geographic meaning, they would be in the 'right' order and with the 'right' signs".

However, I notice that the map has its coordinates in "programming" style (as the F3 output), rather than in "map" style. And the console goto command, which refers to geographic points, expects its data in the "programming" style rather than in the 'correct' map style.

Am I the only one which find this disturbing? Is there any plan to "fix" this? (whatever "fix" may mean in this context).

Thanks, M.

Quote from sharkbitefischer

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.

Quote from sharkbitefischer

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!

Quote from sharkbitefischer

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

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

Quote from sharkbitefischer

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!

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

Version 0.12.0, a.k.a. Release Candidate 2 is available from the github repository pointed to in the top post.

Changes:

*) Fixed running in Single Player ( @Bogus, this is for you and thanks for the report!)
*) Fixed a pair of buglets in the GUI
*) Adjusted access levels of classes and methods: other plug-ins can access Are Protection public methods to check for permissions and other (refer to the javadoc in the source for this).

Well, for sure there will be some loss: we can assume that listeners are held in some container which is then enumerated (and each listener called) when the relevant event is detected.

So, for a 50-GuiElement "dialogue box" (I am using the term in a generic sense) and for click events:
*) there will be 50 insertions in the container instead of 1 at dialogue box creation;
*) 50 deletions from the container instead of 1 at dialogue box destruction;
*) 50 function calls instead of 1 at each relevant event;
*) some code will be repeated in each listener handler;
*) 49 of those function calls will return without doing anything but after having tested that the GuiElement returned by event.getGuiElement() is not this (functionally equivalent to a 50-case switch in a one-for-all listener, but possibly slower).

Of course, a lot of details would depend on what precisely you aim at, but if the 50 GuiElements are there at the same time, they are presumably not 100% independent one for each other and some additional code will be required to let the GuiElements (or their parents) to communicate to each other the outcome of the events; more code to write, debug and execute (which also does not help code readability and maintainability).

I am not an expert of Java performance, but I would expect the CPU additional load to range from trivial/unnoticeable to sizeable depending on how many listeners there are, how frequently this happens and specific implementation details of RW code and of your code.

However, the whole concept does not strike me as an improvement; I understand that handling, say, click events for 50 elements may lead to a very large method; I personally would address this by splitting the method with local method calls when necessary.

So, for instance:

@EventMethod
public void onGuiClick(PlayerGuiElementClickEvent event)
{
	Player		player	= event.getPlayer();
	switch(event.getGuiElement())
	{
	case toggleAButton:		// simple: process directly
		aValue = !aValue;
		break;
	case sellAButton:		// complex: call a local method
		doSellA(player, aValue);
		toggleAButton.setVisible(false);	// no more A!
		break;
	// and so on...
	}
}

I surely cannot answer your question; I am not even sure I understand them. In fact, I do not understand why you should break an event handler down into several equivalent handlers.

I mean: each handler would still have to check the event to see if it has to handle it or not. So, ultimately instead of

@EventMethod
public void onPlayerCommand(PlayerCommandEvent event)
{
	Player		player	= event.getPlayer();
	String[]	cmd	= event.getCommand().split(" ");


	if (cmd[0].equals("command A") )
	{
		processCommandA(player);
		return;
	}
	else if (cmd[0].equals("command B") )
	{
		processCommandB(player);
		return;
	}


	// and so on...


}

you will end up with something like:

@EventMethod
public void onPlayerCommandA(PlayerCommandEvent event)
{
	Player		player	= event.getPlayer();
	String[]	cmd	= event.getCommand().split(" ");


	if (cmd[0].equals("command A") )
	{
		processCommandA(player);
		return;
	}
}


@EventMethod
public void onPlayerCommandB(PlayerCommandEvent event)
{
	Player		player	= event.getPlayer();
	String[]	cmd	= event.getCommand().split(" ");


	if (cmd[0].equals("command B") )
	{
		processCommandB(player);
		return;
	}
}

Is there any gain?

Well, mouse wheel would probably go unnoticed, but to detect a change in equipped item, you don't need to register 5 listeners, just:

player.registerKeys(KeyInput.KEY_1, KeyInput.KEY_2, KeyInput.KEY_3, KeyInput.KEY_4, KeyInput.KEY_5);
//Set listening to true, otherwise the client will not forward any input
player.setListenForKeyInput(true);

but, sure, you need to do it for each player. Then you can get the key with a listener for the PlayerKeyEvent event.

[Message deleted, sorry]

Quote from Minotorious

Nice one

Just a small comment from my side, I don't think pressing Return to create an area is the right way to go.

Well, apparently, this is not a concern: even while creating a new area, once you enter the chat with [T], you can press [Return] at the end of a chat line and it will not affect the area creation process; another [Return], 'outside' of the chat, is needed for the area creation process to go on.

So, I will not change this. Comments?
____________________

@Bogus: I have run a test session in Single Player and, with a simple change, the plug-in runs in SP too. I'll upload the change to github soon; I believe we can consider this solved...

Quote from Minotorious

The only thing I am not sure about with Insert is if it can alter input outside of the game after being pressed. Since insert usually (in text editors etc.) alters input from placing a character to replacing a character. It is worth a try anyway

Good point, but I suspect it does not.

It may depend on the OS, but I am pretty sure the key is a local event and not a system event in both Linux and Windows (only the active window will receive it).

As OSX is ultimately a Unix system, it should also work the same (unless they screwed it up in more ways than I know...)

If you search (or browse) the fora a bit, you'll discover that rivers and dynamic water are planned for later in the development: either is much less simple than it seems at first sight.

The number and the distribution of lakes varies from seed to seed; any seed have at least some, anyway (or at least, I still have to find a seed which has none!).

Fly speed is also related with the world creation speed: if fly speed would increase, it is likely the world creation while you fly would not keep up (unless you have a supercomputer...) and you would have to stop anyway.

Screen shot key may depend on your OS, on whether you run RW under Steam or not and on whether you run it full screen or not.

Saved game? They are worlds, WORLDS, WORLDS! not a simple matter to change a world once created (kidding, of course!)

Why he shouldn't? His last activity is reported 11 hours ago, not that much...

Quote from Minotorious

But you are correct for now there aren't that many options to make this happen other than to agree on a key or to make the key configurable in the settings file you have

Maybe go with the ?// key next to RShift I think that is for sure not used for anything (kidding keep return for now and we can see later it is not that important for the time being:) )

While configurable keys may sound nice, I suspect they would be more a nuisance than other; in addition to the complexities of recognising them in config files (huuuge switches if we go textual, as in "create_key=KEY_KANJI" (I like that key !) ) and the ease for errors both with textual and numeric representations ("create_key=148"), two practical problems arise:

1) dynamically constructing the key name to output it in the modal window while creating the area extent would be far from easy

2) if someone is admin (maybe unlikely) or area manager (much more likely) in two different servers with two different key configurations, a lot of confusion would be ensured.

I prefer to find a suitable key and stick with it. I still believe that the INSERT key is a reasonable choice: not used by anything else (as far as I know), unlikely to be hit by accident and still vaguely mnemonic (to create => add => insert a new area...).

In case, I prefer to change it as soon as possible, before habits build up.

Quote from Bogus

I can test the plugin in SP mode and prepare a world before uploading it to a server. ;D

I see; yes, this makes sense. Anyway, I fixed in my dev copy that crash you reported; I'll pay more attention to SP usage...

@Bogus: I'll check that crash but, in principle, yes, the very concept of Area Protection only makes sense in a multiplayer environment (if there is only you, from whom are you protecting what?)

EDIT: for the moment being, to overcome that crash, create a permissions/groups folder in your Single Player RW, similar to the MP server setup.

It may crash further down, though, as the plug-in expects the MP server setup; However, if you want to try, I would be grateful...

Quote from Minotorious

I would recommend simply adding a create area button (maybe next to the area name textbox) clickable by mouse if that is something you would consider.

Hmmm... I suggest you try and see for yourself which are the possible options.

While you are defining the area extent, RW is working as usual (you can move around, interact with the environment, type in the chat, etc...) and, as with usual RW working, there is no mouse cursor to click with. Only keys can be used to steer the area creation process.

I understand why the RETURN key might not be the best choice but, at that stage, a key to go on and a key to cancel have to be agreed upon anyway.

Quote from Minotorious

Just a small comment from my side, I don't think pressing Return to create an area is the right way to go. While creating areas I need to be able to communicate with the player [...]

Good point. This is pretty much true for any alpha-numeric character then. A Ctrl or SHIFT + RETURN would be handy, but they are a mess to detect.

What about a high function key (F10 or F11 or F12) or INSERT?

Area Protection Plug-in 1.0.7 released! (2018-08-06)

The Java Area Protection plug-in is 'officially' released and available. Download link at the end

Current features:

• Compatible with the old Area Protection 3 LUA script: existing areas are kept as it can read the old data base directly.
• 30 different permissions can be turned on / off independently.
• Each area can have its own general permissions with any combination of those 30 permissions.
• Each area can also assign specific permissions to each server group (overriding the area general permissions).
• Each player can have his own specific permissions for each area (overriding the group permissions and the area general permissions).
• Old LUA script Groups can be reused (once renamed), either with no modification or edited as preferred, as presets, i.e. sets of player (or group) permissions ready to use "with one click" but configurable if needed.
• Selected non-admin players can be appointed by admins as "area managers", with full authority on area management.
• Fully GUI operated.
• A setting in the config file allows to choose whether to use the position of the event or the position of the player to determine whether an event can be permitted or not; the former is more precise, avoids any "reach-in effect", it is the default but it is slower, the latter induces a "reach-in effect" but it is (much?) faster.
• Also runs in Single Player mode.
• Makes several methods available to other plug-ins to query permissions and more (refer to the javadoc in the source).

You want to try it?
Adventurous server owners can download it, install it in their servers and try it. Please remember that it is new code: it has been tested by generous server owners, but it may have bugs and may crash!

In any case, please read the manual: it is in the ZIP file and it can also be downloaded separately below; it is only 8 pages with a lot of images! Please read it!

And this is the manual: AreaProtection_Manual_jpg.pdf please read it!

Problems?
If you try it and meet problems, please report the issue in this thread with enough information to reproduce it: if I cannot reproduce it, I cannot fix it!
Thanks to anybody who already helped and anybody who will help polishing this plug-in!

Source code
The source code for this plug-in is available on my github plug-in repository .

P.S.: Did I say please read the manual?

Change log:
1.0.7:
- [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
- [new] Better explosion control (please read the relevant manual paragraph; feedback welcome)
- [new] With blueprint events ("Create Blueprint" and "Place Blueprint") spanning several areas, to determine if the blueprint can be created/plced, the permissions of the areas are ANDed again
- [fix] various bug fixes, including a nasty bug with permission ORing

1.0.6: not distributed

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

1.0.4:
- When a player is added to / removed from an area and he is within it, his permissions are updated immediately, without requiring any longer he exits and re-enter the area
- Changed the collation used in SQL queries to be compatible with both SQLite and MySQL (technically: it now uses "ORDER BY LOWER(`Name`)" instead of the previous "ORDER BY `Name` COLLATE NOCASE)
- It is now configurable whether the plug-in uses the event position or the player position to check for relevant permissions: the former is more precise, avoids any "reach-in effect" (and it is the default) but it is slower, the latter is less precise and introduces a "reach-in effect" but is much faster

1.0.3: not distributed

1.0.2:
- fine tuned what the "Admin no Priv" flag turns off
- "Go to area" now lists all areas rather than owned areas only
- Adding/removing a player to/from an area is now immediately active, rather than after plug-in reload
- Areas a flying player is in at spawning are now detected immediately (by-passing a RW bug)
- Corrected a few bugs in group management

1.0.1: Fixed bug in new area addition

1.0.0: Initial release

Quote from noci

How about several windows from about 5months ago I had so my problems.
I have a lot of information and options to display / offer in different windows. Where I z.b. want to use several subgroups and staggered windows.
I think there were plausible plausibility with the InputText which should
be fixed if I open another window and hide the previous one.

If you could make a small example of multiple and windowed windows, that would help me a lot.

Sorry @noci, I forgot about this request of yours, I deeply apologise

If it is still current, would you mind elaborating a little and perhaps drafting an actual example of what you need to achieve? Your description is fairly general. Thanks.