Posts by Miwarre

Quote from lenko

The problem was quite simple. In your settings.properties stands for the on and off the waypoints still both times the "0" and not as in your description the "1" and "0". That was all.

Oh, I see; thank you for clarifying.

Well, in the comments within the settings.properties, the allowTpToWp item is described as "0 = not, !0 = yes" where "!0" means any (integer) number other than 0, according to a notation which someone already criticised as too specialistic.

I'll correct it in the next release (IF any); for the moment being, I apologise for the obscurity and I hope the description in the first post will make things clearer, also considering that this plug-in seems to me more documented than most other scripts / plug-in so far...

@Deirdre, @lenko, @Ranaarvalis: I tried to follow the above discussion about allowTpToWp, but I could not understand if anyone was complaining about some problem or not. If someone is facing some problem, would it be possible to have a summary in English? Thanks,

About the error occurring with reploadplugins, as described in the plug-in description at the start of the thread, it is harmless (reloadplugins is not intended to be used in production anyway).

Can you elaborate on "cannot get to work"? What does not work? Is there any error message? Does the new level occur in the level list? In fact, which is the exact sequence of steps which leads to unexpected results?

Sure it is the same player? Sure it is the same attribute name spelling (capitalisation included)?

Quote from Ranaarvalis

Sorry habe heute auch das problem gehabt aber nicht mit deinem plugin ich denke mal das es an rw selber liegt

hier ein teil der log luste den server neustarten

07.11.2016 17:58 server.Main
SEVERE: Fatal error occurred!
java.lang.ClassCastException: [Lcom.vistamaresoft.gps.Waypoint; cannot be cast to [Lcom.vistamaresoft.gps.Waypoint;
at com.vistamaresoft.gps.Gps.setGpsText(Gps.java:442)

Display More

Sorry, I do not understand the German text.

If this happens after a reloadplugins console command, it is expected and not harmful, as stated at the end of the GPS description post. This assuming you are using the last version of the GPS; if you are using older versions, please update (the existing data base will remain untouched).

(FYI, it has to do with the fact that occasionally, after reloadplugins, the plug-in might receive some events from the server before initialisation is completed, depending on client-server communication timing); the worst which can happen is that the first player position might go undetected by the plug-in -- Also, please remember that reloadplugins is not meant to be used in production, but only during test and development, as the accompanying console message clearly says).

Good to know, thanks!

Thanks for your reply, @red51.

I think it might be important to know if an SQL command did 'go through' or not. Possibly it is not necessary to change the exception pattern, 'simply' returning a boolean or an error code int might be enough to let the caller know if everything went fine or not.

Perhaps I made it to look too tough?

To make things lighter, this how is the current Menu component looks-and-feels like; the requesting plug-in sets the title and adds the items and the back-end GUI plug-in displays it, manages user interaction and notifies the requesting plug-in of the user choice;

*) items are clickable,
*) the number of items is unlimited, if they does not fit in a certain height, the list can be scrolled up and down through the arrows, which are enabled an disabled automatically;
*) the [X] button closes the menu without making any choice.

(in the screen shot, the max height has been greatly reduced to have a smaller and clearer image)

Really nobody is interested in helping with development and testing?

Quote from Captian_Cornball

whoops Have my own money system, Mine unfourtueatly has toe be integrated with the main Plugin

All money system are likely to have to be integrated with a main plug-in.

This is exactly the purpose of a back-end plug-in: the main plug-in establishes its own policies, interacts with the users and, when it needs a 'bank operation', it calls the relevant method of the bank plug-in which does the low level work (persistent accounts, low-level data base access, consistency checks, ...).

Then, of course, everyone is free to make his own decisions.

Quote from Valeara

