Posts by Miwarre

Great! Thank you.

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.

A charity could be added to which donate old clothes to help abandoned boars... ( :evil: )

Quote from Minotorious

If the callbacks are called and processed in your EventMethod for the GuiElementClickEvent before the same method closes the panel

No, they are not; callbacks are asynchronous by definition.

In the case of GuiTextField.getCurrentText(), it queries the client for the text and returns immediately; when the client reply comes with the required text, the callback is called and this may happen (in particular bad cases) seconds after the GuiElementClickEvent handler method is done.

In any case, there is no guaranty that this will happen within any specific time frame, including before the click handler is done.

About your other suggestions, I agree that 2. (..."make the Ok button save the information but not close"...) would be the cleanest and clearest.

Unfortunately I do not see how it could work, as the "Ok" button cannot save anything (which has not been saved before); it may only ask for the text data which, in general, may arrive after the user has pressed the [X] button, the Panel has been closed and the data become lost anyway (I agree it would be improbable, but in principle possible and therefore this way of working is breakable).

As it seems to me you are using a procedure like this yourself, possibly this relies on the high probability that the needed data have arrived or the needed PlayerGuiInputEvent has been triggered by the time the user presses the 'other' button ([X] or whatever). However, the whole of this is not deterministic (as network running is not deterministic to start with) and leaves room for any kind of problems.

To see that I am speaking of something real, I think it has happened to you too that you are digging and, for an unfortunate latency spike, you see the result of your digging to appear a few seconds after the pickaxe hit. If the same latency spike happens between the click event and the callback being called, the panel is likely to have been closed in the meantime, the text data would be lost and even exceptions may result, if the Panel & children have been cleaned up in the meantime.

Quote from Minotorious

the 2 events should trigger at the same time

Two events cannot be triggered at the time: one of them will necessarily be triggered before the other. It may be casual which one, but one shall be. However, at least for rather homogeneous cases like this one -- in which all events refer to GUI and in particular to children of the same GUI element and are generated by single user action--, it would be useful if order of events is documented (and swapped, as I was asking before ).

EDIT: I am rather sure that, in other GUI frameworks, in a case like this where one control looses focus and another gains it with a single click; the event for the loosing focus control is generated before the event for the focus gaining control; also because this is what makes more sense in a general way.

Quote from Minotorious

3) then simply use String myText = myTextField.getCurrentText(blablabla);
4) do whatever you want to do with the String
5) close the GuiPanel

