Posts by Miwarre

UPDATE ABOUT moveto():

More experiments with Model.moveto(). It turns out that, as described above, the following has no visible effect, i.e. the model remains in its position:

Vector3f pos = model.getPosition();
pos.y += (up ? +10 : -10);
model.moveTo(pos, 0.01f);

If however, later on, the model is removed from the player's world and added back, it appears in the correct, moved to, position. So, it seems an issue with the player context not updating its scene.

With any of the following, the model jumps instantaneously at the final position (I have no idea of the scale of the speed parameter, but I assume 0.01 should be a rather slow speed):

Vector3f pos = model.getPosition();
pos.y += (up ? +10 : -10);
player.removeWorldElement(model);
player.addWorldElement(model);
model.moveTo(pos, 0.01f);

Vector3f pos = model.getPosition();
pos.y += (up ? +10 : -10);
player.removeWorldElement(model);
model.moveTo(pos, 0.01f);
player.addWorldElement(model);

Vector3f pos = model.getPosition();
pos.y += (up ? +10 : -10);
model.moveTo(pos, 0.01f);
player.removeWorldElement(model);
player.addWorldElement(model);

In practice, there seems no way to have a visible moveto() effect.

In addition, while for Model.setPosition() and Model.setRotation(), the remove from world - add back trick seems to work, having to keep track of to how many players (and which ones) have been added each of the models and toggle each model off/on from each of its players for each model movement becomes rather inconvenient: shouldn't the API take case of this?

Just FYI, I am trying to implement elevators, where a number of elevators are present, individually moving and visible to/usable by a variable number of players...

Quote from red51

We will put that on our list Especially for very small icons (16x16, 32x32 etc) it's indeed a good idea to use sometimes like an atlas texture.

Thanks for the reply. Not urgent, I understand, but useful in the long run.

The possibility to select into a GuiImage only a part of the image (a rectangle) would be rather useful. The use case I have in mind are "image atlases" with icons, buttons, etc, compacting in a single file a collection of images to be shown selectively.

Of course, the final visible effect can already be reached with several separate files, one for each image.

However, particularly with GUI elements, which tend to be many and small, the overload in file size (as the file header is significant in rapport to the total file length) and above all in connection time (each image requires to establish a server=>client connection) could be significant.

Version 0.3 Available!

Changes:

*) Added support for translations: the user interface can be translated by the users themselves adding external files.

Out of the box, only English and Italian are provided (the languages I feel confident enough with). A few additional language files are provided ready to contain texts (for German and French, in France and Canada variants) but I have not translated them; it would be awesome if anyone could translate them and share.

This is an example of the GUI in Italian:

*) Increased the number of way points from 9 to 15.

*) Corrected a few bugs...

See the first post of this thread for details and download.

Enjoy!

Quote from Deirdre

This is maths I see. What I meant is every side of a block (block has a cube form) has 0,5 m from every side I have a look at it.
I didn't see it in any mathematical form.

I suspected this, but given the the above discussion about the 'actual' block size, I preferred to be explicit. Anyway, the important is to understand each other...

Quote from zfoxfire

Miwarre, isnt a block 0.5m cubed?

No, a block is not 0.5m³; as its side is 0.5m, its volume is 0.5 x 0.5 x 0.5 m³ = 0.125m³.

Quote from Deirdre

But I don't understand what you mean with "setr" and steps for 90°. 2 steps to get 90° of a circle or what do you mean?

Sorry for being so late, I didn't notice your last question when you posted it! What I mean is that, in order to rotate a piece by 90°, as many steps are required for each setr setting level

Quote from Eomaetheus

Thanks for posting this! Do you know if there are ways of resizing blocks? I understand that block dimension is uniform across all block types and that block size can be mimicked using altered dimensions of beams, and even planks to an extent, but I wasn't sure if there are similar console commands for blocks.

As far as I know, no, blocks cannot be resized. In fact, they are a kind of 'unit measure' for anything else. Developers have repeated that the building system is being reworked and will be the topic of a future update; there have been suspects that this update will allow bocks to be resized, but so far nothing is certain.

Quote from Captian_Cornball

at EffNet.EffNet.onCommand(EffNet.java:133)
... 9 more

This is the line of your source related to the error; I would look in it for a cause.

I would look at line 133 of file EffNet.java.

Maybe, I miss something, but it seems to me that the World3DModel methods setRotation(), setPosition() and moveto() have an issue quite similar to the one described here and already solved (thanks again, @red51!).

