Hi Captain,
there have been long discussions about mapping tools, I am sure you can retrieve the relevant thread by searching the fora. Incidentally, the compass is useful, once you have set your home point by sleeping in a tent / bed.
Doors and chests can be locked via the Area Protection script.
...] for slow development blues.[...]
[...] updates are slow. [...]
I am from another generation and my time perception might be different, I know, but I do not feel that updates are slow.
Considering that each update requires updating each server and how this affected the player community in the recent past, and also the amount of user support each update generates (in some case legitimately, but often for peoples who do not bother to read the explanations), the updating rate I have seen since I frequent this community (which is not since very long, I agree) seems to me reasonable/acceptable.
Then, of course, everyone is entitled to have his own perception.
Lucky you! My first image is a definitely boring
But many of the following images are for real estate properties near some place named Warre or Warren in Michigan, USA...
Yes, I understood the delays involved by the client-server-client round trip.
But in fact such a round trip is mostly unnecessary: if a plug-in needs to monitor a certain set of keys for its own purposes, it is practically certain that those keys should not carry out the in-game actions bound to them.
Is this what you mean by Player.disableClientSideKeys() ?
So, there would be 3 methods:
1) Player.registerKeys(....) to list the relevant keys
2) Player.setListenForKeyInput(true|false) to activate|deactivate forwarding of those keys to the server
3) Player.disableClientSideKeys(true|false?) to disable|enable processing of those keys.
I wonder if 3) could be already implicit in 2), though (or even both 3) and 2) implicit in 1)? ).
This would both avoid any unnecessary forwarding (less traffic) and make sure that only for registered keys there would be a delay due to the round trip, which is unavoidable, as the server-side plug-in needs to be notified of those key presses and perform any consequent action (better performance).
Would this be a reasonable middle ground?
Just a short note to let know that I have completed the porting of the my GPS script to a Java plug-in; as the original script, it includes:
* compass
* world position
* home setting / teleporting and direction-to display
* waypoint setting / teleporting and direction-to display
So far, I can see that it compiles without errors or warnings. Of course, until I can run and properly debug it, I have no idea if it works or not!
I am also experimenting with internationalisation...
i dopwnloaded this plugin...but how i can use it?
But of course it's also possible (basically that's already possible, with the exception that you can't disable keys yet) to just have a panel which displays some options or instructions.
Exactly! That "exception" is (was?) the only missing detail of the picture. This is why I am insisting so much on it.. 
I noticed that the new API version as new Player.is/setListenForKeyInput methods: I can speculate that, normally, listening is off and key strokes can only be examined after the fact and not cancelled; while, by turning listening on, once key strokes are forwarded to the server, they can be cancelled at the expenses of a slower reaction time. Near?
I've uploaded a new version of the API which provides proper access to the WorldElements, GuiElements and the Timer
The download link is the same, the online javadoc has also been updated.
Great, thanks! Downloading it...
All world elements are just interfaces, that's not intended, they will be converted to classes (so you can create a new instance directly)... this will be changed shortly!
Also GuiElement and its sub-interfaces GuiImage, GuiLabel and GuiPanel are all interfaces. Is it planned to change them into classes?
I am worried! Do you never sleep? Please take care of yourself, for the sake of yourself, of your beloved... and of this community: we need you! And in good shape! 
Modal GUI elements will certainly be useful, but have their own complexities and, reasonably, they are not a top priority now. So, they will come when (and if) they will come.
But not all plug-in GUI interaction with users needs to be modal; in fact, most of the applications I have in mind would work equally well (some even better) with modeless "dialogue boxes" (well, kind of...).
Possibly I didn't express myself clearly, but I understand and agree with you that a full client-server-client round trip for each key stroke would make the game unplayable.
This is why something along the lines of your player.disableClientsideKeys() suggestion could do the job, relatively simply and elegantly: just one server-client message when displaying the "dialogue box" and one when hiding it. For the rest, key strokes would still be processed locally, with the added (local!) check if a particular key is currently disabled or not, which shouldn't involve a big overhead.
Then, whether the disabling is achieved via a specific Player method or via a specific GuiElement property or via whatever other mean are implementation details whose overall convenience is better decided by whom has the full picture of the whole application.
Thanks!
@LokTedd4000: no, no es necessario instalarlo, ni es tampoco posible. Es simplemente una anticipation de la futura nueva forma de escribir plug-ins por RW, asi que los autores de plug-ins puedan familiriarizarse con ella. Si no planea escribir plug-ins, puede tranquilamente ignorar todo el asunto (perdone mi ortografia, pero nunca estudié Espanol en serio!).
Hmm.. what do you mean exactly with "handle several instances of itself running"? [...]
But something tells me you mean something else?
Uh, yes... I meant instances of the plug-in 'main' class, the one derived from net.risingworld.api.Plugin. Of course, internally, the plug-in may instantiate any number of ancillary or utility classes it may define, starts threads, etc, it may even spawn new instances of itself (if it likes a dangerous life...) but, being the originator, it will be responsible for the correct management of all these details, as always is the case.
OTOH, whether the main class can have multiple instances or not, outside of the knowledge or the initiative of the plug-in itself, influences for instance the strategies for defining fields or methods as static or not, for db management and in general for how paranoid about concurrency one should be.
If a server starts only one instance of each plug-in and as there is only one server in each RW context, I cannot see a use case for this myself, but I prefer to be sure, as I may easily overlook something.
Thanks. If anybody else uses my domain, I can probably suit him! 
Your explanations make much sense, thanks.
However, dealing with keystrokes in some specific / special way from within plug-ins might be rather important and it seems reasonable to get as right as possible since the beginning. One aspect coming to my mind is interaction with GuiElements (a generalisation of my elevator example). Other may likely exist.
GuiElements might be a primary way to display choices and actions to the player and collect selections from him, replacing the chat command system, which was a God sent so far, but it is a bit clumsy and requires the player to know what to type. As normally there is no mouse cursor in RW, selection in a GUIPanel can only be carried out with keystrokes, which however, when directed to the GUIPanel, should not trigger the 'usual' action (selecting a "{S}ave" button in the panel with {S} should not move backward).
I do not have a solution yet, your suggestion about player.disableClientsideKeys() seems on the right track, and other solutions may well exist. For instance, a GuiPanel or a GuiLabel may declare its own short-cut(s) 'automatically' disabling any 'normal' function that keystroke(s) may have (if they have none, then there is nothing to care about!).
Customised key bindings does not seem to me an issue: the greater problem I see is to disable -- at certain times -- the normal function of a given key, if any; but in practice it should be disabled unconditionally, regardless it currently has a binding or not, or it had a default binding which has been changed to another key, or it had NOT a default binding and now has a custom binding.
If a plug-in needs the player to perform a certain action (say, to achieve some goal or quest), it would not bother about key bindings at all, as it should try to detect that the goal has been reached, rather than monitor a certain sequence of key strokes, which would be very aleatory at best (what about the [MOVE_FORWARD] being kept pressed for 5 secs? How many individual [MOVE_FORWARD] key presses this implies?). So, key bindings should not be very relevant in such a case too.
Shall a plug-in be prepared to handle several instances of itself running, or it may assume to be a singleton?
Is there -- or will be there -- any requirement / limitation on the package name used for a plug-in?
I usually use my own reverse-domain-qualified package name + app name (as in "com.vistamaresoft.mywonderfulplugin"); any problem?
The tree I was hoping to add was not a cherry tree like others have said.
Basically, it is. Sakura 桜 is Japanese for "cherry-tree", and sakurabana 桜花 (lit. "cherry flower") refers primarily and originally to the cherry flowering; then per extenso to the flowering of several related species and cultivars. For instance, the white sakurabana you may see depicted (and possibly you even posted a picture of it) is the flowering of a plum, which is a strict relative of the cherry-tree. Sakurabana last for only a few days a year and it is (or was) usual for Japanese newspapers to have a column alerting readers of approaching flowering of famous cherry woods, to plan visits at the top of the flowering.
QuoteIt's a pink leaf tree that we actually see in real life.
It isn't. The pink you see are flowers, not leaves. True, the most impressive pictures you may find are from cultivars specifically selected to emphasize the flowering, usually at the expenses of the fruits.
QuoteOne thing I don't understand is the hacking of the game, most mods out there are made that way. Example if a tree in the game already has it's own animations and is biome specific then that same code should be able to be used to create new tree's and plant types by altering their code to fit the new plants. That's how a lot of mods for plant life is made in other games and I see no problem with doing the same here even by adding new mobs to the game. The code is there so I don't understand how people can say it'll be static when you just need to implement what is already there. As far as adding new blocks and planks to the benches the code is there simply alter it a bit so it registers those wood or block types for recipes. If doing this is against the rules then I don't know. I've said it before I'll say it again, I'm not here to step on anyone's toes if you take offence I'm sorry but the code is there and in my opinion hacking is modding.
Well, in another life, for a while I earned a life modding -- in the sense you describe, i.e. hooking into undocumented points and unsupported features of the programme -- a rather famous programme (not really, or not entirely, a game, but this is irrelevant) and, I'll assure you, it is not a path I would like to embark into again.
For instance, for every new version (even a minor version change), I had to do a good part of the reverse engineering again, and again, and again... to locate the new memory addresses, guessing the new functions, etc., re-writing portion of my code relying on functions no longer existing in the main programme, often re-implementing them myself... This for about ten times...
So, this is definitely not the way to go, if you want something which is stable, reliable and with a minimum of life span.
About rules, this is also probably against the rules, but it is not up to me to tell (luckily!).
Then, everybody is free to choose his own approaches and paths, of course. But the consequences are rather clear.
Yes, probably every plugin will have a separate subfolder, can't say for sure. Of course we're always open for suggestions^^
For what is worth, I would greatly prefer a separate sub-directory for each plug-in to be a requirement (with only second-level directories scanned for plug-ins). It avoids any file name clash between the contents of different packages, simplifies the distribution (the distribution ZIP can already include the sub-directory to be directly expanded in the plug-in directory), without any noticeable inconvenient.
You probably already thought of this: I would suggest using a directory other than scripts for Java plug-ins, to keep the two worlds separate and simplify the transition (and the final clean-up, once the LUA framework will be phased out).
Thanks for reporting your findings, @zfoxfire. I personally use Eclipse under Linux, so most of it is not directly applicable for me, but it is always interesting to hear about other people experiences.
I am a bit surprised about the need to fix the imports with NetBeans, Eclipse manages them automatically, or suggests the proper import, as soon as you use the implements keyword.
About testing the plug-in, of course this is not possible now, until a plugin-enabled version of the server will not be available (soon... :evil: ).
Only serverside events are taken into account. [...]
Understood.
QuoteSome events can't be cancelled for logical reasons (obviously cancelling the "PlayerDisconnectEvent" is not possible), some other events can't be cancelled since they event is called after the actual action (e.g. the new "PlayerKeyEvent").
Agreed of course on "PlayerDisconnectEvent" . Not so sure about the "PlayerKeyEvent", though. Of course, it may happen only after the key is pressed, as all events are triggered after the event took place, but what about being handled before the consequent action is carried out?
A practical example could be an elevator plug-in I'm porting from my existing LUA script: I would like to use the number keys [0]-[9] to select the destination floor (at least for the first 10 floors) but, after processing the key, if the user is found to be in an elevator, I would like to block the usual behaviour of keys [1]-[5] (quick slot change), cancelling the event. So, after the key press event itself obviously, but before the key press is processed by the system.
QuoteThe old PlayerQuickslotChange event in the Lua API was an exception[...].
Understood. My example above notwithstanding, this event in itself seem rather secondary...
QuoteRight now every event offers the setCancelled(boolean); method, but I guess it's more convenient to have an interface which is only implemented by certain events (by all events that are actually cancellable). This way you can see if the event it cancellable or not
Yes, this makes a lot of sense. Thanks for your reply, enlightening as they always are! 
