Posts by Miwarre

As they begin to be quite a number of them, the github repository for the source code of this plug-in has been renamed; now it can be found at:

https://github.com/mgavioli/RisingWorld-RWGui

As they begin to be quite a number of them, the github repository for the source code of this plug-in has been renamed; now it can be found at:

https://github.com/mgavioli/RisingWorld-PlanksNbeams

Quote from angriff

I believe it is related to the world database miswrite and not ABM.

This would be a rather important bug ! If you are aware of systematic world data base "miswrite"s, I think you should report it with the maximum of info for correcting it.

Quote from angriff

I is possible to edit the database if you talk to you admin them may be able to remedy it by making it go away permanently.

Depending on the host configuration, world data base editing might be possible or not:
*) with a commercial server using MySQL, the data base is usually not accessible directly;
*) even with SQLite DB, as commercial non-dedicated hosts usually do not allow to run arbitrary software, it may not be possible in loco.

But even when possible, manually editing the world data base is definitely not advisable: data consistency and referential integrity may be subject to restrictions and constrains unknown to the person editing it and the resulting DB may be in worse conditions than before and even unusable.

Quote from sharkbitefischer

if I use the rw setting for the gps it seems to be reporting proper cords now sorry for the bother.

Well, I know I'm being fastidious ( ), but the default GPS display are "proper" geographic coordinates (at least in the sense of "usual"); those in the RW debug display are not (they serve a different purpose).

But I understand the usefulness of having the same display in both and, as the GPS display can be configured while RW cannot...

Quote from Trevor

Hi,

I understand that development of this plugin has ceased, however I have a couple of questions.

1. Is it possible to enlarge the size of the text display? My vision isn't so good and I find it hard to read the text.

It would be possible to make the text size settable, but it would very probably be a server-wide setting, common to all players; not (or not easily) on a per-user basis, as this would require additional GUI to allow the player to set these parameters.

Quote from Trevor

2. Is it possible to add tooltips to the GUI?

I would have liked very much to add tooltips but, as far as I know, the API does not support hovering and does not notify the plug-in when it happens; so, no, I do not think tooltips can be added with current API.

Quote from Trevor

3. If you do not wish to add new features, will you release the source code so that someone else may take over the project? I don't know if I have the ability, but I would like to try adding some features.

Thanks!

I'll upload the source code to my github space rather soon, where other plug-ins of mines are already available.

Quote from sharkbitefischer

This seems odd but it looks like north/south and east/west settings are swiched in the on screen read out of GPS. The east is reading south in gps and so forth.

It seems odd, but RW F3 display switches N/S and E/W indications! E/W comes first and N/W comes third (after the altitude), against all geographic habits...

Quote from sharkbitefischer

Positive is also reading negative in the readouts as compaired to the f3 readout on the first line of data.

Again, RW F3 display exchanges the sign of the E/W component, as it considers W positive and E negative, again against all geographic habits.

F3 display is actually a debug display and it does not show geographic coordinates (as the GPS plug-in does), but rather the components of an oriented reference system used internally in the game and which has a different handedness from the usual geographic coordinate system(s); whence the difference. I assume that in a proper UI (rather than in a debug output mostly intended for the developers) RW would use the 'right' geographic coordinate practices too.

If you want to have GPS to show the coordinate in the RW 'native' format, set the coordNativeFormat of the "settings.properties" file to 1, instead of the default 0.

Quote from sharkbitefischer

also we have been getting this errorlog for a few days too.

errorlog_1530134442950.log
errorlog_1530223163970.log
errorlog_1530242434387.log
errorlog_1530246277849.log

This may happen when the reloadplugins console command is used, depending on the order in which the various listeners are called (which is not constant).

It should not have any adverse effect, though, beyond spoiling the log; can you confirm?

Quote from angriff

Also I see that area protection and some third party plug-ins load tons of lines in the logs that appears to slow down boot into the game

I do not understand what you mean here: which "lines" the plug-ins "load" and how could this "slow down boot into the game"?

(Incidentally: the current Area Protection script is not Java but LUA and, as such, none of this discussion applies to it.)

Quote from angriff

Minos reply excerpted.

To be able to use all the classes of a package you need to import it as java.sql.* so that the import includes all the classes of the package and not just one.

having said that though it is not good practice to import huge packages if you are only going to use 3-4 classes thereof

Yes, this is not considered good practice or good coding style. However, import's have no impact on memory.

Quote from angriff

I also create a lot of little plugins for my server that use common libraries.

"Lots of little plug-ins": this may have an impact on load time (and marginally on memory occupation). If a plug-in is split into two covering the same functionality, loading will require more file accesses and so on and will be (slightly) slower. Each plug-in also has some standard boilerplate contents and some "architectural sugar" which needs to be repeated for each plug-in. So, excessive fragmentation may be a (small) problem, if does not correspond to a functional separation.

"Common libraries": what do you mean by this? Which libraries beyond the Java own libraries and the RW API jar (both of which are loaded always but only once for the whole RW process)?