I created my own multiplayer server (first time I've ever done that for a game ) and the only way I can get the server to shut down after I open it is to shut down my computer. I have opened the command prompt and entered shutdown and "shutdown [server]" along with many other random shutdown and restart and reboot combinations and can not get it to shut down or restart or anything unless I turn my PC off. I kept thinking I was doing it wrong because everytime it tells me command not found and yet other commandside like "mark" or "saveall" even work. I am the admin and have all my permissions turned on. Yet it will not work for me. Help me please ..

Hmmm...

Neither the win_startscript.bat or the mac_startscript.sh, which I assume to be the supported way to start the server under those OSes, have the so handy start, attach, restart, stop sub-command that the Linux script has.

Is this intentional or forced by the limitations of those OSes?

(I tried hard, but I cannot resist: Linux wins again!)

A (mostly) back-end banking plug-in, i.e. a plug-in which does quite little of visible to the player and rather provides services for other plug-ins to use. Only one copy of the back-end plug-in needs to be present in a RW copy (MP or SP) and all other plug-ins can 'use' it if they need it.

It is an example of a simple implementation of the Banking Interface, presented in this thread, and modelling the concept of a Bank in which each player of a (MP or SP) server has an account (with an optional initial amount); other plug-ins, by calling the public methods defined in the interface, can access its various services. So far, the following are implemented:

*) query the currency name and symbol
*) query the balance of an account
*) query the availability of a certain sum on a certain account
*) grant money to a player (if admin)
*) transfer money from a player to another
*) as all transaction are logged, ask for a 'bank statement' over a certain period of time

The name of the currency and its symbol as well as the initial amount granted to new players can be configured for each RW copy.

The basic idea: See the thread quoted above for more details about the very idea of a Bank Interface. Other plug-in, providing a money system can rely in the same Bank Interface to provide similar (or more!) services in a way which consumer plug-ins (plug-ins needing some money services) can use for their purposes.

An example of a consumer plug-in (i.e. a plug-in using these services, if available) can be found here.
____________________

Version 0.2.0:

Player-side the plug-in provides only a minimum of interface, with a main menu activated with the /bank chat command:

where the player can ask:
- his current account balance
- the bank statement over a period of time:

- transfer money to another player:

- if an admin, grant money to a player (from the "World Treasure"; screen similar to the above)
____________________

Important - Important - Important - Important:

In order to work the plug-in requires the GUI back-end plug-in 0.4.0 available here. Install it at the same time of (or before) installing this plug-in or the server will crash at start-up!
____________________

Version 0.2.0:
*) Added bank statement
*) Fixed localised string mismatch
*) Upgraded to RWGui 0.4.0, including window 'display stack'

A back-end plug-in (i.e. a plug-in which does nothing visible by itself, but provides other plug-ins with additional features).

It is currently used by my plug-ins only and it is required (just once!) to run some of them. Developers of other plug-ins are welcome to use it too!

Version 0.5.1

File rwgui_0_5_1.zip updated with the two images missing in the previous release!

Implemented:

*) Modal dialogue box, with title bar and close (X) button.
*) 'Automatic' horizontal, vertical or tabular layout of collections of GuiElements.
*) Check/radio boxes
*) Modal menus, with title bar and scrollable if "too long"
*) Modal menu to select a player
*) Modal message box (with optional timed auto-closing)
*) Modeless informational window
*) Message box
*) Title bar with optional close button
*) 11 small icons for basic interface elements (close button, arrows, check and radio buttons)

0.5.1 change log:

*) Fixed a possible null pointer exception with GuiVerticalLayout.getItemId()
*) Simplified image loading
*) Added GuiLayout.getChildFromId()

Download link at the bottom of this post. Version 0.5.1 is backward compatible with version 0.5.0, 0.4.0 and 0.3.0.

Installation (for everybody!)

Extract the files in the ZIP placing the whole rwgui folder into the plugins folder of RW (if the plugins folder does not exist, just create one). The resulting hierarchy shall be:

── RisingWorld
├── plugins
│ ├── rwgui
│ │ ├── assets
│ │ ├── rwgui.jar

This is all!

The plug-in has no command, as it is not intended to be invoked by players, but used by other plug-ins.
____________________

Use by other plug-ins (for plug-in developers)

Warning: This is very experimental work, code is under active development!

Concept:
A plug-in which does nothing by itself and rather provides classes and tools for other plug-ins to display and manage GUI 'containers', freeing other developers from the implementation details of (part of?) the GUI and also potentially providing a consistent user experience to players.

