Posts by red51

A small new update is available now!

    Es wäre vielleicht ganz toll wenn ich vorm platzieren einer Blaupause noch einen "Farbänderungswunsch" umsetzen könnte. Beispielsweise alle Elemente die mit der ID 65 gebaut sind sollen in #FF8000 sein.

    Diese Möglichkeit ist auf jeden Fall für den Creative-Mode geplant, das werden die Edit-Tools unter F8 - ähnlich wie der "edit" Befehl, lediglich mit der Möglichkeit, mehrere Elemente gleichzeitig zu bearbeiten (und dann auch mit der Option, einen Filter anzugeben, also zB nur eine bestimmte ID innerhalb der Auswahl, die geändert werden soll). Ich kann leider noch nicht sagen, wie weit dieses Tool auch in Blaupausen integriert wird... im Zweifelsfall müsste man also (solange das Tool für Blaupausen nicht zur Verfügung steht) die Blaupause erstmal platzieren, anschließend mit dem Edit-Tool den Bereich markieren, die ID festlegen und dann die Farbe aller Elemente mit dieser ID innerhalb der Auswahl ändern.

    Schwer zu sagen, wodurch das zustande kommt... das wird leider ausschließlich von Steam gesteuert, d.h. wir haben darauf keinen Einfluss :/ Ich könnte mir lediglich vorstellen, dass Steam mit irgendeiner Kombination (Auflösung, Bildschirmmodus) nicht zurechtkommt.


    Wie Yarofey schon anspricht, der Anzeige-Modus kann hier eine Rolle spielen. Falls das auf "Vollbild im Fenster" gestellt ist, kann es evtl. helfen, einmal auf "Vollbild" zu stellen (oder andersherum). Auch wäre es u.U. einen Versuch wert, VSync zu deaktivieren.


    Ist ansonsten die Auflösung im Spiel identisch mit der Desktopauflösung?

    Für mich wäre es wichtig das ich ingame nicht nur auf die Blaupausen zugreifen kann, sondern auch die gesamte Ordnerstruktur einsehen und bearbeiten kann. So sollte es auch möglich sein eine Blaupause in einen anderen Ordner zu verschieben, den Namen zu ändern oder Ordner anzulegen.

    Das ist auf jeden Fall geplant ;) Die neue Version wird Blaupausen als Baumansicht (engl. "Tree view") anzeigen, wodurch man direkt sehen kann, welche Ordner und Unterordner es gibt und welche Blaupausen sie jeweils enthalten.


    Das Verschieben von Blaupausen aus dem Spiel heraus ist ebenfalls geplant, kann aber leider noch nicht sagen, ob das von Anfang an drin sein wird.


    Interessant könnte auch die Möglichkeit der Beschreibung einer Blaupause vor dem Speichern aber auch später zu hinzufügen. Hier kann man information hinterlegen wie zb die Größe eines Gebäudes, die verwendeten Texturen oder auch ein Copyright.

    Ja, das ist geplant :D


    Für den Multiplayer kann ich mir gut vorstellen, dass ein Server eine bestimmte Anzahl an Blaupausen zu Verfügung stellt. Das könnten zb Verkehrsschilder für den Straßenbau sein.

    Das wäre grundsätzlich ein hilfreiches Feature, allerdings würde ich das erstmal etwas nach hinten schieben, d.h. das würde leider nicht mit dem ersten BP-Update verfügbar sein :/


    Es wäre schön, wenn man das auch noch für die "alten Java-Blaupausen" anbieten könnte, oder zumindest ein Zusatzscript womit diese Bezeichnungen noch geändert werden könnten.

    Ja, alle Möglichkeiten des nachträglichen Bearbeiten werden auch für Java-Blaupausen verfügbar sein ^^ Allerdings werden Blaupausen - sobald sie einmal in der neuen Version bearbeitet wurden - nicht mehr mit der Java Version kompatibel sein.


    Was wir noch nicht wissen und worauf ich sehr gespannt bin ist ob die Blaupausen skalierbar sein werden.

    Aller Voraussicht nach werden Blaupausen skalierbar sein, allerdings mit gewissen Beschränkungen ^^ So kommt es bspw. auf die Größe der verwendeten Bauteile an (wenn zB Bauteile mit der kleinstmöglichen Skalierung verwendet wurden, wird man die Blaupause nicht mehr kleiner skalieren können, da diese kleinen Bauteile ja sonst noch kleiner werden).


    Heikel könnte es sonst vll noch werden, wenn damit komplexe Gebäude (zB Gebäude die aus vielen Tausend oder Hunderttausend Bauteilen bestehen) ins Miniaturformat verkleinert werden - denn dann haben sie immernoch den gleichen Einfluss auf die Performance wie ihr großes Pendant, doch man ist evtl. eher dazu geneigt, mehrere davon auf kleinstem Raum zu platzieren :thinking:


    Was aber auch schon angesprochen wurde, wäre die alten Blaupausen bzw. Blaupausen herunterzurechnen, um die vorhandenen Teile zu reduzieren damit es zu weniger Lags kommt

    Diverse Optimierungen haben wir tatsächlich im Hinterkopf, allerdings darf man sich davon nicht zu viel erhoffen: Alle platzierten Bauteile in einem Chunk werden bereits jetzt schon zu einem einzelnen Objekt zusammengefasst, d.h. hier ist performancemäßig nicht mehr viel herauszuholen. Man könnte lediglich unsichtbare Bauteile entfernen (also zB Bauteile, die komplett in einer Wand stecken und nie sichtbar sein können), aber auch hier stellt sich die Frage, wie oft sowas in der Praxis wirklich vorkommt... ansonsten wären alle anderen Ansätze, Blaupausen zu reduzieren, eher dazu geeignet, die Dauer beim Platzieren zu reduzieren :nerd:


    Ein Riesenproblem in der Java Version bei komplexen Bauwerken (oder eher gesagt: wenn viele Bauteile auf kleinstem Raum vorhanden waren) war vor allem die Physikengine. Sicher kennt jeder mittlerweile das Phänomen, dass es in der Java Version zu massiven Framedrops kam, wenn man zB ein selbstgebautes Möbelstück (das aus sehr vielen kleinen Teilen bestand) berührt hat. Diese Situation hat sich in der neuen Version deutlich verbessert. Während wir für die Java Version in der Hinsicht tatsächlich ein paar Pläne hatten, wie wir die Situation etwas verbessern könnten, ist das in der neuen Version eigentlich nicht mehr unbedingt notwendig :saint:

    Yes, original SEGI is not compatible with scriptable render, but there is a project with same approach that is compatible - VXGI (GitHub), it was designed to be compatible with scriptable render pipelines, was inspired by SEGI and have same license (MIT)

    Yes, but even that one isn't compatible with newer HDRP versions anymore - it only supports Unity 2019.4 (HDRP 7), but in HDRP 10 (Unity 2020.2+), Unity moved to a new internal constant buffer API, which makes it no longer possible to pass global variables to command buffers (which is happening in VXGI). There is no public replacement API available unfortunately, so "fixing" this requires changes to the HDRP itself ||

    But even if it was compatible, it uses geometry shaders, which aren't supported by Metal, which would mean this feature wouldn't work on Mac... :/

    Leider bekomme ich den Server nicht über die Putty-konsole neu gestartet (hab noch nicht rausgefunden wie ich es genau machen soll), also wird der Stecker gezogen.

    Das kommt ein wenig darauf an, wie der Serverprozess gestartet wurde (ich vermute du verwendest Linux?). Wenn du noch im Serverprozess bist, dann kannst du einfach "restart" oder "shutdown" in Putty eingeben, um den Server neuzustarten oder herunterzufahren. Wenn du aber nicht mehr im Prozess bist, also der Prozess detached ist, kommt es darauf an, ob der Server bspw. mit screen gestartet wurde (was generell empfehlenswert ist).


    wie lautet der Befehl auf "alles sofort mit Schnee becken"?

    Um die globale "Verschneitheit" zu ändern, kann der Befehl setsnowiness 1 verwendet werden (oder ein kleinerer Wert für weniger Schnee oder 0 um den Schnee loszuwerden), äquivalent dazu gibt es auch setwetness (um die Nässe zu ändern, zB nach Regen). Der Schnee schmilzt aber langsam, sofern nicht ein passender Wettereffekt gewählt wurde (entweder weather snow oder weather heavysnow für Schneefall, oder einfach weather cold für kalte Temperaturen ohne Schneefall).


    red51 Wird es später möglich sein, die Texture auf Blöcken wie auf meinem Bild in eine andere Richtung zu drehen?

    Das ist auf unserer Todo-Liste ;)

    Thanks for bringing this to our attention, this looks very impressive! 8):thumbup:


    However, unfortunately this doesn't seem to be compatible with Unitys scriptable render pipelines, more specifically with the HDRP. Shaders work different there, and most parts of the old Unity Graphics API (which are used by SEGI) are no longer compatible with HDRP - so there would be quite some work involved to port this to HDRP...


    It's a bit disappointing that Unity does not offer a proper realtime GI solution. More than 2 years ago they deprecated "Enlighten GI" (which is useless for a procedural world anyway, because it requires baking of all light data) for HDRP and said they're working on an in-house realtime GI solution. But a few months ago they suddenly re-enabled Enlighten (with extended support until 2027), and didn't provide any further information about their in-house realtime GI solution... it's a pity, considering that Unreal's "Lumen" looks very promising.

    This is caused by the LOD chunks (i.e. distant chunks, depending on the view distance settings): For reasons of performance, they can only represent a heightmap, i.e. no cliffs or overhangs - similar to LOD chunks in the Java version.

    However, sometimes the LOD chunks don't represent the terrain properly (this is causing the issues mentioned by Groovaholic ), and in general, this algorithm still needs some improvements (so flying islands or the moon in your case do not result in those streaks) ;)

    Bei ARK Survival Evolved gibt es die Möglichkeit diverse Farben in einem Kochtopf "blubbern" zu lassen. Das macht sogar richtig Spaß, da je nach Zugabe verschiedener Pflanzen/Blumen andere Ergebnisse herauskommen. In Rising World könnte man zusätzlich auch Karotten, Zwiebeln oder Mais verwenden. Vielleicht erst einmal ein einfacher Kochtopf für einfache Farben und später ein fortgeschrittener Ofen um bessere und schönere Farben zu erhalten.

    Wir müssen mal schauen, wie wir das Herstellen von Farbstoffen später tatsächlich umsetzen. Schön wäre es schon, dafür einen speziellen, interaktiven Crafting-Vorgang zu haben (quasi wie auch schon das Mahlwerk oder die Papierpresse in der Java Version).


    Wäre es nicht möglich, dass ich meinen Fenstermodus bzw. mein Bild ein klein wenig kleiner ziehen könnte, damit ich auch die unteren Slots bzw. Anzeigen besser sehen kann? Mit irgendeinem Programm vielleicht? Ich spiele seit über 6 Jahren im Fenstermodus. Ich habe das Bild sehr groß, allerdings nur so weit verkleinert, dass ich unten die Taskleiste sehen kann. Steamnachrichten, Whatsapp, Zugriff auf verschiedene Symbole dort.

    Wir werden das mal fürs nächste Update ins Auge fassen, müssen wir aber erst noch testen. Leider können wir sowas nicht als Einstellung anbieten, sondern entweder das Skalieren des Fensters ist immer aktiv, oder nie. Wir müssen erstmal testen, ob dieses Verhalten irgendwelche Probleme hervorbringen würde. Wenn nicht, können wir es einbauen ;)


    Es fehlen noch diverse Formen wie Halbkugel, Halbkugel hohl, Kegel hohl, Halbkegel hohl. Bei einen hohlen Säule stelle ich mir auch interessante Möglichkeiten vor.

    Weitere Formen sind noch geplant, aber der Druck aus Teilen der Community, dass endlich Survial-bezogene Features kommen sollen, ist momentan recht hoch (verständlicherweise), daher möchten wir uns erstmal diesem Part ein wenig widmen :hushed:


    Natürlich fehlen noch die Fensterrahmen. ;)

    Auch die kommen noch, das wird auch nicht mehr unendlich lange auf sich warten lassen, da wir Fensterrahmen allein für Blueprints brauchen (damit alte Baupläne kompatibel bleiben) :nerd:


    Bei einem hohlen Zylinder kann ich diesen zwar sehr dünn machen, allerdings wird prozentual der innere Rand nicht dünner. :( Ist man jetzt weiterhin auf manuellen Räderbau angewiesen?

    Das müssen wir noch beheben. Bauteile haben zwar einen "thickness" Parameter (womit solche Dinge wie Wandstärke bei hohlen Bauteilen bestimmt wird), aber das funktioniert noch nicht einwandfrei. Vielleicht schaffen wir es noch zum nächsten Update, das zu beheben ^^


    Der hs_err_pid kommt immer nach ein Server neustart.

    Wie wird der Server denn genau neugestartet? Über den eingebauten "restart" oder "shutdown" Befehl, oder wird der Prozess gekilled? Beim Killen des Prozesses kann es durchaus passieren, dass die JVM auf diesen "Crash" reagiert. Beim "ordnungsgemäßen" Beenden via "restart" oder "shutdown" hingegen sollte eigentlich kein solcher Crash auftreten :thinking:

    Ich nehme mal an, dass der Schatten "dynamisch" mit einer Spielfigur mitwandern sollte, nur hier wird er wohl einfach auf einer fixen Position gerendert?

    Naja, Schatten werden in der neuen Version von den meisten Lichtquellen momentan nur 1x gerendert und dann immer wieder verwendet (statt jeden Frame die Schatten neu zu rendern). Das spart viel Performance. Der Nachteil ist allerdings, dass solche Situation wie auf dem Bild zustande kommen...

    Im normalen Betrieb werden die Schatten immer dann aktualisiert, wenn zB im direkten Umfeld ein Block o.ä. abgebaut wird. Spielerfiguren (die sich ja quasi ständig bewegen) werden momentan aber leider noch nicht berücksichtigt. Das werden wir auf jeden Fall noch in einem zukünftigen Update beheben ;)


    (Nein, das sind hoffentlich keine Dämonen :drunk: )

    Wir werden sicherheitshalber noch einen Exorzisten konsultieren :D

    Wäre es vielleicht Möglich zum kommenden Fix, beim Bett die Matraze einzeln mit ins Spiel zu bringen. Da ist diese ja schon im Spiel ist. somit könneten wir auch schon im richtigen Maß Betten bauen. Dazu sollten zumindestens die Kisten also das man hier das Inventar füllen kann auch funktionieren. Das wäre echt toll

    Naja, tatsächlich ist eine Matraze noch nicht wirklich im Spiel vorhanden :D Die Matraze des Bettes wäre als eigenständiges Objekt noch nicht ganz geeignet (sie hat zB keine Unterseite, da diese beim Bett eh nie sichtbar wäre)... wir haben auch irgendwo eine richtige Matraze rumfliegen, weiß aber nicht, ob wir die zum nächsten Update schon reinpacken können. Früher haben wir eigentlich eher schlechte Erfahrungen gemacht, wenn ein Update nebenbei auch 1-2 (eher kosmetische) Objekte eingeführt hat - manche Leute (insbes. auf Steam) haben das Update dann nur auf dieses eine Objekt reduziert (im negativen Sinne)...


    Am liebsten würde ich das direkt mit mehreren Objekten und Items bündeln... :hushed:


    Aber was die Kiste angeht, das ist auf jeden Fall auf der Todo-Liste ^^


    wo finde ich oder lege mit was die beschriebene "serveroption.server.shortname" an ?

    Das ist der Eintrag "Server_ShortName" in der server.properties Datei ;) Das Feld ist gedacht, dass man hier eine Kurzversion (max. 32 Zeichen) des Servers angibt. Während der reguläre Servername (welcher ja im Serverbrowser angezeigt wird) ja möglicherweise recht lang ist und diverse Informationen enthalten kann (zB über PVP, Plugins, Regeln, Spielmodus usw), wird der "ShortName" zB im Server-Info-Menü (beim Doppelklick auf den Server) angezeigt.


    Beispiel: Unter "Server_Name" könnte eingetragen sein: "Rising World Testserver 24/7 Active Admins - No PvP - PvE only - Creative Mode - Blueprints - Best server ever", bei ShortName" könnte man hingegen entsprechend eintragen: "Rising World Testserver"


    Zum Scheduler: Bei diesem Variablenzugriff ist das "serveroption" ein allgemeiner Zugriff auf die "server.properties" Datei, und danach folgt dann der entsprechende Eintrag der server.properties Datei. Wenn du zB den Weltnamen haben möchtest (in der config heißt es "World_Name"), kannst du im Scheduler via "%serveroption.world.name%" darauf zugreifen, wenn du zB die Serverbeschreibung willst ("Server_Description"), heißt der Key "%serveroption.server.description%" usw.


    Eine Farbtabelle mit Codes wäre sehr praktisch. Es gibt sehr viele Farbcodes und so kann man seinen persönlichen Favorit immer wieder ändern.

    Grundsätzlich sind alle HTML Farbcodes (RGB) dafür geeignet ;) ZB "#FF0000" für rot, "#00FF00" für grün, "#0000FF" für blau, "#FFFF00" für gelb, "#FFFFFF" für weiß usw. ^^


    Mein Server schmeißt mir jeden Tag eine Fehlermeldung raus.

    Server läuft soweit ohne Probleme.

    Was für eine Fehlermeldung wird genau ausgegeben? :wat: Wann tritt dieser Fehler auf? Stürzt der Server dabei ab? Die hs_err_pid Datei ist eher ein Folgefehler und selber in der neuen Version nicht mehr wirklich relevant, es sei denn es geht um Plugins (wenn zB der Server abstürzt, dann crasht auch die JVM [die nur für Plugins benötigt wird] und produziert entsprechend eine hs_err_pid Datei).


    Eigene Voreinstellung kann ich unter C speichern, allerdings ist mir noch nicht aufgegangen wie ich diese, von mir selbst benannten Baustücke, über die Konsole, auch in der gewünschten Farbe, spawnen kann

    Leider gibt es dafür noch keine Konsolenbefehle, diese werden aber mit dem nächsten Update dazukommen ("loadpreset <id/name>" um eine Voreinstellung zu laden, "savepreset <id> <name>" um die aktuelle Größe zu speichern) ;)


    Desweiteren verstehe ich nicht, warum ich einen Block auf einen Untergrund auf Blöcken setzen kann und dieser dardurch die korrekte Höhe erreicht, allerdings bei Untergrund Stein oder

    Erde zur Hälfte im Boden versinken muss. Das leuchtet mir ehrlich gesagt nicht ein. Möchte ich nämlich ein Zelt bauen, hieße es zuerst einen Blockuntergrund oder dünner zu erstellen um dann

    erst mein Zelt darauf zu bauen oder das Zelt zu bauen und dann zu blaupausen, damit es auf Rasten stehen kann. (Natürlich hat ein Zelt einen Boden, aber darum gings mir nicht).

    Das ist leider eine Konsequenz darauf, dass Blöcke und Bauelemente nun dasselbe sind... in der Java Version war dieses Verhalten grundsätzlich auch da (zumindest bei Blöcken) - denn das Raster ist so aufgebaut, dass das Bauteil sich immer dem Raster anpasst, und das Terrain ist nicht direkt bündig mit dem Raster, sondern da ist ein kleiner Unterschied, damit wenn ein Block platziert wird, dieser nur zu ca. 20% aus dem Boden rausragt. Beim Bauen mit Blöcken hat das diverse Vorteile, denn das bietet sich recht gut als Fundament an.


    Beim reinen Fokus auf Bauelemente im klassischen Sinne (also wie die Planken und Balken) ist das natürlich zugegebenermaßen etwas irritierend - der Spagat zwischen Blöcken und Bauelementen ist immer etwas schwierig. Die aktuelle Implementation ist da sicher auch noch nicht der Weisheit letzter Schluss :saint: Hier sind wir weiterhin für Feedback offen, denn gerade solche Probleme möchten wir natürlich unbedingt ausmerzen.

    Was ich noch vergessen habe. In der Java ist doch eine Zahl im Raster zu sehen, mit der man z.B. an anderer Stelle die selbe Höhe/Tiefe reproduzieren kann. Könnte die Zahl auch wieder in der Unity für das Raster implementiert werden ? Wäre schön.

    Ja, die Höhenangabe für das Begrenzungswerkzeug kommt auf jeden Fall noch :D

    Ich kann das bestätigen. Ich habe zwar die Anzahl der Eingaben nicht gezählt, aber Probleme wurde nur durch Neustart behoben

    Ich kann mir höchstens vorstellen, dass das auftritt, wenn eine bestimmte Größe gesetzt ist i.V.m. der Skalierpräzision (setl) :thinking: Aber der "size" Befehl macht ja eh noch ein wenig Ärger, den müssen wir ohnehin noch unter die Lupe nehmen. Ansonsten wäre aber ein Report dennoch hilfreich (nachdem das Phänomen auftritt, einfach die Konsole öffnen und "report" eingeben)

    Mir ist aufgefallen, dass bei settimespeed 60 die Sonne in regelmäßigen Abständen wieder ein Stück zurück springt.

    Leider ist in der aktuellen Version ein Bug, wodurch die Zeit auf dem Server unbeabsichtigt doppelt so schnell vergeht :silenced: Damit kommt der Client durcheinander, weil die Zeit dort im normalen Tempo voranschreitet. Grundsätzlich versucht der Client, Zeitunterschiede unauffällig auszugleichen, da er mit dem Server momentan aber nie auf einen Nenner kommt (da die Zeit dort ja wie gesagt doppelt so schnell vergeht), kommt es dann zu diesen harten Sprüngen. Das wird mit dem nächsten Update behoben, dann sollte die Zeit wieder normal voranschreiten, ohne irgendwelche Sprünge :D

    Can we turn on pvp just inside the areas ?

    Yes, basically every permission in a permission file (including pvp) can be set specifically inside an area (with few exceptions) ;)


    I don't see blueprints being restricted in the permissions

    Yeah, there are currently no permissions about blueprints (or other things like posters), because they are not implemented yet. Once the blueprint update is ready, there will be also corresponding permissions for them ^^

    i mad e4 permissions groups pve/pvp for defaults and ownerpve/ownerpvp for the actual area owners. they both show up for the default and user permissions tho.

    Yes, the game does not distinguish between player and default area permissions - so all permissions (in your "Areas" folder) can be used as default permission or assigned to individual players. Basically the "default area permission" is just a way to assign a permission to all players without having to add all players to that area.

    Grundsätzlich wäre das eine denkbare Option, so ein System müsste aber vielseitig genug sein, um auch möglichst viele Anwendungsfälle abzudecken - da käme es also darauf an, was das System genau können soll. Vll reicht für Spieler A ja, wenn zB der /heal Befehl einfach immer beim Betreten ausgeführt wird, Spieler B möchte aber evtl., dass der Befehl nur einmal pro Stunde durchgeführt werden kann, Spieler C hingegen will, dass der Befehl erst nach 30 Sekunden ausgeführt wird und Spieler D hingegen wünscht eine schrittweise Heilung des Spielers, solange er in der Area ist... es wäre schön, wenn man das System so universell ausstattet, dass es all diese Fälle abdeckt. Es müsste also vmtl. schon eher sowas wie CommandBlöcke in MC sein :thinking:


    Über die Plugin API werden die Areas aber übrigens natürlich auch alle weiterhin zugänglich sein. Denn egal, wieviele Features wir der Area Protection geben, für wirklich 100%ige Kontrolle muss natürlich die API verwendet werden :D

    Die Vorschau des Bauteils ist leider geringfügig größer als das eigentliche Bauteil. Das hatte ursprünglich den Grund, dass wir damit die Sichtbarkeit der Vorschau etwas erhöhen wollten, aber beim genauen Bauen ist das natürlich recht hinderlich.

    Das werden wir vorraussichtlich mit dem nächsten Update ändern ;)