Posts by red51

Der sauberste Ansatz, um etwas zeitverzögert auszuführen, wäre die Verwendung von Timern (Wichtig: Auf den Import achten, also Timer aus net.risingworld.api importieren) Du könntest also in die PlayerConnectEvent oder besser noch PlayerSpawnEvent Methode folgendes reinpacken:

//Label erzeugen
GuiLabel label = new GuiLabel("Hallo Welt", 100, 100, false);


//Label zur Spieler GUI hinzufügen
player.addGuiElement(label);


//Timer erzeugen, der 1x nach 30 Sek ausführen soll
Timer timer = new Timer(0, 30, 0, () -> {
    //Hier steht das, was der Timer machen soll:
    //Nämlich das Label von Spieler GUI entfernen
    player.removeGuiElement(label);
});


//Timer starten
timer.start();

Der Ansatz von @Galveston01 würde natürlich auch funktionieren, nur ist es hier unbedingt wichtig (wie in seinem Beispiel), dass der Threading Modus der Event-Methode auf "Threaded" gestellt wird (sonst bleibt der halbe Server für 30 Sekunden stehen) Hier muss man jedoch berücksichtigen, dass diese Eventmethode dann immer in einem separaten Thread ausgeführt wird, man sich also zB beim Zugriff auf globale Variablen ggf. selbst um eine angemessene Synchronisierung kümmern muss. Da Multithreading teilweise sehr komplex sein kann, würde ich Anfängern dringlichst die Timer-Methode ans Herz legen (zumal die Verwendung von Threaded-Events in erster Linie nur dann sinnvoll ist, wenn wirklich rechenintensive Operationen durchgeführt werden sollen - davon sind wir in diesem Beispiel meilenweit entfernt, sodass ein Timer eindeutig resourcensparender wäre).

Quote from Miwarre

Unfortunately, both methodologies suffer from a serious drawback: both require the target plug-in to be in the CLASSPATH. Apparently, no plug-in .jar is in the CLASSPATH (which makes sense from some point of view), so no plug-in can access the definition of other plug-in classes (or inner classes); trying results in a run-time java.lang.ClassNotFoundException.

Hmm... this is indeed a problem (it makes the getPluginByID/Name() methods rather useless). Currently each plugin has an own classloader (in order to be able to unload a plugin properly), unfortunately these classloaders don't know anything about each other. Basically even a minor change (load all plugin by a single classloader) would do the trick, but first we have to make sure this doesn't result in any other issues (especially regarding the ability to reload plugins on the fly).

Quote from Captian_Cornball

ok is there a way to call it from "onCommand"? I'm Tring to make it Write some data after I issue a /command.

Sure, you can call if from everywhere Maybe post your "onCommand()" code here

Quote from zfoxfire

Will this be a content update or just a bugfix?

Both

Hmm... that looks fine to me... I just tried it and it worked as intended What operating system do you use? Where do you call this code?

Thanks for the report file and the log. We'll do some changes to the game, this issue might be solved with the next update (which will be available in a few days). In case you still encounter this issue after the update, please let us know

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.

That's a bug, thanks for letting us know, it will be fixed with the next update (in a few days)

Thanks @Lonelobo and @SilverSatin for the information and the logs! It's a clientside issue, so unfortunately nothing that can be done serverside. It's caused by the physics engine, and it happens especially when there are many animals in the world. We'll do some changes to the game, so this issue might be fixed with the next update I guess. In addition, we will add a command to reload the physics (this helps when someone gets stuck for no apparent reason), just in case the issue still occurs after the update. The next update will be available in a few days

Sorry für meine späte Antwort, der Log enthielt leider nichts Nennenswertes. Freut mich aber, wenn es jetzt wieder funktioniert.

Quote from TutMeistensNix

Ich gehe immer wieder von Server weil ich ja dann erst wieder programmieren muss und letztens habe ich mich gewundert wer mir den da immer so lustvoll ins Ohr stöhnt.