It is a separate plug-in, which needs to be installed only once in RW and which any other plug-in can use without 'including' it in its own package.

Context:
There are limitations and some 'dirty code' to work around the current RW API limitations, but I have seen in practice that it is possible for any plug-in to request a GUI object from this new GUI plug-in and to be notified of user selection.

According to my experience, it also simplifies noticeably some repetitive tasks in GUI implementation.

Setup:
1) The rwgui.jar has to be added to the project of your plug-in and then it has to be somewhere in your hard disk. The details of how to add it depend on the specific IDE you are using, but the steps are exactly the same as for the Rising World own PluginAPI.jar which your plug-in should already know about.

This is only for the compiler to know about rwgui.jar internals; rwgui.jar itself shall not be included in your final .jar or shipped with it in any way.

2) The rwgui_<version>.zip shall be unZIPped in the Rising World plugins folder (as described in Installation above). This will be the care of the server owner, though: do not include it in your plug-in!

Documentation: the RWGui_doc.zip contains the Javadoc of the RWGui class and sub-classes in HTML format. Everything needed to use the GUI back-end is there!

Samples: The following plug-ins use RWGui. Add your plug-in to the list!
*) GPS
*) Planks 'n Beams
*) UPS
*) simple Bank
*) Plug-in Central

Sample sources: the sampleDlgBox_src.zip file contains the sources of a very minimal, but complete, plug-in exemplifying the use of the GuiDialogueBox class.

Comments and proposals for improvements and extensions are welcome!

Source code

The source code of this plug-i is available on github under the Creative Commons by-sa 3.0 license.

In the Database class, executeQuery() may throw an exception, while execute() and executeUpdate() do not.

Actually, any of the three can 'go wrong'' but, for the latter two methods, exceptions are caught somewhere before returning (and show up in the log). This means that the caller cannot know if something did go wrong or not.

Is this by design? Is there any compelling reason to hide the outcome from the caller?

The thread tag says "German", sorry for answering in English.

This is one of the reasons why in my Java plug-ins I am moving away from chat commands using GUI's instead as far as possible (as well as in order to reduce load on user memory ("which was the command to...?"), typos and so on).

In the few LUA script I did, my approach was to have a common prefix -- related to the script name -- for all the commands of a script and use additional words for specific commands: "/gps sethome" "/gps setwp" and so on.

As I was saying in this oldish post, I see the possibility to completely by-pass chat commands, adding to the API a "main GUI entry event" a plug-in can respond to displaying its own GUI "main menu"; from there it would be possible to navigate graphically the plug-in functions (equivalent to nowadays chat commands).

An in-game command (it might be a short-cut) could display a list of plug-ins having this function to select from and eventually dispense with any typing, remembering, name clashing, ...

Probably not very urgent, but I still see this as a possible, positive goal.

Oh, I see!

"!0" in the comment means "any (integer) number other than zero", it can be "1", "2", "1000000" or any other integer number, but it HAS to be a number, "!0" is not a number.

!0 as which setting?

Things could go faster, but real life sometime kicks in, this time under the appearance of a flu... Anyway, this is the "Dialogue Box" with the Area Properties:

where it is possible to set individual permissions by clicking on them. It took me a while to get it right, but it seems to work now.

And, of course, the UI is completely translatable through external files which can be added by the users without requiring a change to the plug-in.

Compared with the development of the GUI, the implementation of the code for the actual protection is going to be a breeze...

Quote from shortybsd

Either way you'll probably beat the devs on release. I need one other than this Lua one. If you need someone to demo it, let me know

As it is going to be rather complex (at least to code, I hope not to use!), beta testing will be important.

More to follow...

An Area Protection plug-in is under work by me (see here) as well as, it seems, by the dev team themselves (they will probably beat me, but I am leaning a lot working on it, so I go on).

Also the old compass (and similar) LUA script can already be replaced with the GPS plug-in (now that some problems have been solved).

I think a teleport plug-in will appear soon.