Posts by red51

    Freut mich, dass du es hinbekommen hast :thumbup: Ansonsten ist der kommentierte Source-Code des Jukebox Plugins auch hier verfügbar: Example: Jukebox


    Generell kann im Source-Code in der Klasse "MusicPlayer" die Mindest- und Maximalreichweite der Sounds eingestellt werden (über die Konstanten "MIN_RANGE" und "MAX_RANGE"). MIN_RANGE gibt dabei die Entfernung an, bis zu welcher die Musik noch mit 100% Lautstärke zu hören ist (standardmäßig 1), MAX_RANGE gibt hingegen die maximale Entfernung an ab wo das Musikstück nicht mehr hörbar ist (standardmäßig 25) - zwischen den beiden Werten nimmt die Lautstärke kontinuierlich ab.

    I'm sorry to hear you ran into another crash, however, this time it's a different crash: It's a SIGSEGV which occurred in our underlying graphics library (LWJGL) during an internal call (line 96 in the log). That doesn't seem to be related to Java at all. It could be either an issue with LWJGL or - more likely - a bug in the NVIDIA driver =O You could try to install the latest NVIDIA driver.

    I believe this also goes for player names correct? I know we have to ask players to change their name if it has a special character in it.

    Special characters in player names can indeed cause problems, however, this shouldn't interfere with the map ;)

    but from what i understand looking over the game directory, your game includes its own full java instance due to the current game engine correct? it doesn't refer to the java installed for/by the operating system?

    Yes, the Steam version is shipped with its own JRE. Basically it can be updated manually by replacing the Java folder in the game directory with a newer version ;)

    Das bedeutet, dass das Event Objekt nach Aufruf der Event Funktion ungültig wird. Hier ist ein Beispiel:

    Java
    @EventMethod
    public void onChatMessage(PlayerChatEvent event){
    //Hier überall ist das event gültig
    String msg = event.getChatMessage();
    event.setChatMessage("[UselessPrefix] " + msg);
    //AB HIER IST EVENT UNGÜLTIG
    }


    Innerhalb der "onChatMessage()" Funktion kannst du mit dem Event machen was du willst. Nachdem die Event-Funktion aber abgearbeitet wurde (also ab Zeile 7) verliert das Event seine Gültigkeit.


    Du kannst natürlich weiterhin andere Sub-Funktionen aufrufen, zB sowas ist absolut ok:


    Was aber nicht erlaubt ist, ist Events irgendwo zwischenzuspeichern und später irgendwie nochmal zu verwenden. Folgendes ist zB verboten:


    Was aber hingegen wieder ok wäre, wenn du die eigentlichen Daten des Events zwischenspeicherst. Statt also im obigen Beispiel das "PlayerChatEvent" zwischenzuspeichern, wäre es besser, die eigentliche Chatnachricht (oder was auch immer) zu speichern. Beispiel:


    Was auch geht: Eine eigene Klasse erstellen die alle Daten des Events entgegennimmt:



    Generell wird es in der neuen API so sein, dass die Events auf Java Seite nur noch eine "leere Hülle" sind mit nur einer Variablen - nämlich einen Pointer auf die Memory-Adresse des nativen Events (genau genommen gibt es in Java keine Pointer, daher wird einfach die Memory-Adresse als 64 bit Wert gespeichert - es handelt sich also vielmehr um einen Handle). Bei Funktionsaufrufen wie zB "getChatMessage()" wird eine native Funktion aufgerufen und der Pointer (bzw. die gespeicherte Memory-Adresse bzw. der Handle) des Events übergeben. Auf nativer Seite wird das Event aus dieser Memory-Adresse ausgelesen und dann der gewünschte Funktionswert zurückgegeben (in dem Fall die Chat-Nachricht).
    Nachdem aber alle Event-Funktionen durchlaufen sind, wird das native Event gelöscht und der verwendete Speicher freigegeben - d.h. das Java Event würde nun auf eine ungültige Memory-Adresse verweisen (und ein Zugriff darauf würde in den allermeisten Fällen das Spiel crashen). Um das zu verhindern, wird nach Ende des Event-Aufrufs die Memory-Adresse bzw. der Handle auf 0 gesetzt und bei jedem weiteren Funktionsaufruf stattdessen eine Exception geworfen.


    Insgesamt sieht das ganze in etwa so aus:


    • Natives PlayerChatEvent wird erstellt und die Memory-Adresse, an der es sich befindet, ausgelesen
    • TriggerEvent(PlayerChatEvent) wird aufgerufen - eine zentrale Funktion, die alle Event Listener benachrichtigt
      • Ein Java Objekt "PlayerChatEvent" wird erstellt und der Pointer bzw. der Handle übergeben
      • Für jedes einzelne Plugin wird nun die registrierte Fkt. für das Chat-Event aufgerufen, in unserem Beispiel wäre das "OnChatMessage(PlayerChatEvent)" - bis hier hin ist alles cool
      • Wenn eine Event-Funktion von einem Plugin aufgerufen wird (zB "getChatMessage()"), wird auf nativer Seite das native Event an der entsprechenden Memory-Adresse ausgelesen und der gewünschte Wert zurückgegeben - hier also die eigentliche Chat-Nachricht als String
    • Nachdem alle Plugin-Funktionen aufgerufen wurden, werden die Pointer bzw. die gespeicherten Memory-Adressen in den Java-Events auf 0 gesetzt (ab sofort kann keine Event-Funktion wie "getChatMessage() mehr aufgerufen werden)
    • Die geänderten Daten im nativen PlayerChatEvent werden vom Spiel weiterverwendet (wie zB die möglicherweise geänderte Chat-Nachricht) und das native Event wird gelöscht - der Memory an der Stelle wird für andere Dinge freigegeben


    Ich hoffe, das war einigermaßen verständlich ;) In den meisten Fällen sollte diese Änderung eigentlich keine größere Einschränkung bedeuten - denn auch schon in Java wäre sowas in manchen Fällen etwas gefährlich gewesen (bspw. wenn ein Event-Objekt gespeichert wird, und dann ne halbe Stunde später der Player dahinter oder so ausgelesen worden wäre - der möglicherweise gar nicht mehr auf dem Server ist).
    Es dürfen wie gesagt alle Daten eines Events in Listen gespeichert werden (im Zweifelsfall kann man auch eine eigene Klasse erstellen die die einzelnen Event-Daten aufnimmt), es darf nur das Event-Objekt selber nicht in eine Liste gepackt werden.

    Hmm... that's strange... the crash occurs in the "libjvm.so" and seems to be related to garbage collection. This could be a bug in Java =O It looks like the same issue was reported some time ago for Java 7, but apparently it couldn't be reproduced: https://bugs.openjdk.java.net/browse/JDK-8020236


    2. running rising world directly from the game folder seems to help, but then it's not using steam's launch options so it just uses default memory options. also have to have steam already running if doing this method. running directly seems to allow the game to operate seemingly without issue. i played rising world for several hours yesterday and no crash.

    This sounds like Steam is loading some libraries which aren't really compatible with the game or with Java :huh: However, you can still set the memory manually without starting the game through Steam. To do that, just create a file called "args.txt" in your game directory ("steam/steamapps/common/RisingWorld"), then you can enter the arguments you want to pass to the JVM. If you want to assign more RAM, you can add this to the file:

    Code
    -XmxHEAPm
    -XX:MaxDirectMemorySize=DIRECTm

    Just replace HEAP and DIRECT with the amount of RAM (MB) you want to assign as heap/direct memory. For example, if you want to assign 16 GB of RAM to the game (e.g. 8 GB heap and 8 GB direct memory), you could enter:

    Code
    -Xmx8192m
    -XX:MaxDirectMemorySize=8192M


    Maybe you could also try to add this to the end of the file:

    Code
    -XX:+UseParallelGC

    This uses a different garbage collector. Maybe this helps to avoid the crash :)

    Thanks a lot for your feedback! :)


    also just wondering will lighting effect the player as well i.e will we be able to hide from bandits if we are in the dark?

    Well, basically that's not directly related to the lights & shadows ^^ The lights and shadows are really just a rendering thing. Since lights aren't static anymore, the light & shadow information is only available on the GPU basically, while npc AI is handled by the CPU.


    Being able to "hide" in shadows only works if the lighting was static (or in a static world, so the "dark spots" can be defined beforehand)...


    This means shadows won't affect the npcs unfortunately... but things like current time of day could be taken into account for the AI.


    We didn't start working on the npcs, so unfortunately I can't say much about that yet :/


    Also another aspect is the sound having great sound effects in surround 5.1 / 7.1 can also make a game come to life, are you going to be re-doing these or just porting the old sound files over?

    We are re-using our old FMOD project for the new version. Starting from scratch would be way too time consuming (there are already so many sounds in the game) :whistling: But we're reworking and improving many sounds (item sounds, footsteps, ambient sounds etc).

    Danke fürs Feedback! :D


    Also wären skalierebare Glow-effekt Bauteile möglich ?

    Also bisher haben wir das noch nicht eingebaut, aber es wäre auf jeden Fall möglich. Wir können das grundsätzlich einbauen :) Allerdings würden diese Bauteile dann die Umgebung nicht wirklich ausleuchten, sondern nur wie auf dem obigen Screenshot sein^^


    Das Bett gefällt mir und hat sogar zwei Kopfkissen. Für Pärchen zum Kuscheln sicherlich gut, aber es sieht für ein Doppelbett etwas schmal aus.

    Hehe, das ist tatsächlich als Einzelbett gedacht. Zwei Kopfkissen sahen irgendwie besser aus als nur eines, und da dachten wir uns, man gönnt sich ja sonst nix :whistling:


    Kann ich auf einen Script-Ersatz hoffen?

    Schwer zu sagen... wir hatten für die alte Version mal ein Plugin vorbereitet (welches nie veröffentlicht wurde), mit welchem Lua Skripte eingebunden werden konnten (die Idee war gewesen, dass wir endlich die Lua API rauswerfen können, aber bestehende Skripte weiterhin funktionieren). Nun könnte dieses "Lua Plugin" zwar in der neuen Version *theoretisch* weiterhin verwendet werden, aber einige API Aufrufe ändern sich ja - was ggf. auch in Lua Skripten berücksichtigt werden müsste. Das müssten wir uns nochmal genauer angucken, wenn die neue Plugin API etwas weiter ist.
    Bis dahin kann ich leider keine wirkliche Aussage dazu treffen. Ich würde deshalb lieber erstmal davon ausgehen, dass es in der neuen Version kein Lua mehr gibt... :|


    Besser wäre es, die Funktionen, die über bestimmte Lua Skripte bereitgestellt werden mittelfristig in Plugins zu übertragen. Bzw. bestimmte Dinge wollen wir ja auch direkt ins Spiel integrieren, wie zB Teleportieren.


    Besteht vielleicht eine Möglichkeit in alten Blaupausen die Lampen/Lichter zu sondieren oder irgendwie zu löschen ohne explizit nach ihnen suchen zu müssen? Durch die neue Lichtveränderung scheinen viele alte Lampen überflüssig.

    Das ist eine berechtigte Frage... durch die Änderungen am Licht wäre das absolut legitim. Vielleicht wäre es auch gar nicht so verkehrt, generell alle Lampen aus alten Blaupausen zu löschen (vll bis auf ein paar Spezialfälle, wie Lagerfeuer etc). Wir müssen uns da mal Gedanken machen ;)


    Wenn man Licht in die Wand etc. eingearbeitet hatte, gab es diverse Effekte. Das ist nun vorbei, oder?

    Also grundsätzlich könnten Lampen auch in Wände eingebaut werden. Denn die "Innenseite" der Wand ist ja nicht sichtbar, sodass diese auch keinen Schatten wirft. Das gilt aber nur, wenn das Licht wirklich innerhalb der Wand ist (wenn es hinter der Wand ist, dann funktioniert das leider nicht mehr).


    Wir könnten aber vielleicht auch ein paar "technische Lichter" einfügen, die generell keine Schatten werfen. Diese wären nur über die Konsole verfügbar, aber damit könnte man natürlich Effekte erzielen, die mit den normalen Lichtern & Schatten nicht so einfach möglich wären.

    Vielen Dank für das Feedback :)


    Das einzige was ich mich frage wäre wie das ist wenn ich einen Raum statisch beleutet haben möchte, sagen wir ein Wohnzimmer und das Schlafzimmer hat dann
    nur eine kleine Nachttischlampe wo dann das neue ganz besondes gut wirkt.

    Also die Art und Weise, wie Lichtquellen den Raum ausleuchten, wird sich auf jeden Fall komplett ändern - sodass aktuelle Methoden, Räume auszuleuchten oder bestimmte Lichteffekte zu erzeugen nicht mehr ganz so funktionieren werden. Wir werden auf jeden Fall eine ganze Reihe neuer Lampen und Lichter einfügen, um möglichst vieles abzudecken - von Flutlichtern bis hin zu kleinen Lampen, die fast kein Licht an die Umgebung abgeben. Oder auch sowas wie beleuchtete Panele (wo besonders mit einem Glow-Effekt gearbeitet werden kann), evtl. sogar als skalierbares Construction Element, wie zB hier: https://images.rising-world.ne…w/lighting/lighting04.jpg


    Nichtsdestotrotz wird man in der neuen Version recht schnell richtig stimmige Szenen mit der Beleuchtung hinbekommen ;) Vor allem wenn die Lichter sparsam eingesetzt werden und dadurch Schatten ihre volle Wirkung entfalten können.


    Wäre hier bei den neuen Lichteffekten nicht ein kleiner Teaser drinn

    Hehe, dem rücken wir auf jeden Fall schon sehr nahe. Ich denke es dauert nicht mehr so lange, bis wir endlich die ersten Videos präsentieren können ^^

    Hi folks! Today we want to share a few more screenshots with you.



    Brief summary


    The new version will provide much more realistic lights and shadows. In addition to that, lights no longer pass through walls.
    In terms of modding, we've started working on the new Plugin API and decided to stick to Java for the API.



    Long story


    As mentioned in our previous announcement, we will see some major improvements regardings lights and shadows in the new version. In the current Rising World most lights were static (i.e. computed once by the CPU during chunk generation) - this provides good performance, but the visual results weren't that great. In the new version, all lights will be fully dynamic, resulting in a much more realistic lighting. In addition to that, lights are able to cast shadows now. To make sure performance doesn't suffer too much, we will use a deferred renderer (which can handle lots of lights fairly efficiently) and a smart shadow updater (which regenerates shadows only if the environment changed).


    We've prepared a small comparision between the new lights (still work-in-progress) and the static lights in the old version of the game:


    lighting01.jpg



    Shadows play a big role and can be a real game changer. When exploring dungeons, for example, or walking through forests at night (just equipped with a torch), shadows create a completely different atmosphere.


    lighting02.jpg



    Another big improvement thanks to proper shadows: Lights no longer pass through walls in the new version!


    lighting03.jpg



    Apart from lights and shadows, we also started working on the new Plugin API. We decided to stick to Java for the API, since this language provides a much better performance (and full multi-threading support) compared to scripting languages. This also means that large parts of the current API stay compatible, however, there are still a few changes to the API so existing plugins need to be updated for the new version. We will post more information about that soon.


    Stay tuned for the next status update! If you want to get more information in the meantime, make sure to check out our development roadmap on Trello :)

    Hi Leute! Heute möchte wir ein paar weitere Screenshots mit euch teilen.



    Kurzfassung


    Die neue Version wird wesentlich realistischere Lichter und Schatten bieten. Zusätzlich werden Lichter endlich nicht mehr durch Wände scheinen.
    In Sachen Modding haben wir begonnen, an der neuen Plugin API zu arbeiten. Wir haben uns dazu entschlossen, weiterhin auf Java für die API zu setzen.



    Lange Version


    Wie schon in der vorherigen Ankündigung erwähnt, wird es in der neuen Version einige große Verbesserungen in puncto Beleuchtung und Schatten geben. Im aktuellen Rising World sind die meisten Lichter statisch (d.h. sie werden einmalig von der CPU beim Generieren eines Chunks berechnet) - das bietet gute Performance, aber die optischen Resultate sind eher mittelmäßig. In der neuen Version hingegen werden alle Lichter dynamisch sein, was zu einer wesentlich realistischeren Beleuchtung führen wird.
    Zudem können Lichter nun Schatten werfen. Um sicherzustellen, dass die Performance darunter nicht zu sehr leidet, werden wir einen Deferred Renderer einsetzen (welche recht effizient mit vielen Lichtern umgehen kann) sowie einen intelligenten Schatten-Updater (welcher die Schatten nur dann neuberechnet, wenn sich die umliegende Umgebung ändert).


    Wir haben einen kleinen Vergleich zwischen den neuen Lichtern (natürlich noch work-in-progress) und den statischen Lichtern der alten Version des Spiels vorbereitet:


    lighting01_de.jpg



    Schatten spielen eine große Rolle und führen zu einem ganz anderen Spielerlebnis. Wenn beispielsweise Dungeons erkundet werden, oder der Wald bei Nacht mit einer Fackel in der Hand durchstreift wird, erzeugen Schatten eine völlig andere Atmosphäre.


    lighting02_de.jpg



    Eine weitere große Verbesserung dank korrekter Schatten: Lichter werden nicht mehr durch Wände hindurchleuchten!


    lighting03_de.jpg



    Abgesehen von Lichtern und Schatten haben wir nun auch angefangen, an der neuen Plugin API zu arbeiten. Wir haben uns entschlossen, weiterhin Java als Sprache für die API zu verwenden, da diese Sprache wesentlich bessere Performance (und vollen Multi-Threading Support) liefern im Vergleich zu Skriptsprachen. Das bedeutet auch, dass weite Teile der aktuellen API kompatibeln bleiben werden, wobei es hier dennoch einige Änderungen gibt sodass bestehende Plugins angepasst werden müssen, um mit der neuen Version lauffähig zu sein. Wir werden demnächst mehr Informationen dazu posten.


    Bleibt gespannt auf das nächste Status-Update! Falls ihr in der Zwischenzeit mehr Informationen haben möchtet, könnt ihr gerne auf unserer Roadmap auf Trello vorbeischauen :)

    I'm glad to hear that disabling vegetation helped :thumbup:


    I have a question, what would be the impact if I turn false the air? What is for the air inside of a house?

    Well, basically this option is only useful when blueprinting underground structures (like caves). It's similar to the "include terrain" option, except that it only includes air blocks. If you already include terrain in your blueprints, there is no need to have the air option enabled ;)

    Danke, frohes neues Jahr! :D


    Eine eigene Werkbank könnte man zwar auch jetzt schon einbinden, aber leider keinen Einfluss auf die angezeigten Rezepte nehmen :/ Hier müsste man eine eigene UI erstellen, was aber äußerst umständlich ist (und die UI würde definitiv vom normalen Craftingmenü des Spiels abweichen)... was also vom jetzigen Stand aus fehlt ist effektiv eigentlich eine Funktion, um das Crafting-Menü aufzurufen mit nur einer bestimmten Auswahl an Rezepten.


    Die Möglichkeit, Rezepte anzupassen, ist auf jeden Fall für die neue Version geplant. Wir werden das entsprechend für die API der neuen Version berücksichtigen ;) Ich weiß leider nicht, ob das noch Einzug in die aktuelle Version halten wird... hier kommt es ein wenig darauf an, wieviel Aufwand dahinter steckt :|

    Thanks for the update! I'll try to reproduce this bug :)


    Second thing It places a black x on the map of the other person instead of a red dot

    Hmm... that's strange oO Basically the X is just a regular map marker which is created by rightclicking on the map. Please try to delete it by clicking on it and hitting the DEL key on your keyboard - just in case this marker was created by accident.

    Thanks for the infos! One more thing: If you open the config.properties file in your game directory with a text editor, what's the value of game_blueprint_include_vegetation? It looks like it's causing quite some trouble if it's set to true ?( In case it's set to true, please try to set it to false and see if you still experience any crashes :)

    Hier mal ein Vorschlag von mir

    Das sieht echt klasse aus :thumbup: Sogar aus Planken gebaut? 8o


    Dieser Wettbewerb müsste von jemandem bewertet werden, das kostet Zeit

    Naja, also einen richtigen "Wettbewerb" würde ich vmtl. weniger daraus machen wollen. Eher sowas, was ursprünglich für die "schönsten Bilder" angedacht war, auch wenn daraus leider nichts geworden ist (was aber ja damals noch nicht abzusehen war). Oder eher eine Art "Sammelstelle" für Vorschläge bzgl. Achievements ;)


    Kann man ja zeitig damit anfangen. Bis dann alle Bilder zusammen sind, dauert es ja auch seine Zeit. Du müßtest eben nur die Vorgabe dafür geben.

    Leider können wir momentan noch keine richtigen Vorgaben machen :( Die Schwierigkeit bei den Grafiken besteht natürlich darin, dass jeder User einen anderen Stil hätte. Die Figur in deinem geposteten Bild finde ich zB schon echt passend, sowas könnte sich theoretisch durch fast alle Achievements durchziehen (erinnert dann ein wenig an den Vault-Boy aus Fallout) - der Vorschlag eines anderen Users würde aber hingegen möglicherweise gänzlich anders aussehen, sodass der Look der Achievements zum Schluss sehr zusammengewürfelt aussehen könnte =O


    im neuen RW soll es errungenschaften geben die sollen von anfang an drinnen sein

    Naja, das weiß ich noch nicht. Von Anfang an* drin sein werden auf jeden Fall Statistiken (also dass das Spiel sich merkt, wieviele Bäume du gefällt hast, oder wieviele Km du bisher gelaufen bist). Achievements werden möglicherweise etwas später kommen (in dem Fall werden aber die vorher erspielten Statistiken auf jeden Fall berücksichtigt).


    *natürlich ist das nicht auf die Demo oder etwaige Testversionen bezogen^^


    denn wenn wir sie jetzt bauen sind sie aus dem ALTEN RW
    es ist aber doch für das NEUE RW sollte es dann nicht im neuen gebaut werden

    Also Achievements würden nicht im Spiel gebaut, sondern sowieso extern erstellt werden ;) Grundsätzlich würde ein Achievement nur aus einem griffigen Namen bestehen, einer kurzen Beschreibung (Einzeiler) welche die Bedingung enthält, und einer passenden Grafik (die kleinen Icons die man dann in Steam zu Gesicht bekommen). Hier ist ein Beispiel wie Achievements typischerweise aufgebaut sind (ist zwar nur auf Steam bezogen, auf anderen Plattformen hat das aber Ähnlichkeit): https://steamcommunity.com/stats/105600/achievements

    Thanks for the error log! Unfortunately this a native crash which is caused by the underlying physics engine :( It looks like this happens if chunks with lots of construction elements are modified or if blueprints are placed which contain lots of construction elements...
    Do you always run into this crash when placing a blueprint? Does it also happen if you place the blueprint in a new, empty world?


    I was able to place the blueprint in question, but the physics-crash seems to be a random issue anyway :|