Posts by red51

Quote from Yaromid

Da "Posters / Images" auf Scheduled gesetzt sind; kann man mit denen schon im Blaupausen-Update rechnen?

Schwer zu sagen Wir werden in den nächsten Wochen auf jeden Fall ein paar Vorkehrungen für Poster treffen, aber ich weiß nicht, ob das passend für Blaupausen fertig wird. Im Survival-Bereich drückt der Schuh etwas, und die Spielerfraktion, die dem Bauen nicht ganz so viel abgewinnen kann, wird immer ungeduldiger - wir müssen daher unbedingt schauen, dass wir den Bereich möglichst schnell voranbringen können

Quote from Deirdre

Die Texturskalierung bei ID 159 auf 4 von einer hochauflösenden Textur nur noch eine wischiwaschi Textur herauskommen, bzw. die Vergrößerung macht

die Textur extrem unscharf. Ich denke mal, dass die Unschärfe stärker hervortritt, je größer man die Textur heranzoomt bzw. größer skaliert. Es ist mir auch bei anderen Texturen aufgefallen, aber genaue Id's weiß ich nicht mehr.

Das ist leider zu erwarten: Die Textur wird ja nicht hochauflösender, wenn man sie größer skaliert. Wenn wir wollen, dass bei großer Skalierung die Texturen weiterhin scharf sind, müssten wir mindestens mit 8K Texturen arbeiten - das ist aber für ein Spiel wie RW aber heute noch ein bisschen zu viel des Guten. Zwar technisch nicht unmöglich, aber es würde den VRAM Verbrauch deutlich nach oben schrauben, viel Performance kosten, und auf der Festplatte würde RW wohl schnell Richtung 100 GB und mehr belegen.

Du kannst aber sicherstellen, dass du in den Grafikeinstellungen die Texturqualität für Bauelemente auf Maximum stellst.

Es ist tatsächlich gar nicht so einfach, eine Spirale zu bauen Wir müssen uns das mal genauer anschauen. Eine Option, dass Pivots sich nicht um die Y-Achse drehen könnte hier evtl. helfen, das müssen wir einmal testen

Quote from ebisgames

wie groß die jeweiligen Areale dann sein werden muss dann der Admin festlegen ? ( bei selbst erstellten Areale )

Das Spiel wird eine Standardgröße vorgeben, aber Admins können diesen Wert auf ihrem Server einstellen

Most parts of the RCON tool are indeed already implemented, however, it's currently not accessible unfortunately. It wasn't ready in time for the multiplayer update, so we decided to release the RCON tool in a subsequent update.

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.

Quote from sharkbitefischer

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

Quote from Yaromid

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

Quote from lenko

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)

Quote from sharkbitefischer

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

Quote from _Joe_

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?

Quote from lenko

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.

Quote from lenko

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

Quote from lenko

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

Quote from Deirdre

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.

Quote from kluge60

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

Quote from Deirdre

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

Quote from paulevs

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...

Quote from Smoka

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).

Quote from Deirdre

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).

Quote from Deirdre

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?