Posts by Miwarre

While working on the Area Protection plug-in, I am finding it would be very useful a way to change the boundaries of an Area after it has been created (currently the only way to alter the extent of an existing Area is to remove it and create a new one, which makes management complex).

The most immediately useful implementation would be something like:
Area.setMinX(int value), Area.setMaxX(int value), Area.setMinZ(int value), etc. with values as global coordinates,

but if something like Area.set[Start|End][Chunk|Block]Position(Vector3i val) is easier to implement, I could live with it...

Crossing fingers (but not holding breath )...

I have used Eclipse to develop in Java for years; recently I switched to NetBeans and I am still adjusting my habits...

If I understand correctly, you want to retrieve the (Unique) ID of a player from his name, regardless the player is currently connected or not.

First, you need the plug-in object; if the code is in a class derived from net.risingworld.api.Plugin, the plug-in object is simply this; if it is in a class of a different inheritance, you have to work out how to reach the main plug-in object.

Assuming plugin is the plug-in object:

WorldDatabase db = plugin.getWorldDatabase();
String queryString = "SELECT ... FROM Player ..."; // construct the query string you actually need
ResultSet result = db.executeQuery(queryString);
while(result.next())
{
	// manage each row in the result set
	// according your query string and your needs
}
result.close();

gives you access to the world data base; the data base can be queried; players are in the Player table; table columns you may be interested in are: ID (world-dependent, but unique and constant within each world), UID (universal; it is a long), Name. This should allow you to build the query string you actually need according to your goals.

Remember that Database.executeQuery() may raise exceptions, which should be catch-ed (precisely how depends on the context and on your coding style).

A new 0.5.4 version of the PnB plug-in is now available.

Apparently at least some of the last fixes did not percolate into the .jar file (possibly NetBeans is less smart than Eclipse and does not rebuild all the necessary files ).

This version is a full manual rebuild and all the known bugs should be fixed.

This is presumably the 'final' version of the plug-in: no more development on it, other than maintaining it working according to RW evolution.

Details and download in the top of this thread.

Thank you, @sharkbitefischer; you have a message...

As I have resumed the work on this plug-in, I would like to test its ability to read the data bases of the old LUA script (and then its compatibility) in more realistic conditions than some contrived alpha test.

If some server owner would be so kind to send me the DB of his LUA area protection script, this would contribute to the development of the new plug-in (and it would spare me some time...).

The DB out of its own server has little sense and does not really contain any sensitive information, but for added privacy, rather than posting the DB here, you may use a private conversation.

Thanks in advance!

P.S.: @yahwho: yes, the source code will be public.

Not really drop-down, but RW Gui has programmable menus...

EDIT: RW Gui source code is public (on github if you feel brave, you may add drop-down lists to it... (hint, hint, ... )

Plug-in Central is supposed to list and give access to any compatible plug-in. Making a plug-in compatible with Plug-in Central is very easy and described in the "Making my plug-in to appear in Plug-in Central list" section of the top post.

When Inventory.insertNewItem(short itemID, int variation, int stacksize) is used to add an item to the player inventory and the next open slot is one of the 5 quick slots, the item is not actually added (and available in the quick slot) until the inventory is not open with the I key.

Once the inventory is open, the item becomes available in the quick slot.

This issue can be tested with the Plank 'n Beams plug-in which uses this method to add the item to the player inventory.

Quote from Minotorious

No don't worry about that, my panel/labels are created and stored for each player individualy in attributes

Then I do not understand why you need to distinguish between GuiElement visibility in general and for a specific player.

As these GuiElement's belong each to just one player, simply turn on/off the general visibility with GuiElement.setVisibility(true/false), so that the element is visible/hidden to its player and GuiElement.isVisible() returns the 'correct' value.

Or am I missing something?

(yes, I know I am not red51! )

If you turn a GuiElement invisible with GuiElement.setVisibility(false) and then query its visibility of course, it returns false. It cannot take into account whether you have set that particular GuiElement visible for some player or not, if nothing else because you do not tell it which player! (the method call has no parameter for the player)

See also my reply in your other post.

I do not know if this is intended behaviour or not; but you are playing on two levels here:

1) The visibility of a GuiElement is set in general with GuiElement.setVisibility(boolean)

2) the visibility of a GuiElement is set for a specific player with Player.setGuiElementVisible(boolean)

The documentation for Player.setGuiElementVisible() says:

"calling this method ignores the current visibility state of the GUI element (see GuiElement.setVisible(boolean)). However, changes to the GUI element itself will restore the original visibility value of the GUI element."

So, it seems to me that:

A) if you set off the (general) visibility of several GuiElement's, you need to turn it on for each GuiElement (and for each player). Are you turning off the (general) visibility of the panel parent only or of the panel children too? If the latter, then the need to turn it on for each child is clearly intended behaviour.

B) On another plan, of course if you add the same panel child to all players, it will have the same content for each player. Not knowing what you are trying to achieve, I have no idea if this is correct or not; in most cases, the contents shown to each player is player-specific. So, you may want to examine this point.
____________________

Making Player.setGuiElementVisible(boolean) recursive:

I am not sure this would be generally preferable. For instance, assuming you create a dialogue box with some (rare or secondary) options turned invisible; when you turn the whole dialogue boxvisible, you do not want those options becoming visible.

As GUI elements are by default visible and a call is needed to make them invisible, if such a call is made, I think it should be honoured when changing the visibility of the parent (my opinion, though).

Did you try the documentation at https://javadoc.rising-world.net/?

A description of what you are attempting to achieve and a snippet of the code you are using would make helping much easier.

See here for an extended discussion of this point.

Quote from angriff

Woot.. great That will open a whole new era of plugins. The one idea was to charge iMoney to enter an area.

For this you don't need to change the status of any object. In fact it could be done with the current plug-in API.

A new 0.5.3 version of the PnB plug-in is now available.

New:

*) Fixed a bug with iron and copper ingot ID's (again thanks to @Lady_whynot!).

Details and download in the top of this thread.

Quote from Minotorious

Once you have more time maybe rewrite it to use the Item Definitions calling them by item name that way internal ID changes will not bother you so much anymore

Do you think names will not change either?

Quote from red51

[...]Unless I find some serious issues with the name changes, a player.setName(String) method will be available with the next update

Sorry for having routed the discussion away (into whether to use player names in commands or not).

The main point I initially wanted to raise was that such a totally generic player renaming method would be very easy to abuse; I for one would be very upset if I find my character renamed on a server; not to mention that it could be renamed to something offensive (or that I consider offensive) or rude or...

I am sure that @Minotorious will never do this, as well as most of the server owners we know and respect. But we can also be pretty sure that sooner or later someone will rename some (or all?) the characters on a server in a censurable way.

If the problem are blanks in the name (as well as other problematic characters, like possibly quotes or apostrophe), I would understand an automatic procedure which replaces these characters in player names with underscores (or another 'jolly' character). Such a procedure could be documented and run 'blindly'.

But the name of my character is my choice (within the rules), and not anybody else's.