Posts by red51

A small new update is available now!

    Ursprünglich war mal geplant, dass eine Auswahl der Bilder ggf. auf der Storepage bei Steam oder so erscheint. Es hat sich alles leider ein wenig anders entwickelt. Natürlich kann man weiterhin Bilder dort posten, tatsächlich war der Thread ja zeitweise auch sehr belebt, aber vor dem Hintergrund der neulichen Änderungen bei Steam und einigen bevorstehenden Umkrempelungen bei RW, würden es die Bilder vmtl. nicht mehr auf die Storepage bei Steam schaffen 8|

    Das wäre super, wenn das geändert werden würde. Wäre dann ein glätten es Wassers auch möglich, die Stufen im Wasser sind ja recht hoch für die Boote, zumindestens Optisch

    Zwar wird Wasser auch als "Textur" in den anderen Terrain-Tools verfügbar sein (also beim Hinzufügen/Löschen, Malen, sowie dem Erstellen/Löschen von Wasser in auswählbaren Areas), aber Glätten leider nicht. Damit würden sich die Stufen leider auch nicht verkleinern lassen, da dies leider durch die derzeitige "Auflösung" des Wassers bzw. den zugrundeliegenden Wasserinformationen in der Welt (blockweise) bedingt ist...

    Systemvoraussetzung laut Steam [...] Wenn ich meiner Meinung nach, mit solch einem Rechner RW spielen möchte, sollte man von größeren Blaupausen und aufwendigen Projekten mit vielen Balken und Planken die Finger lassen

    Tatsächlich handelt es sich dabei ja wirklich nur um die absoluten Minimalanforderungen, um das Spiel zu spielen. Spätestens wenn die Einstellungen (vor allem die Sichtweite) auf ein Minimum geschraubt wird, wird man mit solch einer Hardware i.d.R. auch auf allen Servern spielen können. Schön ist das natürlich nicht, aber dafür sind ja auch die "Empfohlenen Systemvoraussetzungen" da, an die man sich dann eher orientieren sollte.
    Erfahrungsgemäß wird den Systemvoraussetzungen in den meisten Fällen aber eh nicht ganz so viel Beachtung geschenkt... 8|


    so das die Minimal Voraussetzung auch wirklich zum spielen ÜBERALL ausreicht

    Das Problem ist aber auch, dass es beim Bauen keine Beschränkungen gibt, sodass man ab einem bestimmten Detailgrad irgendwann jede Hardware in die Knie zwingen kann... die einzige wirklich "sichere" Lösung hierfür wäre, das Bausystem zu beschneiden. Bei anderen Spielen gibts ja designbedingt immer eine Art "Obergrenze", wieviel überhaupt bzw. mit welchem Detailgrad gebaut werden kann (bei Minecraft oder 7dtd eine blockweise Ausrichtung, bei Rust oder Ark ein modulares Bausystem etc).


    Andererseits spielen viele Spieler (tatsächlich sogar die Mehrheit, ganz zu meiner Verwunderung) eher nur im Singleplayer, bzw. kommen mit den Problemen bei extrem detailreich bebauten Gegenden tendenziell nur sehr wenig bis gar nicht in Berührung. Es wäre schade, wenn diese Spieler durch exorbitant hohe Mindestanforderungen möglicherweise abgeschreckt werden (zumal "detailreich bauen" ja nicht das einzige Feature im Spiel ist) ;)


    Bei den Servern wäre es gut wenn du mal eine realistische Empfehlung mit veröffentlichen würdest. Ich gehe mal davon aus das bei Mietservern vom Ram abgesehen die Hardware ok ist. Aber wieviel Ram sollte ein Server wirklich haben damit 10,20 oder 50 Spieler Serverseitig ohne Probleme spielen können.

    Naja, prinzipiell gibt es eine grobe Aussage darüber hier: Dedicated Server Setup
    Bei Servern wird es etwas schwierig, konkrete Aussagen über die Mindesthardware zu treffen. Zwar spielt der RAM eine große Rolle, ist aber nicht der einzige entscheidende Faktor. Bei RW sind auch weniger die maximalen Spieler ausschlaggebend, sondern eher, wieviel wirklich gebaut wird und inwieweit Bilder usw. verwendet werden. 20 Spieler, die sich eher ein kleines spartanisches Lager bauen werden den Server weniger auslasten als 2 Spieler, die ein gigantisches Bauwerk mit Millionen von Bauteilen planen...


    Vor allem wenn es um "Gameserver" geht, haben wir leider schon einige schwarze Schafe entdeckt. Hier werden - aus (nachvollziehbaren) Gründen der Rentabilität - meist viele Gameserver auf einer Maschine gehosted. Problematisch wird es, wenn zu viele Instanzen auf derselben Maschine laufen und diese unterm Strich ständig ausgelastet (bzw. eher schon "überlastet") ist. Man kann hier nicht verallgemeinern, aber da in vielen Fällen der Fokus eher auf "Slots" und "RAM" liegt, ist es meist nicht möglich, Rückschlüsse auf die Hardware zu ziehen.



    Effektiv wird ein Server mit 32 GB, aber grottig langsamer Festplatte wesentlich mehr Probleme bei RW bereiten als ein Server mit 2 GB RAM und guter Festplatte. Wir haben schonmal Tests mit einem 1-Kern vServer (1 GB RAM) durchgeführt, welcher preistechnisch irgendwo bei 2-3 EUR liegen würde. Hier konnte man immerhin zu dritt ganz vernünftig spielen (natürlich wären gigantische Bauwerke problematisch geworden). Andererseits führten manche Tests mit fertigen Gameservern, welche preislich eher bei 10 EUR liegen, schon mit 1 Spieler und ganz ohne irgendwelche Bauwerke (also ganz frische und unberührte Welt) teilweise bereits zu massiven Problemen, die in Richtung "unspielbar" tendierten =O


    Gesetzte Lampen bleiben dunkel. Weder Chunkwechsel noch kompletter Relog hat etwas gebracht

    Das ist eigenartig... die Beleuchtung wird separat in einem eigenen Thread berechnet, wird das Licht denn nach wenigen Sekunden dargestellt?

    Also beim "undoblueprint" Command gibt es wie schon gesagt definitiv einen Fehler, der dazu führt, dass nicht alle Teile gelöscht werden. Das tritt sowohl im Singleplayer als auch Multiplayer auf und hat nichts mit der Serverperformance o.ä. zutun. Beim Platzieren hingegen ist es eigenartig, dass es in manchen Fällen gehäuft Probleme gibt, in anderen wiederum gar keine. Generell hängt das schon eher mit der Serverperformance zusammen, aber auch mit vielen anderen Faktoren. Hier können manche Plugins und vor allem Lua Scripte einen wesentlichen Einfluss darauf haben.


    Na jedenfalls habe ich in dieser Diskussion herausgefunden, dass ich den 1 GB Mietserver einsparen kann, wenn ich "mit Freunden Spielen" schon das 4fache habe

    Oh, nur um Missverständnisse zu vermeiden: Der Memoryverbrauch des Client ist nicht vergleichbar mit dem Memoryverbrauch des Servers. Wenn der Client viel braucht heißt das nicht, dass auch der Server viel braucht (und umgekehrt). Client und Server haben jeweils ganz unterschiedliche Arten des Memoryverbrauchs.


    Die editc Färbemethode ist auch nur mit der Nase auf dem Objekt möglich

    Das sollte mit dem nächsten Update nicht mehr so sein^^

    Wir werden im nächsten Update eine Höhenanzeige dazupacken, auch Blueprints werden - wenn man sie mit der Enter-Taste auf "Undurchsichtig" stellt - dann korrekt im Wasser gerendert (also dass die Bereiche, die unter Wasser sind, auch korrekt vom Wasser verdeckt werden) ;)

    The blueprint limitation regarding the view settings is basically just that the blueprint will only store parts of the building which are actually visible (the "detail distance" is the important setting here). The view distance is basically the "full view distance", i.e. it determines how far away chunks (only a low poly version of the chunks) can still be seen. The detail distance is the view distance for buildings etc. For example, when setting a view distance of 50 and a detail distance of 21, this means the game will render a 50x50 area of "low poly" chunks (containing vegetation, but no buildings and constructions) and a 21x21 area of full detail chunks (containing blocks, construction elements, grass, small plants etc).


    About the other settings, I've just created a new topic for that: Graphics settings

    Here is an overview and description of all settings in the graphics menu.


    Display ModeToggles between "Windowed" mode, "Fullscreen" mode and "Fullscreen Windowed" mode. It's recommendable to use the latter mode.
    ResolutionThe resolution of the game. It's recommendable to use your desktop resolution. This setting is handled automatically if "Display Mode" is set to "Fullscreen Windowed".
    View DistanceThe total view distance (low poly chunks which do not contain buildings and other constructions). Has a moderate impact on performance.
    Detail DistanceThe detail view distance (detail chunks which contains blocks, construction elements, objects etc). Has a big impact on performance.
    Anisotropic FilterThe lower this setting, the blurrier textures appear when viewed at a certain angle.
    VSyncIf enabled, the framerate will be locked to your monitor frequency in order to eliminate screen tearing. If you don't experience any screen tearing, it's recommendable to keep this disabled.
    View adjustmentOnly works while a world is loaded. Contains various settings for the player view (FOV, color, chat settings etc).




    LightscatteringLight scattering effect for the sun, also referred to as "god rays". Has a moderate impact on performance.
    LightglareEnables/disables the "halo" around light sources. Has a moderate impact on performance.
    Physical debrisIf enabled, physical debris will spawn when destroying blocks or terrain.
    Ambient Occlusion (SSAO)Adds some subtle shadows to corners and crevices etc. You can set the intensity separately. Has a big impact on performance.
    Grass MaskingIf enabled, grass will no longer be visible through certain objects (more precisely, grass will be occluded dynamically).
    FXAAFast anti-aliasing. It "smoothes" sharp edges on the screen. It's recommendable to keep this setting enabled, since its impact on performance is barely noticeable.
    Depth of FieldIf enabled, distant objects appear blurred. You can set the distance separately.
    RefractionsEnables/disables light refractions, i.e. the environment appears distorted when looking through glass or water. Has a big impact on performance.
    Water ReflectionsEnables/disables dynamic water reflections. Has a moderate impact on performance.
    Triplanar LOD MappingIf enabled, textures on steep mountains will not appear "stretched".

    Hmm... I'm not sure if one of these plugins modify the chat output... you could try to unload the plugins by typing "unloadplugins" into console and see if the chat name still has the "Guest" prefix (type "reloadplugins" to reload the plugins or better restart the server).


    Alternatively you could send me a log file of the server, either post it here or send it via PM ;) You can find the log files in the "Logs" folder in the server directory.

    What do you mean with "removed all groups"? Do you mean that you deleted the permission files? Did you restart the server after deleting the files? Even if the player remains in a group which doesn't exist anymore, this group should not have an influence on the chat or any other player permissions 8|


    Do you run any plugins?

    I had the feeling that RW was using up all of my RAM. I'm not sure if that could lead to a reboot

    Unfortunately Rising World / Java cannot allocate more RAM during runtime, so there is always a fixed amount of memory that gets allocated when starting the game (depending on how much RAM there is available). For example, if you have 8 GB of RAM, the game will try to allocate up to 6 GB. But it's possible to override this setting by setting up a launch parameter in Steam.
    However, even if the game would use more RAM (e.g. trying to allocate 16 GB while your system has only 4 GB), this shouldn't lead to a system crash (the RAM that's already in use by Windows or any other programs cannot be allocated by Java anyway) ;)

    I'm glad to hear this issue is solved ;)
    In general, it's important to cancel an event in the same frame / tick, so basically the event instance is "worthless" in the next frame (so it cannot be used in a callback [which is always called a few ticks later - depending on how long it takes to get the response from the client] or in another thread). So the approach mentioned by @Minotorious would be the proper way to solve this :)

    Danke für den Hinweis! Versuche bitte einmal, in Steam folgenden Hotfix herunterzuladen: Gehe dazu via Rechtsklick auf RW in deiner Steam Bibliothek -> Eigenschaften -> Betas -> wähle "hotfix - native object mgr" aus. Danach sollte dieser Fehler eigentlich nicht mehr auftreten (falls doch, lass es uns bitte wissen). Mit dem nächsten Update werden diese Änderungen in den stable Branch übergehen ;)

    Noch ein kleines Manko. Wenn Raster gebaut wird, und dann später wieder angesetzt wird, entstehen Lücken.

    Das müsste eigentlich auch mit dem nächsten Update behoben sein, denke ich. Ein jetziger Bug (welcher auch dafür sorgt, dass "undoblueprint" nicht korrekt funktioniert) sorgt dafür, dass sich beim Platzieren die Position, Größe und Rotation des Elements durch Rundungsfehler geringfügig ändern kann. Ich könnte mir vorstellen, dass dadurch diese Lücke zustande kommt. Am besten nach dem nächsten Update mal beobachten und falls es trotzdem noch auftritt, am besten mitteilen ;)

    My boyfriend just told that he is unable to join servers on both his devices either. It's the same network. May it be a network issue?

    If your friend's having the same problem, it's likely related to the network. Are you maybe behind a NAT? This if often the case when living in a student dorm, for example.


    Turns out I'm having the exact same issue [...] Is this possibly a WIN10 issue?

    Hmm... since the majority of users already use Win10, it's unlikely that it's a general Windows 10 issue (although it might be related to Win10 of course) :huh: Did you try to join a specific server, or did it happen with every server? Do you use any antivirus software? Some antivirus programs still block the connection even if they're turned off. Do you use the windows firewall, or some additional firewall software? Do you run something like Windows Defender, for example? Is your Windows up-to-date (do you participate in any Windows betas, e.g. Windows Insider program etc)?

    We will definitely add the "PlayerIllegalStateEvent" with the next update :)
    The "illegal state error" related to item moving / splitting stacks should also be fixed with the next update. If you still experience this issue after the update, please let us know ;)

    maybe calling some sort of resync or reconnect then?

    Well, if too many "illegal state errors" occur for a certain player, he will be kicked, therefore he's forced to reconnect anyway (which will fix the desync) ^^ However, the whole "illegal state error" stuff is also in place to protect the server from hackers. Right now there aren't many hackers in RW (if any), so this error is mostly caused by bugs. Ideally every bug which triggers this issue (or more precisely, which causes the desync) will be fixed in the long run, so at the end of the day, this might be a reliable server protection.


    If an illegal state error occurs, the best thing is to report this issue (with a server log or something like that) :)