Posts by Miwarre

Quote from zfoxfire

I'm thinking that in the future it would be nice to register something like this as a creative tool and insert it into creative mode. Instead of pressing an F key to select a tool, you click on one of many vanilla or 3rd party tool icons. Right now, this tool could be used by anyone on the server I'm assuming. It should be registerable as a creative tool so it could be limited by whoever has permissions to enter creative mode.

This is definitely a possibility! (certainly probable? ). It is already possible to test for the user being an admin (or belonging to some specific group(s) ) before carrying out the operation. Even to make this restriction configurable via a setting (as an admin_only boolean or as a list of allowed groups).

And, incidentally, congratulations for the plug-in!

I have no insight into RW internals and red51 may answer with more reliability. How I get it is that there is no explicit hard limit on poly count in RW (of course, there are physical limits imposed by the hardware used), but more polygons there are, more the performance will be affected (well, obvious! ).

60,000 seems very high for just one model to be rendered in real time within an already complex scenery. Even 5,000 might be heavy, particularly if you plan to place several models.

Ah ah!! setMouseCursorVisible() was the missing piece.

Once a GuiElement, say a GuiPanel, is defined as clickable (setClickable(true);) and appears on the screen, how am I supposed to click on it? There seems to be no mouse cursor; did I overlook something obvious?

@zfoxfire and @yahgiggle: THANKS!

Quote from Ranaarvalis

[English] How is that because if I delete a / gps setup because of wrong input or I tear it off ??

To change a waypoint, simply set it again (simpler than adding more commands to manage them).

Quote from Ranaarvalis

And how can I change the height display since it is too high for me.

You can't. This level of customisation will be added later...

Quote from Ranaarvalis

Unfortunately, I can only set 10 wp it is only 0-9 get this answer (GPS goto / wp: waypoint index must be an integer between 0-9) is a little bit I find. You are already working

Yes, this is stated in the description above. I may revise this decision at a later stage... Actually there are 9 way points as way point 0 is the HOME.

A Java plug-in to help in finding own way while moving across a world.
____________________

Version 1.4.0

This will be the final version of the plug-in; bugs, if found, will be corrected but no new features will be added (I know I am repeating this since a number of versions...)

- New in 1.4.0

*) Removed WP sharing!
*) Changed player identification from name to DB ID.
*) Added the possibility for other plug-ins to send to the GPS temporary target points
*) Added a number of public API functions for other plug-ins to use
*) Added Javadocs
*) Posted sources to the plug-in github repository.

- Features

*) Displays current player heading as a standard navigation route, position in 'standard' geographic coordinates (N E) and block altitude:

Note that internal RW positive W longitude is converted into a more common positive E longitude.

*) Optionally, in settings.properties, the display can be set to Rising World own proprietary format:

*) Define a Home position and display radial, side (to the left or to the right of the player) and distance to it:

*) Define up to 15 way points and display radial, side and distance to any of them in turn:

*) Working with the GPS is done via a GUI:
which allows to turn the GSP on/off, to set the Home and each way-point, to show/hide them. The GUI adapts itself to the current GSP status.

*) Teleport to home and to any defined waypoint. Teleporting to waypoints can be disabled for servers which do not like players popping up everywhere. In fact, it is disabled by default; edit allowTpToWp=0 within setting.properties into allowTpToWp=1 to enable (remember to reload the plug-ins or restart the server to enable the change).

*) Other plug-ins can use a number of API which GPS makes available; details in the Javadoc included in the sources; among them, an API to send the GPS target points:

*) Target points are a kind of way points; other than way points, target points are not permanent (when the player disconnects they are lost), there can be any number of them but only the first is active and can be displayed in the GPS display; once the player reaches the active target, the target is deleted and the next one becomes active.

*) The plug-in user interface defaults to English, but it can be translated in any language (whose characters are supported by Rising World) through external files by the users themselves. Details in the readme.txt file.

*) The plug-in stores player-specific data into a separate data base for each world; so, even, in a local single player context, home and waypoints defined for one world do not affect other worlds.
____________________