It is not so simple: GuiTextField.getCurrentText(Player player, Callback<java.lang.String> callback) takes a callback as an argument and I cannot close the [GuiPanel[/tt] and its children until the callback is called and the returned text string processed (in the callback, not in the code for the dialogue box); for just one GuiTextField it is somewhat devious but still manageable.

But in the "Edit Area Extent" dialogue box I have 6 GuiTextField's: coordinating 6 callbacks results in incomprehensible, unmaintainable code.

I still believe the simpler solution to be by far an exchange of the event order. About your point:

Quote from Minotorious

there could be a case someone would want them to trigger the other way around

it is possible, but I have described a very real and relatively frequent case where the current event order is "non-preferred". Can you describe a use case where, when the focus moves from element A to element B, it would be preferred to have the event for element B (the focus destination element) notified before the event for element A (the source element)?

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

Scenario: a Panel (simulating a text entry dialogue box) with:

• a GuiTextField into which to enter a value
• a GuiLabel with the "OK" text and a suitable background colour (simulating an "OK" button)

Operation:

• The user clicks on the GuiTextField and enter some text
• with the cursor in the GuiTextField, the user clicks the "OK" button

these are the generated event for 2. (in this order):

• PlayerGuiElementClickEvent for the click on the "OK" button
• PlayerGuiInputEvent for the text input loosing focus.

Managing event 1 usually entails closing the "dialogue box", which results in event 2 not being processed at all and the entered text to be lost (in the best case, if the relevant listener has been removed; in the worst case, it might generate an exception as the "dialogue box" pieces no longer exist).

Would it be possible to have the PlayerGuiInputEvent before the PlayerGuiElementClickEvent? This also once that "real" GUI buttons are added to the API?

(So far, I am working around this by requiring two clicks in a row on the "OK" button, but it cannot be a definitive solution.)

Quote from red51

This issue will be fixed with the next update

Great! Thanks. (sorry, I forgot to answer...)

@red51: Something strange seems to happen when converting between Chunk+Block coordinates and Global coordinates when Global is negative.

(Chunk -1, block 0) converts into global position -16 (using ChunkUtils.getGlobalPosition())

BUT

Global position -16 converts into (Chunk -2, block 15) (using ChunkUtils.getChunkAndBlockPosition()) which is 1 block off.

This also happens when creating Areas with the Area(Vector3f globalStartPosition, Vector3f globalEndPosition) constructor: the chunk and block start/end positions of the resulting Area are off by one block if any global position is negative.

This is a small plug-in which tests these methods.

/****************************
	T e s t C h u n k U t i l s  -  A Rising World Java plug-in to test ChunkUtil conversions.


	TextChunkUtile.java - The main plug-in class


	Created by : Maurizio M. Gavioli 2018-07-23


(C) Copyright 2018 Maurizio M. Gavioli (a.k.a. Miwarre)
This plug-in is licensed under the the terms of the GNU General Public License
as published by the Free Software Foundation, either version 3 of the License,
or (at your option) any later version.


This plug-in is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE. See the GNU General Public License for more details.


You should have received a copy of the GNU General Public License along with
this plug-in.  If not, see <https://www.gnu.org/licenses/>.
*****************************/


package com.vistamaresoft.testchunkutils;


import net.risingworld.api.Plugin;
import net.risingworld.api.events.EventMethod;
import net.risingworld.api.events.Listener;
import net.risingworld.api.events.player.PlayerCommandEvent;
import net.risingworld.api.objects.Player;
import net.risingworld.api.utils.Utils.ChunkUtils;
import net.risingworld.api.utils.Vector3f;
import net.risingworld.api.utils.Vector3i;


public class TestChunkUtils extends Plugin implements Listener
{
	@Override
	public void onEnable()
	{
		registerEventListener(this);
	}


	@Override
	public void onDisable()
	{
		unregisterEventListener(this);
	}


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


		// check for a specific chat command
		if (cmd[0].equals("/cu") )
		{
			if (cmd.length != 3)
				player.sendTextMessage("usage: /cu chunkval blockval");
			else
			{
				// get chunk val and block val from the input string
				int chunkVal, blockVal;
				try { chunkVal= Integer.valueOf(cmd[1]); }
				catch (NumberFormatException e)
				{
					player.sendTextMessage("Chunk value is not an integer");
					return;
				}
				try { blockVal= Integer.valueOf(cmd[2]); }
				catch (NumberFormatException e)
				{
					player.sendTextMessage("Block value is not an integer");
					return;
				}
				Vector3f	globalPos	= ChunkUtils.getGlobalPosition(
											new Vector3i(chunkVal, 0, 0), new Vector3i(blockVal, 0, 0));
				player.sendTextMessage("Chunk "+chunkVal+", block "+blockVal+" => pos "+globalPos.x);
				Vector3i	chunkPos	= new Vector3i();
				Vector3i	blockPos	= new Vector3i();
				ChunkUtils.getChunkAndBlockPosition(globalPos, chunkPos, blockPos);
				player.sendTextMessage("Global pos. "+globalPos.x+" => chunk "+chunkPos.x+", block "+blockPos.x);
			}
		}
	}


}

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

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

OK! It appears that things are working correctly with my MySql world!

Quote from Jon_miner

All of the areas converted from my LUA DB have players like "<playername> (Custom)" instead of getting one of the presets (owner, friend, etc.). I noticed that the original ".group" files were named with "title case" (Owner, Friend, etc.) instead of the lower case of the .preset files (owner, friend, etc.). Is this why it did not assign the players defined in the LUA areas to one of the .presets? Is there some way to get the conversion to assign the players in one of the old .groups to one of the new .presets instead of making the "(Custom)"?

Well, first of all, naming of files is totally irrelevant; you could name them "file01.preset", File02.preset" " FILE03.preset"... and it would (should?) not change anything. What matter are:

1) The permissions turned on in each preset: if the permissions of a player match those in a preset, the preset name is shown near the player name. If the permissions of a player for an area do not match the permissions of any preset, then " (Custom)" is shown.

2) The preset name is declared in the "GroupName=" line of it.

Maybe this might already allow you to diagnose why all these players are "Custom" in your particular case. It is also possible that some more set-up might be necessary to convert not only the actual permissions (they should already be correct) but also the naming.

Quote from Jon_miner

It also appears that when editing an existing player, there is no option to select a preset. Only check or uncheck permissions. It would be helpful if you want to change a player from one preset to another or change a "custom" to a preset.

Nice suggestion. I'll add the the list.

Quote from Jon_miner

Something I noticed right off is that it is difficult to add a player to an area for our world as we have several thousand players and it is slow to scroll through the entire list to find the one you want. Can a search and/or filter or a "find as you type" feature be done? This would also be needed for the areas list as we have several hundred areas.

A search box option is already in the to do list. It should be there soon ( ).

I'll try to understand that error about player selection.

Quote from Jon_miner

ould it be possible to allow all of the old LUA script text chat commands or at least some (/showareainfo, /arealist, /addplayertoarea /removeplayerfromarea, etc.)? Maybe with some shorter commands (/info, /addplayer, /removeplayer, etc.)?