Im Singleplayer hättest du immerhin den Vorteil, dass das Spiel (seit dem letzten Update) pausiert, wenn du das ESC Menü aufrufst^^ Dann knurrt dich immerhin niemand an, und du landest auch nicht plötzlich in einem "Game Over" Screen, wenn du wieder ins Spiel wechselst

Grundsätzlich kannst du Plugins auch einfach mit reloadplugins oder rp neu laden (dann wird quasi ein Reconnect des Spielers simuliert). Oder alternativ die Plugins im Singleplayer testen, das geht weitaus schneller, vor allem wenn du deine Plugins vom Spiel automatisch kompilieren lässt (dann kannst du direkt was im Sourcecode ändern, ins Spiel wechseln und die Plugins neuladen lassen, ohne dass du irgendwelche Dateien hin und her kopieren musst)

Aber zum eigentlichen Problem: Wie weit gelangt denn der Ladebalken? Poste am besten mal den vollständigen Serverlog.

Das sieht gut aus, das kannst du so machen

Aber: Das Speichern in der Datenbank macht eigentlich nur Sinn, wenn die per Befehl "/back" gespeicherte Position auch nach dem Disconnect des Spielers verfügbar bleiben soll (also quasi dauerhafte Gültigkeit haben soll, selbst nach Serverrestart etc). Wenn es nur um eine temporäre Information geht, kannst du die Position bspw. auch einfach als Attribut des Spielers speichern (Attribute können für jeden Spieler festgelegt und anhand eines eindeutigen Strings beschrieben werden, dabei kann jedes erdenkliche Objekt als Attribut gespeichert werden - also eine Zahl, ein Vector3f, ein anderer Spieler, ein GUI Element, ein String usw). Hier ein Beispiel (wie gesagt, wenn du es weiterhin per Datenbank speichern möchtest, kannst du das hier eigentlich ignorieren^^):

Player player = event.getPlayer();
Vector3f backTargetPos = event.getDeathPosition();


//Als Attribut mit dem Key "tmn-back-pos" speichern
//Sicherheitshalber einen neuen Vector3f dafür erzeugen
player.setAttribute("tmn-back-pos", new Vector3f(backTargetPos));


//...


//Irgendwo anders, wenn die Position abgerufen werden soll
//Type-casting ist wichtig! Da getAttribute() nur ein
//universelles "Object" zurückgibt
Vector3f position = (Vector3f) player.getAttribute("tmn-back-pos");


//Unbedingt prüfen ob != null, also ob Attribute zuvor gesetzt wurde
if(position != null){
    //Spieler teleportieren o.ä.
    player.setPosition(position);
}

Vielen Dank für das Video Das ist offensichtlich ein Bug, verwundert mich zwar ein wenig (da die cmds "gm 1" und "gm 0" ja auch funktionieren), aber ich denke der sollte einfach reproduzierbar und somit auf jeden Fall fürs nächste Update behebbar sein

Quote from TutMeistensNix

Nun gibt es aber nicht mehr getPosition() wie lautet es den nun?

Die Funktion gibt es weiterhin, einfach player.getPosition() aufrufen Hier findet sich generell eine Übersicht über alle Spielerfunktionen: Player

Quote from TutMeistensNix

Kommt ein Spieler das erste mal auf den Server wird geprüft ob er schon mal da war, wenn nein dann wird ein Back Punkt erstellt anhand der getSpawnPosition() ist das ok?

Ja, also wenn du "getSpawnPosition()" auf das Eventobjekt aufrufst, dann erhälst du exakt die Position, an welcher der Spieler online kommt. Bedenke, dass PlayerSpawnEvent nur einmal aufgerufen wird, nämlich wenn der Spieler zum Server verbindet und gespawnt ist (nach seinem Ableben wird immer PlayerRespawnEvent aufgerufen, erst wenn der Spieler disconnected und wieder zum Server verbindet, wird das PlayerSpawnEvent aufgerufen - aber ich denke das entspricht auch der Intention hinter deinem Code?)