Important - Important - Important - Important:

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

Commands

For the 'purists' and for compatibility with well-known commands of older scripts, two commands are also available:

Installation

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

── RisingWorld
    ├── plugins
    │    ├── gps
    │    │    ├── assets/
    │    │    ├── locale/
    │    │    ├── COPYING
    │    │    ├── gps.jar
    │    │    ├── readme.txt
    │    │    └── settings. properties

*) Uninstall the old LUA version, as the two might trespass in each other garden!

*) Uninstall any older version of this plug-in! Only one version may exist in your Rising World copy / server!

Open points and known issues

*) If the player changes of heading without actually moving, particularly while flying, RW does not always notify the script which cannot update the displayed heading. This depends upon RW and there is nothing I can do about. The heading is updated as soon as the player moves.

*) After issuing the reloadplugins command from the console, an error message may appear in the chat relative to this plug-in; it is harmless and depends on the timing of the various initialisation steps which in turn depend on the server, the network and so on; just ignore it (the reloadplugins command is not intended for production anyway, but only for testing/debugging purposes).

Enjoy!

Quote from red51

What "mode" stopped showing up?

Maybe "model" was meant?

1) Is there an 'official' (or suggested) place in these fora where to put user-contributed plug-ins for the other to download?

Should they be posted in the "Example plug-ins" sub-forum? User-contributed plug-ins are not necessarily "examples", not even "exemplar".

2) Are there guide lines for suggested / preferred / requested physical details of distribution? Like: one single archive, please OR multiple files are also ok; for archives, please stick to .zip (or whatever) OR .tar.gz is fine too. And so on.

3) Is a specific form of licensing (or a range of roughly similar equivalent licences) suggested / required? Is the publication of sources a requirement or the simple .jar is already enough (as long as it works, of course)?

Comments from everybody is welcome, but some sort of 'official' statement about these points from JIW would be greatly appreciated.

Quote from red51

Right now it (i.e. onDisabled() ) isn't called, but this will be changed However, the method is not fully reliable, because if the application gets terminated forcefully (i.e. the process gets killed), or if it crashes, there is no way to call the "onDisable()" method. Currently it's only called when the plugins get reloaded.

When you reload the plugins, the "PlayerConnectEvent" and "PlayerSpawnEvent" will be called again for every plugin (so basically it's just like a server restart)

Great! Currently I use onDisable() mostly to be sure resources are released properly, should the plug-in be restarted (i.e. exactly in a "reloadplugins" perspective); if the process is killed (or crashes), nothing can be assumed anyway.

Quote from beders

I can also debug the dedicated server from the plugin project and set breakpoints, yay!
(I can provide instructions for IntelliJ if desired).

I didn't try very hard, but so far I could not set my Eclipse to debug the plug-in .jar (I use Eclipse as I already use it for other tasks).

EDIT / UPDATE: Eventually I was able to debug a plug-in running inside RW with Eclipse. I'll post details soon, but the summary is to use the 'usual' way for Java remote debugging (where 'remote' means another process, not necessarily another machine), but modifying the RW dedicated server startup script to launch Java with the debug command line options.

Another question (well, two!) about "reloadplugins":

1) While unloading, does the system call the onDisable() method of each plugin? I am not sure the method is called when the player 'closes' the world (only tried single player so far).

2) When loading the plug-ins again, does the system 'reconnect' each player to the plug-in? I mean: a plug-in may have some setup to do when a player connect to the game; when a plug-in is restarted all players are already connected, how does the plug-in knows about them?

Quote from dagoline

.... but you all know that RW is a building/survival game not a CAD programm?

Indeed! Did you mention building?

@red51, WOW! I am very grateful that, in the midst of releasing an update, you found the time to look into this matter!

Precision:
I am aware that any floating point operation involves roundings and that this kind of things requires several steps often with trigonometric functions and so on. One more reason for finding a way which requires as few steps as possible to reach the intended result!

