Posts by red51
-
-
Hmm... this may be related to the other issue that permissions are not applied correctly (which will be fixed with the next update). Did you set it in the "default" permission file? That should basically work. Or did you set it in a specific group permission?
-
Ich habe die Beiträge mal in einen eigenständigen Thread verschoben
Jedenfalls ist das mit dem Beanspruchen der Areas tatsächlich so: Wenn der Spieler das Objekt (bleiben wir mal beim Pfahl) irgendwo platziert, dann wird dort für ihn eine neue Area erstellt - dieser Spieler hat dort dann eine spezielle "Eigentümer" bzw. "Owner" Berechtigung (kann vom Admin eingestellt werden). Der Spieler kann - wenn er mit dem Pfahl interagiert - auch weitere Spieler seiner Area zufügen (und diese ebenfalls zu "Owner" machen). Fremde Spieler können in dieser Area nichts zerstören. Wenn der Spieler seinen Pfahl abbaut, wird die Area wieder entfernt.
Alternativ kann ein Serveradmin das freie Platzieren dieses Pfahls auch unterbinden - gleichzeitig kann der Admin dann selber Areas erstellen (mit dem Creative-Mode Tool [F9]) und diese als "beanspruchbar" markieren. Fortan dürfen Spieler ihren Pfahl in diesen Areas platzieren und bekommen dann darüber ihre "Owner" Berechtigung. Diese Areas können allerdings nicht vom Spieler erweitert werden. Beim Entfernen des Pfahls bleibt die Area bestehen (und kann dann wieder von einem anderen Spieler beansprucht werden). Das ist sinnvoll, wenn ein Admin selber freie Grundstücke definieren möchte (wichtig zB wenn eine Stadt entstehen soll, damit Spieler nicht kreuz und quer ihre Areas erstellen).
Es gibt verschiedene Level oder Stufen für den Pfahl. Ein höheres Level sorgt dafür, dass beim freien Platzieren eine größere Area beansprucht wird. Bei der 2. Variante (Admin definiert beanspruchbare Areas) hingegen kann der Admin festlegen, welches "Mindest-Level" der Pfahl eines Spielers haben muss, damit die Area beansprucht werden kann (Beispiel: Grundstücke in der Innenstadt sind teurer als irgendwo am Stadtrand und entsprechend kann dort ein Pfahl mit höherem Level [ergo ein "wertvollerer" Pfahl] gefordert werden).
Admins können auch festlegen, wieviele Pfahle ein Spieler insgesamt platzieren darf. Um seine Area also zu vergrößern (gilt nur fürs freie Platzieren) kann der Spieler entweder mehrere Pfahle platzieren (ein Überlappen mit eigenen Areas ist erlaubt), sofern vom Admin erlaubt, oder seinen Pfahl auf ein höheres Level aufwerten. Areas der 2. Variante hingegen können nicht vom Spieler vergrößert werden (nur vom Admin).
Außerdem können Admins einstellen, dass Areas automatisch aufgelöst werden (bzw. die Pfahle entfernt werden), wenn der Eigentümer längere Zeit nicht mehr online war.
-
red51 I have run into a problem. The console command item pickaxe 1 will not work for any of my regular players. What is the permission setting to allow the item console command? Or is it strictly a full admin command?
You have to set "itemgive" (in "command" section) to true
-
Mal eine Frage zu P2P: Wenn ich eine meiner Welten in dem Modus starte, kann ja jeder RW-Spieler in meiner Steam-Freundesliste joinen, richtig? Ist es irgendwie möglich, die beitretenden Spieler zuerst auf meiner Seite "abzufragen", also z. B. mit einem Dialog:
"XY möchte beitreten [Zulassen] [Ablehnen]" ?
Ja genau, momentan kann jeder, der dich in der Freundesliste hat, dem Spiel beitreten, so wie in der Java Version. Einen Dialog dafür einzubauen (zumindest als optionale Lösung) wäre aber vielleicht gar nicht so schlecht. Ich packe das mal auf unsere Todo-Liste
Ein Password als Zugang wäre bestimmt leichter
Das wäre an sich auch eine naheliegende Lösung, das Problem ist leider nur, dass wir eine Passwortprüfung erst durchführen können, nachdem die Verbindung aufgebaut wurde. An sich wäre das nicht weiter problematisch (ist im normalen MP auch so - wenn das PW falsch ist, wird die Verbindung einfach wieder getrennt), aber bei Steam P2P ist es etwas problematisch, wenn eine Verbindung wieder getrennt wird: Es dauert manchmal einige Sekunden, bis Steam die Verbindung wirklich trennt und neue Verbindungen wieder zulässt. Wenn jmd. also versehentlich ein falsches Passwort eingibt, kann es sein, dass er danach erstmal einige Sekunden nicht mehr beitreten kann (was dann Verwirrung stiften kann)
-
On another note we still have problems with using console commands inside a claim. We have to step outside the areas to use the console commands.
This will be likely fixed with the next update. There were quite a few issues regarding permissions in general, so I guess the commands issue is related to that. If you still experience these issues after the next update, please let me know
-
Schwer zu sagen
Aber tatsächlich denke ich auch, dass das mit dem Permission-Bug zusammenhängt - das bringt nämlich einiges durcheinander. Das nächste Update sollte diese Probleme eigentlich aus der Welt schaffen (das wird leider kein separater Hotfix mehr, sondern Teil des nächsten regulären Updates). Wenn die Probleme danach weiterhin auftreten sollten, lass es uns bitte wissen -
If "areatools" are set to true in the permission, the player has access to the creative mode area tools (F9), which means he gains full control over all areas - he can create, delete or modify areas. Actually the area tools (F9) were originally meant to be an admin-only tool. If you want a player to have access to creative mode (without the ability to change areas), make sure to set "areatools" to false, and just set the particular creative mode tools you want to allow (e.g. "terraintools", "removaltools" etc) to true. Also set "changegamemode" under "general" to true (so the player can actually use the "gm" command).
Self-claiming for areas isn't implemented yet unfortunately
You can already set an area "claimable" though, but this has no effect currently. The idea is to have a specific item in the future which allows players to claim land. If areas are set up and set to "claimable", a player could place his "claim item" in this area to claim this area. This way you could set up pre-defined plots on the server (which may be helpful if you want to create a city, and want players only to be able to claim specific parts of land).In addition to that, players will also be able (depending on server settings) to create new areas with this "claim item" (as long as these areas do not collide with existing areas). These areas are a bit different than regular areas (which were set up via area tools). Once a player removes his claim item, his self-claimed area will also be removed (this does not apply to claimable areas created by admins, as mentioned above)
-
There was no update for Rising World yesterday
But according to SteamDB, Valve updated the Steam SDK package yesterday. This happens from time to time, we have no control over this, but it should not interfere with the game or the server.Areas are stored in the "Areas.db" file in the World folder. If the file is corrupted, for example, there should be more information about that in the logs. Maybe you could upload the latest server log here (or send it via PM to me).
What do you mean about the moon being a mess? oO
-
Das ist tatsächlich momentan etwas problematisch
Grundsätzlich ist vorgesehen, dass man ingame den Namen ändern kann (was dann unabhängig vom Steam-Namen ist), ähnlich wie in der Java Version... aber diese Einstellungen sind bisher leider noch nicht drin...Momentan sind - wie in der Java Version - recht strenge Namensregeln festgelegt, aber ich weiß nicht, ob das überhaupt noch sinnvoll ist... dazu müssten wir uns mal Gedanken machen... vielleicht wäre es gut, alle Namen zuzulassen, nachteilig ist es allerdings aber für Admins, wenn sie den Spielernamen für Commands benötigen
Vielleicht ändern wir das probeweise mal, um zu sehen, wie sich das verhält.Vielleicht können wir unabhängig davon auch noch eine passende Schriftart bereitstellen, damit der Name ingame auch korrekt angezeigt wird
-
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
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
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
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
-
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!
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.
-
Wir sollten es töten bevor es Eier legt!
Aber das tritt nur auf Screenshots auf, also im Spiel selbst sind die Augen korrekt positioniert?
-
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
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)
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
-
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
)Wir werden sicherheitshalber noch einen Exorzisten konsultieren