Simply put, if those methods are called after the model has been added to a player's world (player.addWorldElement(model);), they have no visible effects. But if, contextually or afterwards, the model is removed and re-added, the changes show up. Note that any of these code snippets work correctly and they all seem equivalent:

model.setPosition(modelPos);
model.setRotation(modelRot);
player.removeWorldElement(model);
player.addWorldElement(model);

where first model properties are changed and then the model is removed and added back. OR:

player.removeWorldElement(model);
model.setPosition(modelPos);
model.setRotation(modelRot);
player.addWorldElement(model);

where model properties are changed while the model is removed. And even:

player.removeWorldElement(model);
player.addWorldElement(model);
model.setPosition(modelPos);
model.setRotation(modelRot);

where the model is removed and added back before changing its properties (which greatly surprises me , but probably the various operations are queued, rather than blocking).

I have tried moving the model changes to a separate thread (one never knows...) but it seems to make no difference.

Exemplifying moveto() is less easy, as the remove, change and add back need to be at different moments (to give moveto() time to go on), but it follows the same pattern.

Note: I have only tried the Vector3f and Quaternion overloads of those methods, so I do not know if the overloads with separate values work differently, but I do not expect they do.

Am I overlooking something or there is actually an issue?

Welcome back, @Chrisx84!!!

It is rather simple: add another onGuiElementClickEvent(GuiElementClickEvent event) to the same class containing the current onCommand(PlayerCommandEvent event); in it you can test which GUI element has been clicked with the event.getGuielement() method.

Of course, for this you need to move the GuiTextField label, GuiLabel okbutton (and possibly also the GuiPanel panel) variables from local to the onCommand(PlayerCommandEvent event) method to class-wide fields, so they are kept when the latter method ends.

Thanks for the reply. I suspected this when I noticed that the textures are client-side and not server-side, so some server -> client protocol is required to display them in the client from a script on the server, file names are not enough.

Crossing fingers...

Quote from lenko

Ist es so gewollt das die erweiterte Anzeige für Home punkte und Wege Punkt beim neuen einloggen wieder neu eingestellt werden müssen.

Sorry, according to Google this translates to: "Is it so wanted that the extended display for home points and waypoint when the new log again have to be set again."and I am not sure what it may mean.

Do you mean that, if you set home/wp in a world, when you log again to the same world, they are lost?

Quote from yahgiggle

That is awesome work Miwarre

Thanks!

Is it possible to make an ImageInformation out of in-game built-in textures? (I tried to understand how to do this by myself, but I failed so far).

I see at least 2 scenarios:

1) Displaying the texture as it is (i.e. a simple, flat square) in a GuiImage object

2) Attaching the texture to a custom 3D model. I can imagine UV mapping would be tricky, but it would be useful to ensure the model has the same look of related 'native' objects.

Version 0.2 Available!

Changes:

*) Added a new GUI panel which allows to do the same as chat commands via point and click (chat commands are retained, though, for the joy of purists... :evil: )

*) Vertical position of the GPS info window is now configurable

See the first post of this thread for details and download.

Quote from lenko

I mean the standard coordinates you see also when you press F3.

Oh, I see... well, those coordinates are quite non-standard, as longitude increases toward West (and it is listed before latitude, against the commonest usage). Mines are more standard (assuming a flat Earth, of course...)

Quote from lenko

How and where to set the Gui to standard?

Not sure what you mean: which standard?

Quote from lenko

Can I change the position of the Gui on the screen?

As I replied to Ranaarvalis, at the moment you can't, but I am working on this. A new version is on the way...

GREAT! And it works! Thanks.

I noticed a strange effect: while changing the colour and/or the 'clickability' of a GuiLabel (possibly of other GuiElements too?), the colour and the position of the label change in unexpected ways.

I am adding the sources of a very small plug-in; it only has one chat command: /test which displays a panel with the three boxes, numbered from 1 to 3, the first is blue ('active') and clickable, the other are red (inactive) and non-clickable: clicking on the active box displays a short message in the chat; two clickable buttons (left and right) move the 'selection' to the prev/next box, they also are can become inactive if there are no more previous or next boxes.

What actually happens is that any change to the colour or to the 'clickability' of a GUI element, displaces it slightly to the right and up and turn its colour to fully transparent; debug statements confirm that the actual colour and position values in the element are correct, but the display is wrong.

If the element is removed from the player GUI before the change and re-added after, the display is correct; in the test plug-in, this is done for the PREV button, and not for the other elements. This might work as a work-around, but seems a sub-optimal solution.

Any suggestion?