Also, I think the level of "required" precision is visual more than instrumental: luckily, RW does not have (nor does it requires) goniometers! If it looks precise, it is precise enough. As an example, the orientation of your beam is precise enough, while the final orientation of the beam in my post near the top of this page is visibly non-precise.

Your example:
your example shows that the test orientation I though impossible to reach can be reached indeed! This, for me at least, is great new, as it falsifies a hint that the current implementation might be incomplete (and, again, thanks for finding the time to work on it!!!).

However (there was a "however" coming... ), at the moment your example cannot be properly replicated, without a list of steps. As you say: "you have to experiment with the x and z rotation a little bit". I may easily be wrong and I will try (for sure you know RW much more than I do!), but I have the feeling that the list of steps would be rather long for something which ultimately can be described at the sum of two rotations.

I believe this raises some concerns of actual usability (and of user experience, to quote a term now fashionable) for a wide range of projects (three of them I have described above).

Couple of details:

Quote from red51

all rotations are basically intrinsic rotations, but they don't work exactly as you may expect. [...] When rotating a construction element (while placing it), you basically just increment (or decrement) the particular rotation values (rotation around x, y and z axis).
When converting these euler angles to a quaternion,...

Sorry, but I beg to dissent. When increasing / decreasing one of the three values of an Euler (or Tait-Bryan) representation, in general the rotation applied is not an equivalent intrinsic rotation around the corresponding object axis.

This might be true, occasionally, for instance if the other two values are 0, but not in general; I think this to be clearly shown in this my previous post of this same thread. In other words, if <a, b, c> represents a rotation in Tait-Bryan angles, <a+n, b, c> does not necessarily correspond to adding a rotation of an angle n around the object X axis (and similarly for the other axes).

Quote from red51

since we're going to rework the construction system in the future anyway, we will check out if there is a more convenient way for the rotations

I am sure the dev team has all the required expertise, but if it can be of any help, I can try to work out the math involved in adding a real intrinsic rotation to a Tait-Bryan representation.

I don't know if anything has been done server-side, but the specific example I was quoting above now work correctly and I cannot spot any other issue. Anyway, thanks to whomever thanks are due!

At this point, I think to be ready to formalise my

1) Given a reference line

1a) parallel to one of the coordinate planes (XY, YX or ZX; the example shows a green beam parallel to the XY plane)

2) and slanted of 45° (the two blue beams of equal length show that the green beam is indeed slanted of 45°)

the goal is to place

3) one single (solid) beam rotated of 45° around the reference line (here outlined with red beams);

The 45° rotation requirement is considered satisfied when the middle vertices of the beam start and end sides are horizontal:

4) The beam shall be at least 4 blocks long and of the maximum width a beam can have.

5) The positioning and rotations shall look precise at visual inspection when seen from a distance of at least 4 blocks from any of the beam points (visible precision at super close inspection distance is not required)

6) Proof of solution shall be the list of rotation commands issued to achieve the requested orientation from the default upright orientation of a beam (as set by pressing [Backspace]).

7) The prizes for anyone solving the problem will be:
- my ever-lasting gratitude
- the satisfaction to be proven "Master of Rising World Construction"!

Note: in the pictures above, the red beams outlining the goal beam are not correct and the start and end 'squares' are actually rhombi. This is because I am currently unable to achieve the request orientation and I believe it cannot be obtained with the current RW implementation.

I hope to be proven wrong!

Quote from Deirdre

@Miwarre Your explanations are very complicated for me. I'm a builder, no mathematician, no architect, I'm only playing with one, and trying to translate it in my language and in my understanding, but I'm trying to help as well as I can do. When I see the pictures I can imagine it better.
I have the wish for more precision, more measurements, bigger glass size for instance. Who really needs 0,5° differents, if he wants to build no ogival or absolutely accurate.

Thanks for the reply @Deirdre. I fully understand you; the whole matter was much like black magic for me too, when I started. So, I'll try to elaborate on the final comments of my previous post.

