Posts by Miwarre

Quote from sharkbitefischer

ok Re report lol. it seems that the new rwgui causes the selection boxes to stop working and pnb is charging admins for materials. How do you stop that the other version didn't charge admin. I reverted the rwgui to the old version and the check boxes started working again so the problem is with rwgui.

Whether admins are charged or not is set in the plugins/pnb/settings.properties file. Adjust these settings and then reloadplugins.

The missing images in RWGui should be fixed with the latest ZIP version.

ZIP file for version 0.5.1 updated with the two missing images.

Download link in the TOP POST.

Quote from sharkbitefischer

new version has problems with pnb. the check boxes on the old and the new pnb won't work with the new rwgui.

Thanks for the report, @sharkbitefischer. In fact, the radio boxes do work but, as two image files are missing from the ZIP, nothing is shown in them and you cannot see it. I'll upload a complete set of images ASAP.

Quote from Jon_miner

I don't know if I can give you specifically what is going wrong with the RWGUI plugin, but it appears to throw a java exception error when it is actually responding to the "text box" input of other plugins. Specifically the Animal Breed Master plugin by @Machete. Not trying to point fingers at any particular code or anything as I don't really understand it, but this is what I have noticed. I will try and see if I can replicate it and give you some log info.

It might be the same thing fixed in the latest version (just uploaded). Maybe, if anyone is bold enough to test it...

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

New:

*) Updated to the latest (0.9.3) plug-in API: it should work with the latest server and client code.

Details and download in the top of this thread.

Please let me know of any remaining issue (hoping there are no new issues... )

Also please note that the source code of this plug-in is now available on github.

Version 0.5.1 uploaded.

Mostly a bug fix: it should fix the above error and improve a bit the code.

Download link in the TOP POST.

It is my understanding that plug-ins are first loaded and then enabled in the order in which the underlying operating system lists them when a directory is scanned.

This order depends on the operating system itself: on Unixes (Linux and OSX) it is basically (but not entirely) the alphabetical order of the file name (probably in some generic locale); on Windows it depends, among other things, on the file creation order.

The solution proposed by red51 right above is fine for addressing a two-way priority (A always before B), but in general relying on some order of loading / enabling to address plug-in precedence seems to me sub-optimal (for instance, with 3 plug-ins, it might happen that you want A before B, B before C and C before A! Or A before B for some operations and B before A for other operations).

As the code needs to be adjusted in any case, it would be better to implement the proper precedence in the code itself. Remember that plug-ins can speak to each other!

Thanks to everybody for their kind words!

An updated PnB should be ready by tomorrow.

Quote from sharkbitefischer

I don't want to rush you but the GPS plugin is acting real funky and throughs errors all the time anymore. Please have a look at it too. and you might have a look at your base rwgui plugin. it probably could use a face lift

Thanks for the hint: updating GPS will follow immediately after PnB.

Can you tell me some detail about what is not working or needs to be improved with RWGui? As far as I can tell, it is working correctly.

Hello everybody,

In case anybody cares, a short note to let this great community know that I am back and I am right now catching up with Rising World evolution and its plug-ins in particular.

I am sorry for having been 'missing' for a year; several health problems in a row (some serious, some less serious but aggravating anyway) have eaten a lot of my time up for a long time.

I am reconstructing my RW plug-in dev tool chain and I should be back 'in business' very soon. I noticed that several plug-ins of mines have compatibility problems with the new RW versions. In particular, I saw PnB stopped working and @red51 has been so kind to put on line an adapted version of it; thanks, red51!

I'll start mending PnB first; I am also browsing the forums to catch up, but if anybody has any specific plug-in request and leave a note here, I'll notice sooner; thanks.

Thanks to JIW dev team and to this great community for keeping the great job up with Rising World.

M.

Quote from Kryssi_79

@Miwarre
Is it possible to create a listView-Window
with 2 Buttons 'OK' and 'cancel' ?

Examples:Pic1 / Pic2

The examples you quote are tree views, which are rather complex to implement. For a simple (non-hierarchical) list, you may insert in your main window a VerticalLayout to which to add the list items and below it a HorizontalLaytout with two labels representing the buttons

Button are not currently supported as such by RWGui, but you can make the intended meaning and function clear to the user by using GuiLabel's with an appropriate background colour.

Quote from mjminfo

As I requested in a previous post, is there a way to delete wp from the global list ?

No, there is no way to delete WP's from the shared pool.