Naja, bei MySQL etwas tricky: Es wird dann gespeichert, wenn der nächste Commit auf diese Connection aufgerufen wird. Da MySQL über mehrere Connections verfügt (standardmäßig ist 10 in der server.properties eingestellt), kann es sein, dass es sehr lange dauert, bis ein Commit mal zufällig durchgeführt wird Das sollte aber wie gesagt eigentlich nicht sein, weswegen es in Kürze behoben wird.

Well... the plank issue is caused by the minimum size of planks. We changed it some updates ago, it has a minimum size of 5 units now (considering a block has a size of 100 units). Resizing planks uses steps of 10 units, so if you scale it down to the minimum size, you can't scale it back to the default size (unless you scale it to the maximum size). I know this is a little bit awkward. You can change the resize precision though, by typing "setl <value>" (e.g. "setl 5", so you can resize in steps of 5), in the future, there will be a more convenient way to do that.

About lags in singleplayer: This always depends on your hardware, what hardware do you have exactly? Maybe post a report file here (to do that, open console ingame [by pressing ^ or `] and type "report" [w/o quot. marks], then a file called "report" [followed by a number] will appear in your game directory [steamversion: to get there, rightclick on rw in steam -> properties -> local files -> browse local files], please upload this file here)

Hmm... syntaktisch sieht das jetzt richtig aus. Ich habe die Vermutung, dass es ein Problem mit der MySQL Datenbank gibt, nämlich, dass Commits, die auf die Weltdatenbank angewendet werden, nicht sofort durchgeführt werden Ich werde mir das mal genauer anschauen, ggf. wird in wenigen Tagen ein Fix dafür verfügbar sein

You can do that programmatically of course Each model is a separate object, but one could create a new class which holds multiple World3DModel instances. Once we have some more time we may release an example plugin for that (or maybe integrate such a class in the API directly).
However, it's always necessary that your model still has a separate obj file (and texture) per part^^

Generell ist es bei der Pluginentwicklung sehr hilfreich, wenn die (zumindestens wenn man im Singleplayer testet) Debugkonsole aktiviert ist, dann sieht man sofort, wenn ein Fehler auftritt Diese kann aktiviert werden, indem game_debug_console in der config.properties Datei auf true gesetzt wird. Kombiniert man das damit, dass das Spiel im Fenstermodus ausgeführt wird (sodass man die Konsole gleichzeitig im Blick hat), hat man eine enorme Effizienzsteigerung

Quote from TutMeistensNix

Aber ich merke doch sehr wie das nix für mich ist.

Aller Anfang ist schwer, wobei solche MySQL Dinge ja nicht mehr unbedingt zum Einstiegskram gehören MySQL ist generell pingeliger bei den Abfragen und verlangt einen ordentlichen Syntax (hat ja nichts mit Java zutun), SQLite ist da deutlich toleranter (bei Lua hatten wir ja nie MySQL Support, wobei man SQLite jetzt natürlich auch weiterhin nutzen kann)^^

Quote from ozmods

so this shows you can use multiple textures on the same car

Just to avoid misunderstandings: every model can only have one single texture, trust me In other words, if you want to use multiple textures, you have to use multiple models (one texture per model).

Quote from ozmods

because it gives me around 20-30 fps I would need to reduce it down a lot

It's important to keep polycounts as low as possible On the one hand, it has a direct impact on rendering performance (it highly depends on your hardware, an NVIDIA GTX 1080 can definitely handle much more polygons than an integrated Intel HD graphics adapter), usually you can keep "a few million triangles" in mind when it comes to the total polygon count (but keep in mind that the game scene already consists of a lot of triangles).
But on the other hand, high polygon counts also result in bigger file sizes, i.e. especially in multiplayer it takes more bandwith to transfer the model data to the client.
For a decent looking car (if you create a model from scratch), I'd recommend to not use more than 10,000 - 30,000 triangles (you can achieve really great results with these limits, everything above that is basically a waste of resources).