1) Precision is not optional: if you don't need it and it is there, it does no harm; but if you need it and it is not there, you are out of business. Also please note that I am not speaking of residual approximations: the beam shown in my previous post is several degrees off, both along its own Y axis (as shown in the final detail screen shot) and along the world Y axis (as shown in the penultimate picture). I'll make a few examples, not theoretical but from my actual experience with RW:

1a) The beam we are mistreating all along this thread might be the corner beam of a, say, 4-sided roof as in:

Once I needed to use it, rather than in "square section" as shown here (with its edges two above and two below), in "diamond section" (i.e. with its edges on top, middle left, middle right and bottom, i.e. rotated by 45° around its length (Y) axis): I had to give up because the intended orientation was practically impossible to obtain without it being visibly off the mark.

1b) Another time I was working with dormer-windows:

but the junction between the roof side slope and the dormer-window roof slope was impossible to reach decently; so I had to 'cheat' make both as larger rectangle and close the access to the inside of it, as it was a mess of intersecting rectangles:

1c) Then, I tried with 'Gothic' tracery windows, just a simple one; I hoped to use beam again in "diamond section", but again the result was a mess of mismatching beams, so I gave up again and resorted to "square section":

This are all practical cases, involving a limited number of pieces and not really in complex relationships to each other (at least easy to visualise).

2) Counter-intuitiveness: In the current implementation, the rotation commands rotate the object around non-evident -- and in several cases counter-intuitive -- axes: in general, neither the object OWN axes or the world 'global' axes, which are the reference systems that a user can visualise more easily.

3) Incomplete?: I am not 100% sure of this, so I still add a question mark. However, the fact that nobody was able to solve the relatively simple problem I posed at the start of this thread makes quite serious the hypothesis that the current implementation is incomplete and does not allow to reach all the possible orientations a solid body can assume.

I also ask to try the example I describe in section [II] of my first post: it shows a case when one rotation around one of the possible axes is lost, as this also is a serious hint about the potential incompleteness of the current implementation.

4) Unnecessary: Above anything else, all of this is unnecessary, as far as I can tell. Object-relative reference systems are very common and relatively easy to implement; they allow to add rotations which are really and precisely around the object OWN axes (also called intrinsic rotations), which are much easier to visualise, as you have the object before your eyes. They can also be implemented in a way which is really complete (demonstrably).

They would allow to easily (at least much more easily than now) and precisely reach any orientation you can visualise. Under these context, the 1° degree precision now available would be enough for most objects, surely for the 3 smallish objects I show in the pictures above.

Now, jMonkey (the framework RW is developed upon) comes with built-in support for them and I cannot think of a reason strong enough for NOT using it, as RW apparently does now.

Finally, while I am aware that the attentions of users is currently toward other aspects of the game, the building system is and will remain one of the RW strong points and dragging along the (unnecessary) weak points I describe above does not seem to me 100% wise. So, I feel the priority of this aspect should be raised.

Thanks for reading another over-long post! If I made errors or arbitrary assumptions, I will be glad to learn more!

Oh well, this is going to be long and boring; please bear with me... I have warned you If nothing else, if you care, please read at least the final comments. Thanks!

Thanks to @Deirdre for the steps she provided. I had a look at them, re-played them locally and I learned a few interesting things.

Step 0: a beam (0.5m wide, 3 m long, if you care) at default, un-rotated orientation. This is how it looks along the Z axis (I tried to take the screen shot as orthogonally as I could and I overlaid the axis names for added clarity):

and along the X axis:

So far nothing strange.
________________________________________________________________

Step 1: 3 x UP arrow (according to Deirdre list). This should mean +45° around the X axis (currently, as the beam is not rotated, the axes of the object and of the world coincide). View along the Z axis:

and along the X axis:

Everything as expected!
______________________________________________

Step 2: 3 x PgDn arrow: this should mean -45° around the Z axis. View along the Z axis:

And along the X axis:

and also along the Y axis (looking down):

