Posts by red51

It's indeed easy to miss the message... but on the other hand, it might be annoying if the message stays there permantently (maybe it's intentional to have a full inventory, who knows)? We can at least increase the duration how long the message will stay visible (and maybe make the status message a little bit more visible). Maybe a small notification sound would also make sense (although on the other hand, this may be annoying too)

Quote from Captian_Cornball

got it, the sticky needs some updates, infiniteitems Isn't In it.

Thanks for letting us know, I've updated the sticky now

So finally I did some tests about that, unfortunately I wasn't able to reproduce the issue I tested all scenarios, i.e. setting position/rotation before adding the model, setting position/rotation after adding the model, calling moveTo() before/after adding the model etc.

Although I just tested it in singleplayer (and LAN). Do you run it in multiplayer eventually? I didn't test the behaviour when there is a latency between the server and the client.

Otherwise I have no idea why it doesn't work on your side... only thing I noticed is that the speed in the moveTo Method is quite slow, so when providing 0.01, the element barely moves. I guess we may change that. But everything else worked as intended.

Can you maybe provide a test-case or alternatively send me the code via PM?

Hmm... kannst du die entsprechende Zeile bzw. am besten den ganzen Code mit Hinweis auf die entsprechende Zeile einmal posten oder mir per PN senden?

Quote from Smoka

ca. ab den 6 Block von boden aus

Hab den Fehler reproduzieren können, danke für den Hinweis, das wird mit dem nächsten Update behoben

Quote from Miwarre

The question is that, unless I have overlooked something very obvious, I can have either the jump (with the remove-then-add-back trick) or no movement at all (with no 'tricks'), with nothing in between

If you want to move the element to the target position instantly, you can just use the "setPosition()" method, otherwise "moveTo()" for smooth movement. Apparently adding/removing the model to the client causes the issues you were having (I will look into this now). As a workaround, you may try to add a small delay to the moveTo() command (i.e. by using a timer), so add the element to the particular player, and trigger a timer to move it with a delay of 0.5 seconds, for example (just for testing purposes).

Quote from Miwarre

As far as I can imagine things right now, a very precise movement sync across the different players is not necessary

It's not even possible*, especially due to the network latency (a player with a ping of 10 ms will receive the "moveTo()" message much earlier than a player with a latency of 100 ms, or image a player suddenly has a lag which causes a delay of a few seconds), but also things like framerate are relevant (the movement itself is framerate-independent, but it affects the processing of network messages [if the client receives a moveTo message, it will be processed in the next tick, in order to keep it synchronized with the rendering]... so a player with 200 fps will start processing the moveTo() message quicker than a player who only has 5 fps).

*Precision could be increased if the server keeps sending the current location of the model to the client, but this may cause a lot of traffic. I'm not sure if the result is worth it.

Quote from Miwarre

This is the kind of consistency which would be useful to have

Well, if the server calculates the moveTo() position as well, this wouldn't necessarily increase consistency (at least among different players), it would only be helpful if a plugin actually needs to now the exact position after calling the moveTo() method

If you don't want to allow infinite resources, you have to add the infiniteitems key to the deny block (and put to whatever you want to allow into the "allow" block):

creative:
    allow:
    - default
    deny:
    - infiniteitems

Das ist eine lustige Geschichte, setFlying() war bereits vollständig implementiert (sind eigentlich nur marginale Änderungen), ich musste aber einen kleinen Bugfix veröffentlichen, sodass ich alle Änderungen kurzerhand rückgängig gemacht habe (da sonst der neue Client nicht mit aktuellen Servern kompatibel wäre, und da es nur wenige Zeilen waren machte es keinen Sinn, die Versionskontrolle zu bemühen). Nach dem Kompilieren war leider ein Neustart der IDE nötig, und die rückgängig gemachten Änderungen wurden nicht wiederhergestellt (wie ärgerlich). Je mehr das eigentliche Update dann Richtung Release rückte, desto weniger Beachtung konnte den API Funktionen gewidmet werden, sodass setFlying() in die Tiefen Abgründe der Vergessenheit geriet. Leider hat sich diese Funktion (mit einigen, wenigen anderen Dingen) vor dem Auskommentieren in Sicherheit bringen können, sodass sie zwar nicht im Changelog auftaucht, aber trotzdem in der API zur Verfügung steht.
Das nur so als kleine Lagerfeuer Anekdote

Lange Rede, kurzer Sinn: Die Funktion wird leider erst mit der nächsten Version verfügbar sein

Quote from TheMrMik

Irgendwie funktioniert es nicht bei mir..
Es passiert einfach nichts.

Sind ggf. mehrere Plugins aktiv? Andere Plugins, die ggf. andere Keys registrieren? Ich sehe nämlich gerade, dass das durchaus problematisch ist, da andere Plugins (oder auch Aufrufe an andere Stelle im Code) diese Einstellung überschreiben Das muss geändert werden. Bis dahin als Workaround am besten alle fremden Plugins entfernen und bei eigenen Plugins darauf achten, dass die "registerKeys()" Methode des Spielers nur ein einziges mal an einer Stelle aufgerufen wird...