If you add third party libraries (which probably you cannot install in the Java VM of a commercial game server host), this may affect loading time and memory occupation (it shouldn't affect performance: if the methods you use from them are really needed, that CPU load is going to happen anyway...).

Quote from angriff

I have a question about plugins and if there several plugins that load the same API codes . are they uploaded once or multiple times for each plugin reference in memory?

What you mean by "load the same API code"? the import statement? import's are not "loaded" and do not occupy memory at run time, they are only used at compile time to resolve external identifiers.

@Zendoric: you are right that the player config file is stored on the player client computer. However the plug-in is run by the server on the server host and, as such, has no direct access to the client file system (not should have it, as @Minotorious pointed out).

Quote from Minotorious

Just to add my cookie to the discussion, I would find it dangerous if a plugin could somehow access my filesystem when I connect to a server without my permission at least

If I consent to it then it is my fault if something goes wrong

Edit: I see on the Javadoc there is a Player.setOption(blabla) method so why not have a Player.getOption(blabla) method too to get such settings from the client?

Well, in a sense, RW servers are already impacting heavily on your file system !

But, it seems to me nobody is suggesting RW clients should forward remote file system access to RW servers; I was suggesting (and you added relevant details) that the server can ask the client for a specific setting value and forward it to the plug-in.

This could follow the pattern of a Player.getOption(int value_ID, Callback<??>callback) method parallel to Player.setOption(), but it would require a callback as the operation is asynchronous and the answer from the client can come at any moment.

@Zendoric: I don't think your example is going to work. The config.properties file being looked for is in a different machine (the client connecting to the server): no file operation on the server local file system is going to reach it.

So, the server has to ask the client to send this value and then forward it (possibly via a callback function) to the plug-in.

In a test server I was given access to by the kindness of its owner, I tried adding my own UID to the owner's:

admins=<owner_UID>,<my_UID>

as a consequence, neither of us was any longer recognised as an admin; when I put my UID only, I was recognised as an admin.

Shall we deduce that the "admin" line of the server.properties file only accepts one admin UID?

P.S.: I searched the fora for a similar topic, but I didn't find any; either my search skills suck or the issue is new and possibly related with the change from player names to UID...?

Thanks, @red51; this will definitely help!

Sorry to pollute this thread with an English post. Time ago this discussion tried to define the necessity, usefulness, ... of a money system in RW. After two years, it may still be an interesting reading...

Just to complement Minotorious' great description, "Name_of_Plugin" is the "name:" entry of the plug-in plugin.yml.

As plug-ins are unlikely to go or change while RW is running, you may rather safely get the target plug-in at your plug-in OnEnable method and keep it in a global variable:

@Override
public void onEnable()
{
	targetPlugin = (TargetPlugin)getPluginByName(targetPluginName);
	// more initialisation...
}

You may need to add the target plug-in in your IDE as an external Library / JAR / ... in order for the target plug-in specific methods to be known and callable.

Quote from Trevor

Ah, OK. I hadn't seen the triangle elsewhere so I thought that might've been a custom shape. Thanks.

It is a shape you can only get through the console, but it is a built-in shape.

You know where the DB is, don't you? So, one solution is to hard code that (relative) path into the reading plug-in.

If you really want the writing plug-in to be free to create the DB wherever it likes, you have to code the reading plug-in to connect to the writing plug-in and ask for the DB path.

But at that point, I think it would be cleaner to let the writing plug-in to do all the DB work and have the 'reading' plug-in to directly ask for the information it needs to the 'writing' plug-in, without bothering with the DB path at all.

Quote from Trevor

The current triangles are isosceles which are wonderful but limited in their application. It would be wonderful if you could add right-angle triangles as well.

Cheers!

Well, shapes are defined by RW; this plug-in just adds the texturing.

Quote from Minotorious

But then the question how do I distinguish between all my child elements since they don't have an individual attribute name anymore

I see your problem; I was distracted by RW-Gui, which has a user-defined ID for each GuiElement and reports the element ID for each event; in this way there is no need to store anything, just checking the ID.

As the default GUI elements have no ID and one has to rely on PlayerGuiElementClickEvent.getGuiElement() or PlayerGuiInputEvent.getGuiElement(), I see the need to store each GuiElement separately.

One could perhaps use the order of the List returned by getChildren(), but I don't know how reliable it would be.

Or one could build his own ID system as RW-Gui does...

As far as I can tell from 'outside':
*) fps is local to the client and should be totally unrelated to number or nature of player attributes (server side);
*) server performance should also not be substantially affected by how GuiElements are stored; it will be affected by their existence and management, but I would not expect how they are stored would change this very much;
*) the time necessary to "connect" to a server (from clicking [Connect] to starting playing, which is much more than simply establishing a connection) may be slightly longer, but as there is a significant network load, it will possibly not noticeable in itself.

A point I would raise, though, is if you really need to store each of hundreds of GuiElements as a separate player attribute; I would expect them to combine into larger GUI units (dialogue boxes, windows, menus, ..), which would be possibly more reasonable to store as player attributes.

Or, as an alternative, only a limited number of major "GUI entry points" (starting windows or perhaps only one "top menu"?) could be stored per player and from them other GUI windows constructed on the fly with the player-specific data.

So, there is ample margin for experiment and optimisation...