Now things start to look strange. From the screen shots a sharp eye may be needed, but while viewing the rotation on the screen, it is rather clear that this rotation is neither around the object Z axis or the world Z axis; it looks like around some undefined axis which presumably depends on the previous rotations.
__________________________________________________

Step 3: 4 x Left arrow: which should be -60° along the Y axis. This is rather clearly the world Y axis, not the object axis (or any variable axis resulting from 'obscure' calculations). View along the Z axis:

View along the X axis:

And view along the Y axis, showing that the object is not actually parallel to the XY plane::

Finally, a detail showing that the 'tilting' of the beam around ITS OWN Y axis is far from being 45°:

_________________________________________

Comments:

1) The implementation, instead of the X, Y, Z axes (as described in the F1 help screen), rotates the object around axes largely counter-intuitive and very hard to visualize; they are surely the result of internal calculations, but from the user perspective look arbitrary.

For what is worth (and from some @red51 comments above), I suspect that the implementation simply alters the X, Y or Z value of an internal representation in Euler angles, rather that implementing rotations consistently intrinsic or extrinsic. A hint might be the suspect of gimbal lock shown in OP [II], as an Euler angle representation may suffer from it.

2) By small (non-intuitive) corrections, the intended orientation might perhaps be obtained (still not sure, though). Each correction will however affect the orientation of the object around all the 3 axes and will require further corrections. It is not a matter of having half degrees available, it is a potentially never ending chase of corrections after corrections.

3) JME directly supports consistent intrinsic rotations and one could wonder which reason is strong enough to ignore this easy support. If Euler angles are preferred to persistently store the rotation data of an object, as they are the most compact representation (sparing one floating-point value over quaternions and 6 f.-p. values over matrices), the conversion could happen when writing the data to a file.

4) I am still not sure that implementation is logically complete (the suspect of gimbal lock is a strong hint that some orientation cannot be reached); right now, it definitely looks operatively incomplete, as a simple case like the one I pursued in this thread is proving very hard to reach, possibly impossible to reach with the needed precision.

5) I am glad that all of this seems not to affect many users (those looking for 'balls', as @yahgiggle says ); still the eventual lack of precision does affect architectural realisations.

6) I am aware that angles, quaternions, Euler angles and so on are not glamour nor make for a popular update; still, the building capabilities of RW will remain as one of its strong points and I feel that this matter should be raised a bit in priority.

@yahgiggle & @Deirdre: I appreciate the time spent by those (few) who seem to care about this point which, if true, would be a serious flaw in a fundamental part of RW.

However, I am forced to note that so far nobody posted a list of steps to reach the test orientation I described above; this by itself would show that I am wrong to worry (and would teach me something I could not discover by myself).

And sorry but an approximation is not enough; even with the default setting of 15°, it should not be a problem to achieve angles which are integer multiples of it, as 45° is (yes, there might be internal floating point rounding errors, but if they show through in a process that, in the optimal implementation, is made of just TWO steps as my test orientation does, then something else is seriously screwed).

I am also surprised that nobody seems to care about the case I describe in part [II] of my original post. In my point of view, this alone shows that here something is not working as it should.

So as far as I am concerned, the issue is still pending (and incidentally, I know how to use str/l/p as it can be seen in the summary of their functioning I posted a little while ago).

Of course, thanks again for all contributions!

EDIT: Cross-posting!!! Deidre posted a step list while I was writing this post. I'll check it ASAP! Thanks!

I know there are many other pressing things, but is there any new on this?

Well, it seems to me this bug reappeared !

Some servers which appear in my MP client TAB "History" and to which I can connect from there do not appear in the main server list, neither with "Alphabetical" or "Player count" sorting.

An example of this is the server named "DAY [ONE] ..." with IP 37.187.129.33:4255

@yahgiggle: thanks for the reply and for the time spent on this.

From your screen shot it is not easy to appreciate angles, so I may be wrong, but the rotation around the beam Y axis does not look as it be precisely 45°.

If you could list the individual rotations you did to reach the shown orientation (I don't think they are covered by some kind of intellectual property ), I could reproduce and tell if we are speaking of the same thing or not.