One of the reasons I am thinking of removing the shared WP feature is also that it is going to require another sort of full DBMS support for it and it seems to me this would exceed the scale of such a project.

Quote from yahgiggle

Moved by me as this is not a plugin its a discussion about a plugin

Please keep your posts in the right area

I was not sure: it is surely a discussion, but about an exiting plug-in, so in my view it was kind of in between. Anyway, you are the moderator and I respect your decision.

Quote from yahgiggle

@Miwarre this would have been better in your plugin post oO

About this I disagree: threads tend already to wander a lot by themselves; this is a very specific question, for which I was eliciting specific answers; so, for me, it was a separate topic.

Quote from Jon_miner

IMO, The Global WP capability should either 1) Be manageable somehow by only Admins 2) Be removed and replaced with capability of pass a personal WP to another Player 3) Be removed all together.
The Teleport plugin, IMO, is better suited for "World/Global Teleport Points".

I agree; I have replied here with more details...

I'm replying here to this post by @Jon_miner, as it seems to me to belong here more than there.

Quote from Jon_miner

IMO, The Global WP capability should either 1) Be manageable somehow by only Admins 2) Be removed and replaced with capability of pass a personal WP to another Player 3) Be removed all together.
The Teleport plugin, IMO, is better suited for "World/Global Teleport Points".

I agree; I don't know if you listed those three options in some order; according to my personal preferences, I would rate them in this order:

1) Be removed all together: this would simplify the plug-in a lot (reducing server load and occupation) and, if another plug-in is better, let's it do its job!

then, at some distance:

2) Replaced by a single player-to-player WP pass: not sure how much useful it would be and it would raise a few user experience points, as there should be some UI to allow the receiving player to accept / refuse the sending and to select the destination slot. But, if there are some requests, it might be doable.

3) restrict to Admins: basically, the reasons for 1) still apply: whether it is restricted to admins or generalised to all players, either it makes sense or not; my impression is that it doesn't.

So, I am still inclined to remove the WP sharing feature.

Quote from Jon_miner

I haven't seen anyone doing an Area Protection plugin. Is this because the Area Protection capabilities are going to be incorporated into the game?

Yes, you haven't seen it, but this does not necessarily mean that no plug-in is under development...

The fourth byte looks like an alpha value...

This has already been discussed here and here. Perhaps time for re-assessing the matter? In case, adding your ideas to those thread will be very welcome.

The fifth button from the left (the one with a red cross on it) deletes the WP currently detailed right above (or the home point, if Home is selected).

Version 1.3.1 still has the WP sharing feature and some bugs fixed; I suggest to upgrade to it.

If you need the WP sharing feature, would you mind describing the rationale in this thread about GPS changes? Thanks!

Quote from yahgiggle

saying picking the first string coming to mind is a little rude Miwarre

Sorry, I didn't intend to be rude; direct maybe yes, but not rude; if it sounded like this, I apologise.

Quote

but after all the problems with world edit and users typing the wrong thing like / weplace block /weplace block etc i decided adding /bp to the mix would case more problems than it solves.

This may be a point.

If it is of any relevance or usefulness, when I still used chat commands for the various functions of my plug-ins, I decided to use a common prefix, which was usually the name of the plug-in (or an acronim for it), reducing the possibility of conflicts ("/gps sethome", "/gps gohome", etc), but still not ruling them out definitely and so, I gave the possibility to change the prefix via plug-in settings, in case another one use (now or in the future) the same string as a prefix or a command.

Now, I moved everything to GUI, but there is still the (single) command to call up the main GUI entry point; in any case, for this, I still give the possibility to customise it.

Quote from yahgiggle

yes and is why i said two things will happen, but in the case of /select /selectarea /select area they all do the same thing, they bring up the area selecting tool oO

1) "/selectarea" is definitely a different command than the other two, as event.getCommand().split(" ")[0].equals("/select") will not match it; the other two might end up behaving differently or not according to the way each treats further words after the first.

2) Are we sure that only one instance of the area selecting tool would be created or there will be several?

3) Even if they share the same area selecting tool, once the selection completed, each will carry on its own processing of that area; not necessarily what the user may want...

This is similar to the problem with Java package names (which should ideally be unique world-wide) or with GUID (which are by definition "Globally Unique"). In both cases, some heuristics has been found to manage the problem. It should be much easier in a much more limited domain, like RW chat commands. I am not sure that picking the first string coming to mind and not yet used by another plug-in is such a heuristics...