Unfortunately the API has no way to access the localized names of an item (basically the API always runs serverside, and the server doesn't have any localization). We can, however, add a clientside command to get the according item name from a localized name (so you can at least find out the correct item name), but there would be no way to trigger this command programmatically
Alternatively we could offer a callback method for that (so the server asks the client for the name), but the result would depend on the game language of the client (and it would be very awkward solution)

Oh... that's indeed an issue. The internal attributes map only gets created once a plugin sets an attribute, unfortunately the hasAttribute() method doesn't take this into account, so calling this method before any plugin has created at least a single attribute for this plugin raises an exception X/

Another workaround (instead of checking getAttribute() for null) would be to set a dummy attribute when the player connects or spawns.

I'm sorry for this issue, it will be fixed with the next update!

Quote from zfoxfire

I just placed two ores in a furnace slot by accident. I was able to remove the first while the second one remained.

What do you mean exactly? Were these ores at the wrong position?

Quote from Darwin_Blackwolf

I've been noticing more and more that it tends to reset itself to "All Ores" out of the blue, oft-times being while I'm switching between the ore detector and the flashlight.

Hmm... I wasn't aware of this issue. I will check out what's going on there

This is because you forbid the creative mode. You only put "default" in the allow section (i.e. the user is allowed to enable creative mode, but he can't use any creative tools).
If you want a user to use the creative tools, you have to move the "deny" entries to the "allow" section:

creative:
    allow:
    - default
    - freecrafting
    - terraintools
    - edittools
    - npctools
    - nohungerthirst
    - questtools

Quote from Miwarre

red51: I did test the inter-plug-in call and it works flawlessly! From plug-in A, I could call:

Awesome, thanks for the feedback!

Quote from Blacky1004

"getLanguage()" Für mich wäre es
nun gut zu wissen ob hier die eingestelle Sprache im Spiel zurückgegeben wird oder die Culture des Betriebssystems.

Das liefert die eingestellte Sprache des Spiels zurück (Zugriff auf die Systemsprache des Users können wir aber auch noch anbieten^^). Also momentan entweder "de" oder "en". Die Sprache kann in Steam geändert werden, indem man via Rechtsklick auf RW in der Steam-Bibliothek geht -> Eigenschaften -> Sprache -> und dort die entsprechende Sprache auswählt
Bei der Standalone hingegen wird standardmäßig die Systemsprache genommen, manuell kann man sie ändern, indem man dem Spiel das Argument "+lang=en" (bzw. de) hinzufügt.

Also ich denke, wir werden sowas mittelfristig anbieten. Also die Möglichkeit, eigene Kontextmenüs (das was man momentan bei toten Tieren, dem Zelt, anderen Spielern etc. aufrufen kann) zu erzeugen. Kann dafür leider keine Zeitangabe nennen...

GuiElemente mit der Möglichkeit, einzelne Pixel zu bearbeiten, sind sehr interessant. Es würde ein wenig anders aussehen als die "paintComponent()" Methode aus Swing bzw. die "paint()" Methode aus AWT, da OpenGL generell anders funktioniert. D.h. es gibt keine derartige Methode, in welcher die Darstellung eines Elements pro Tick verändert werden kann, sondern es müsste schon über eine Textur gelöst werden. Nun aber jeden Frame eine neue Textur in der API zu erzeugen und an den Client zu senden ist natürlich Käse, daher wird es vermutlich ein Element geben, was es erlaubt, einzelne Pixel zu bearbeiten (und ggf. auch ein paar Zeichenmethoden, wie zB eine Linie zeichnen etc). Diese Infos müssen weiterhin an den Client gesendet werden (diese paar Bytes sollten eigentlich kein Problem darstellen, sinnvoll wäre es vll aus Performancegründen, das nicht jeden Tick zu machen, sondern mindestens 50 oder 100 Millisekunden (oder ggf. noch etwas mehr) dazwischen Zeit lassen [das wäre einfach per Timer zu lösen]), auf Clientseite würde dann einfach eine bestehende Textur manipuliert werden.

Ich kann nicht sagen, wann diese Dinge kommen werden, all zu lange sollte es aber nicht dauern

PS: @Blacky1004 deine GUI für den Postbank Automaten sieht klasse aus!

Okay, I released a small clientside update in Steam (maybe you have to restart Steam in order to get the update), it should work properly now

There was neither a push nor a commit between the main update and the small bugfix shortly afterwards (usually I do these things after the updates, after responding in the forums etc., once there is enough time). However, it was my fault that the change was reverted.

Unfortunately I wasn't able to look into this issue yet But I will finally do that within the next days.
About the moveTo method: When removing the model before it arrived at the final destination, and then re-adding it, it will jump to the final destination instantly. Right now the moveTo() only happens clientside (so the server only see's the final destination). If it's necessary to have a exact position serverside, we will implement it of course

Apparently some game files are missing, or could not be downloaded correctly oO What internet connection do you have? Try to delete all files and download the loader again. Do you run a firewall or any antivirus software?