Posts by red51

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?

Quote from Smoka

Da hab ich mich etwas unklar ausgedrückt, Blöcke in der höhe werden zerstört aber es wird mir nicht angezeigt (optisch) erst wenn ich z.B. ein Block an der Stelle platziere wird es mir erst angezeigt.

Oh, verstehe Aber das ist erst ab einer gewissen Höhe? Ab welcher Höhe tritt das denn auf?

Well, this is a perfect example of how not to do it: Apparently the bug isn't fixed I mean, I swear it was fixed, but somehow this minor change was reverted accidentally with the latest bugfix X/
Are you developing your plugin in singleplayer or on a multiplayer server? Are you planning to release your plugin shortly? This change requires an update of the server, we want to avoid that (or at least wait if there might be another update necessary in the next days), however, we can release an updated client (and if you're working with the server, an updated server as well), but it would be an optional update (so if you release your plugin before the next update is available, it might not work for everybody)

Hmm... that's strange. Does it work when you download the "Universal" version from the homepage instead and run the "risingworld.jar" there?

Sorry for my late reply to this. Do you still run into the same issue after the latest update?

Maybe try this: Rightclick on the App, open contents/Resources/java and execute the "risingworld.jar". Does it work then?

Den Fehlerlog als "Bearbeitungsgrund" anzugeben ist keine gute Idee Ich würde dir empfehlen zu prüfen, ob dieser Fehler auch mit der neuesten Version auftritt, und falls ja, nochmal einen neuen Log posten.

Wir haben vermieden, daraus eine neue Version zu machen (damit Server nicht nochmal updaten müssen), daher muss bei der Standalone eine Datei gelöscht werden, damit das Update verfügbar wird. Also am besten in den "data" Ordner gehen und zB die "commons.jar" Datei löschen, anschließend das Spiel starten und den Download bestätigen