Well, I understand you experienced admins are accustomed to those commands, but I am against them, for several reasons:

1) all commands which require a name (of an area or of a player) will have problems if the name contains spaces (and possibly non-ASCII characters which may be difficult to type with the keyboard available to the admin).
Selecting from a list does not have this problem and also avoids any typo (I have a old LUA DB kindly provided by @sharkbitefischer with area names like "Meow and Traps Palace (meowxdrawr and TrapLord)" or "Shazza & pocket (ShazzaGalore & pocketdeath1)": not the easiest string to type correctly).
Once the search box implemented, list selection should be not significantly slower than a chat command, taking the time lost in typos into account.

2) Several of those commands have other kind of problems: chat commands like "/info" are too generic: any plug-in may define such a generic string! So, the command has to be "/ap info <area_name>" in the best case. "/ap arealist" may list hundreds of items, barely useful; and so on.

3) I do not like chat commands!

So, for the moment being, the answer is "I understand, but no" :evil: .

Quote from Jon_miner

- It appears that chest and blueprint protection works properly even when trying to "reach in". Furnace protection appears to work properly as far as either destroying them or operating them, but it appears anyone (from either in or out of the area) can take/put ore and ingots. This is no worse however than the current LUA script.

I'll check it, but I suspect the plug-in is not notified of the ingot movement by RW, in which case, there is nothing I can about it, at least with the current plug-in API. I'll let you know the outcome.

Quote from Jon_miner

- Minor nit and not everyone may agree with me, but the "Admin priv: ON/OFF" item seems backwards to me. IMO that line should display what it is currently set to (either ON or OFF) and toggle to the other. It appears that it now displays what it would be set to if you click on it. Also minor, but think it would look better as "Admin Priv:" versus "Admin priv:" (Priv capitalized). Also a chat command to toggle this would be handy (/adminpriv). Also a display of the current setting on-screen for admins (maybe under the area name).

Hmmm... strange you find this item backward and not the very first one, which uses the same strategy "Hide areas" when they are shown and "Show areas" when they are hidden). Would "Turn admin priv. ON / OFF" clearer?

As my own language (Italian) only capitalises the first letter of a sentence in whatever context, I never understood the "Title Capitalisation" of English. But feel free to suggest any linguistic improvement you may prefer: English is not my native language.

Again, not "/adminpriv" but "/ap adminpriv"... Admin setting on screen added to the to do list...

Quote from Jon_miner

A quicker way to navigate and find player and/or area names in the lists is by far the more important thing that I feel needs fixing.

As I said, already in the to do list (actually it is the second item, after the ability to change the extent of an exiting area).

@Smudger: English not being my native language, I am not sure I understand what you are asking or even if you are asking anything. Does the list of features in the first post of this thread help?

@Jon_miner, @Minotorious, @sharkbitefischer: reach-in can now be avoided!!! See above...

Version 1.0.4 released!

Version 1.0.4 is available from the thread top post.

1.0.4 Change log:

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

- fixed a bug with player lists

Enjoy!

Quote from Minotorious

But is it so bad to iterate over 1000-5000 areas? Java is slow but it is not thaaat slow

Well, Java is not particularly slow (and anyway faster than LUA!).

Anyway, iterating over 5000 areas in itself, should only take a few milliseconds. The point is that, for each area, it has to be computed if the point when the action happens is within the area or without (which implies up to 12 comparisons); then for each area the action is within there are 3 Map lookups, 2 player attribute lookups, several tests and various "logic sugar".

This for each pickaxe stroke (or similar repetitive action): if a dozen players are digging at the same time, I expect the server latency to increase somewhat and the player starting to notice some (additional) lagging.

In the current implementation, all the above computation is reduced to just one single bitwise AND!

However, the code for the above, real action point, implementation is already there (it is used to check for explosions; for the moment being disregard that explosion events have some problem); making a test version where it is used for all events should not be very complex and then it can be tested "on the field" if the overload is acceptable.

Quote from Minotorious

but a player spawn event is always triggered no matter if the player is flying or not

I re-did the tests and, in fact, it seems so: PlayerSpawnEvent is always triggered.

I still have to understand why a breakpoint set on it was not fired if a breakpoint was also set for the PlayetEnterAreaEvent (which happens right before it); some mystery of the Java debugger? a catch with multi-threading? ...

Anyway, I confirm that the PlayetEnterAreaEvent is not triggered at spawn time if the player is flying, but it IS triggered if the player is NOT flying (of course, if the player happens to spawn within an area); in the first case, the event is triggered as soon as the player moves a bit.

Quote from Minotorious

people outside an area hitting inside it for a short range biiiiiig problem for pve/creative servers unfortunately

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?

Quote from Jon_miner

This SQL statement worked, at least on my MySql server.

Well, it should work, being part of the SQL spec!

Quote from Jon_miner

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?