Posts by red51

    Leider benötigt die Oberflächenbearbeitung relativ viele Zusatzdaten, deshalb kann nur dadurch nur eine Seite verändert werden (in dem Fall immer die Oberseite)... :/


    Bei der Oberflächenbearbeitung werden direkt die oberen Eckpunkte verschoben - daher funktioniert das leider nicht bei der Kugel oder diversen anderen Bauelementen...


    Es ist aber die Überlegung im Raum, das insofern abzuändern, dass quasi immer ein Würfel als Referenz genommen wird, und stattdessen alle nahgelegenen Punkte bzw. "Vertices" entsprechend zu verschieben. Dadurch könnte man dann auch die Kugel bearbeiten (die würde dadurch verzerrt werden). Das würde aber auch mehr Daten verursachen als der jetzige Ansatz, und wir müssten uns überlegen, wie wir sicherstellen, dass bisherige Bauten dadurch nicht beschädigt werden :thinking:


    Leider kann ich momentan noch nicht sagen, ob das funktioniert oder wann das kommen würde :( Wir müssen damit ein wenig herumexperimentieren (wahrscheinlich aber erst, sobald die neue Version die Java Version auf der Storepage ersetzt hat)^^


    Oder/auch eine vertikale Spiegelung zu ermöglichen?

    Das ist grundsätzlich möglich: Mit dem Konsolenbefehl flip y kannst du den aktuellen Block entlang der Y-Achse spiegeln. Die zu bearbeitende Oberfläche wird dann auch gespiegelt (ich stelle gerade fest, dass es da zu Anzeigefehlern kommt - wir fixen das mit dem nächsten Update, kann aber auch durch aus- und wiedereinschalten der Oberflächenbearbeitung behoben werden) ;)


    Wir überlegen noch, wie wir das Spiegeln evtl. ins Radial-Menü unterbringen... vll dass beim Spiegeln ein Untermenü geöffnet wird, in welchem man auswählen kann, entlang welcher Achse gespiegelt werden soll

    Und dachte auch schon daran dort mich mal zu Probieren, und da karm die Frage auf ob sowas wie "eine Passende DLL" die dann auch Unity interners nutzen kann (Dabei dachte ich mehr an neue Figuren, Animationen und was mann da noch alles anstellen kann) besser/einfacher wehre :saint:

    Achso, naja, leider wird das nicht so einfach funktionieren :/ Rising World verwendet (anders als die meisten Unity-Spiele) kein "Mono" (bei welchem man die Assemblies bzw. DLLs des Spiels einfach verändern oder austauschen kann), sondern IL2CPP - damit wird der Spielcode beim Kompilieren in C++ umgewandelt. Das ist zwar bei weitem nicht so schnell wie der Teil des Spiels, der direkt in C++ implementiert ist, aber immernoch wesentlich schneller als Unitys veraltetes Mono (hier habe ich mal einen Vergleich gepostet) ^^


    Das bedeutet aber auch, dass der Spielcode nicht so einfach modifiziert werden kann... Das ist einerseits vorteilhaft, da Hacker & Co es schwerer haben, das Spiel zu ihren Gunsten zu ändern (richtige Hacker wird das natürlich nicht abhalten, aber zumindest die ganzen Script-Kiddies^^), andererseits kann das Spiel aber auch nicht mehr so einfach modifiziert werden.


    Bei letzterem Punkt muss man aber dazu sagen, dass sich das natürlich nur auf codeseitige Änderungen bezieht. Assets und diverse Spieleigenschaften können trotzdem verändert werden, denn einerseits speichert das Spiel vieles in der "definitions.db" im Spielverzeichnis (zB alle Eigenschaften von Items, Npcs, Wetter, Rezepte usw), andererseits liegen alle Modelle und Texturen in "Asset Bundles" vor (die grundsätzlich modifiziert werden können). Wenn jemand also zB ein anderes Modell für eine Spitzhacke einbauen möchte, dann liegen diesem "klassischen" Modding-Ansatz keine Steine im Weg ;)


    Der goldene Weg ist aber natürlich die Plugin-API, da hierüber sichergestellt wird, dass zB im Multiplayer auch alles richtig synchronisiert wird ^^


    das ist eine Gute Frage, Spontan würde ich sagen mit "Sprung Markern"
    -wenn zu der Zwischenwellt geweckselt wird, muss der Ziel Punkt mit angegeben werden und Wo der Spieler war wirde hinterlegt (bei den neuen Dynamischen sachen, muss dan ebend das Plug in sich das merken)

    Bei einer API-basierten Lösung wäre das auf jeden Fall sinnvoll, dass die Position in der Zwischenwelt natürlich entsprechend gesetzt und geändert werden kann.


    Das scheint mir schon die sinvollste Lösung zu sein, dann sind Server betreiber und Plugin Ersteller zusammen verantworlich für die Performance

    Ich denke auch, dass diese Lösung wohl am wenigsten Probleme bereitet :thinking:


    Da wehre vieleicht ein ServerVorgaben, für die Plugins gut, quasie das mann im Plugin schon Größenvorgaben berücksichtiegen kann
    Und eine gesicherte Mindest Größe z.b. 512x512x512 (sollte doch jeder server schaffen)
    Dann kann das Plugin auf ein Minimum abgestimmt werden und sich ggf. ausbreiten

    Das kommt darauf an... wenn es wirklich nur eine leere Zwischenwelt gibt (also ohne Landschaft), in welcher der Betreiber oder Admin also alles selber erschaffen müsste, bräuchten wir vmtl. nicht unbedingt eine Größenbeschränkung... denn einerseits hat der Betreiber es dann ja selber in der Hand, wieviel er dort baut (oder es zulässt, was da gebaut wird), andererseits ist das auch von der Datenmenge meist eh nicht so viel. Oder anders gesagt: Bei Gebäuden ist es quasi eh egal, ob sie nun in der Hauptwelt oder Zwischenwelt liegen. Ungünstig ist nur das Terrain bzw. die Landschaft, da dies ja in dem Fall doppelt vorhanden wäre (was aber wegfällt, wenn die Zwischenwelt kein Terrain generiert).


    :wacko: Wie kompliziert wehre es LOD (Umgebungshintergrund) umgebung mit in die Zwischenwelt zu nehmen, die wehre ja schon aus der Normalen Map da?

    Naja, das Problem ist, dass das LOD ja die Hauptwelt repräsentiert, d.h. alle Änderungen in der Hauptwelt werden darin also sichtbar sein... andererseits aber eignen sich die LOD-Chunks aber auch nicht für den Nahbereich, d.h. hier bräuchten wir in jedem Fall also weiterhin normale Chunks :/

    Wie wäre es denn diese "Zwischenwelt" größenmäßig zu begrenzen und, wie die Testwelt, nur eben und ohne Vegetation, NPC, etc. zu erstellen? Zudem nicht für jeden Spieler eine einzelne, sondern der Admin müsste entscheiden ob es nur 1 je Server gibt (z.B. für Admins/Mods) oder ob bestimmte Spielergruppen ihre eigenen bekommen. Das dürfte doch die Performanceprobleme minimieren?

    Grundsätzlich ist das möglich, und je weiter diese Welt begrenzt wird, desto kleiner auch der Einfluss auf die Performance. Die Frage ist nur, wo zieht man die Grenze bzgl. Welt-Größe? Und wie sieht sie aus, also was für ein Terrain wird dort generiert (ggf. Flachland)? Das wird vmtl. etwas sein, wo man es nicht jedem recht machen können wird... Person A braucht vll nur einen 100x100 Blöcke großen flachen Bereich, Person B benötigt zwingend eine ganze Insel, Person C hätte an der Stelle gerne einen riesigen Ozean während Person D gar keine Landschaft braucht, sondern eh nur Inneräume dorthin verlagern will...


    Wenn die Zwischenwelt in ihrer Größe begrenzt ist, wirft das auch andere Fragen auf... denn gerade beim Wechsel zwischen normaler (in ihrere Größe nicht begrenzte) Welt und (größentechnisch begrenzte) Zwischenwelt stellt sich die Frage, wie die Koordinaten dann umgerechnet werden. Angenommen ein Spieler befindet sich irgendwo fernab vom Nullpunkt (zB bei 30k) und soll nun in die deutlich kleinere Zwischenwelt gebracht werden, um an dieser Stelle einen "geheimen Lagerraum" zu bauen - das würde bei einer begrenzten Zwischenwelt dann Schwierigkeiten mit sich bringen...


    Vll wäre es da universeller, wenn die Zwischenwelt zwar nicht begrenzt, aber dafür standardmäßig "leer" ist, also kein Terrain vom Spiel aus beinhaltet, man dort also nur bauen kann :thinking: Schwieriges Thema :saint:


    Aber unabhängig von dieser "Designfrage" ist die Implementierung so eines Systems leider dennoch mit einigem Aufwand verbunden, da das Spiel das Konzept verschiedener Dimensionen bisher nicht kennt... es müssten dafür einige Teile umgeschrieben werden. Für Spielersyncro etc. ist das kein Problem, aber das Welt- bzw. Chunk-Management wird dadurch komplexer :|

    Also eigentlich wird die Rotationsgenauigkeit dauerhaft gespeichert, sowohl beim Ändern über das Radial-Menü als auch beim Ändern über die Konsole (via setr) :wat: Auch nach einem Neustart des Spiels sollte der zuletzt eingestellte Wert aktiv bleiben (auch wenn er über setr geändert wird) :thinking:


    Wenn ihr sagt, dass das nach dem Beenden des Spiels nicht aktiv bleibt, bin ich etwas irritiert... ich konnte das Problem bei mir nämlich leider nicht reproduzieren (und es wäre wie gesagt auch ungewollt, wenn dem so ist)...


    Dementsprechend wäre es ja auch doppelt gemoppelt, wenn man irgendwo einen Standardwert hinterlegen kann (weil das lediglich für neue Spieler relevant wäre, die das Spiel zum ersten Mal starten - hier ist aber eh unwahrscheinlich, dass diese die config anpassen, bevor sie RW das erste Mal gespielt haben).


    Das Spiel speichert die Einstellung übrigens in der config.properties unter "Game_BuildingRotatePrecision", "Game_BuildingMovePrecision" und "Game_BuildingScalePrecision". Das sind die Werte, die über setr/setp/setl bzw. über das Radial-Menü auch geändert werden.


    Wichtig ist aber noch der Hinweis, dass Bauelemente, Pflanzen und Blaupausen eigenständige Einstellungen haben. Wenn man also für Blöcke die Rotationsgenauigkeit ändert, dann gilt das nicht für Blaupausen und umgekehrt. Die Idee dahinter war, dass man bei Blöcken ja ggf. mit anderen Präzisionen arbeitet als bei Blaupausen... wir könnten das aber sonst auch ändern.


    Ist das vielleicht der Grund für die Verwirrung? Ansonsten klingt das für mich nach einem Bug :monocle:

    ist es möglich den Umfang des Geländewerkzeugs zu vergößern, um zb eine sehr große Fläche platt zu machen oder zu erheben?

    Wie Avanar und Deirdre schon sagen, mit Numpad + und - kannst du das Raster verkleinern/vergrößern (leider momentan aber noch auf eine maximale Größe beschränkt). Um eine Fläche zu plätten bzw. zu ebnen, könntest du Enter drücken - damit wird quasi eine Art "Obergrenze" gebildet, bis zu welcher Höhe Terrain aufgeschüttet werden soll. Mit Bild-Auf und Bild-Ab kann diese Obergrenze nach oben oder unten verschoben werden. Am besten funktioniert das dann i.V.m. dem Werkzeug 1 (unter F5) ;)

    Die Oberflächenbearbeitung ist in der Tat etwas schwierig zu bedienen, daher würde ich das nur empfehlen, wenn man das unbedingt benötigt :D Ansonsten kannst du (wenn die Oberflächenbearbeitung nicht aktiv ist) den Block ganz normal mit Shift und den Pfeiltasten bzw. Bild-Auf und Bild-Ab skalieren, wie Avanar und SonoBionda auch erwähnen. Wenn du den Block proportional skalieren willst, kannst du auch Shift und +/- drücken ;)


    Zu B: Wenn du den Block mit der Oberflächenbearbeitung verändert hast, dann muss beim Zurücksetzen (Backspace sowie Shift+Backspace) ebenfalls die Oberflächenbearbeitung aktiv sein - sonst wird nur die normale Skalierung bzw. Drehung zurückgesetzt^^

    red51 do you think it's faisible to have Crabs with this initial NPC update? Sorry for asking, but I really love the idea of sandy beaches with this little guys running all over to catch them :wacko:

    Crabs are actually on our to-do list :) Unfortuantely we still don't have a proper model ready for that, so I'm afraid they won't make it into the initial NPC update... but they're definitely planned ^^


    2) I wish we can have scaffolding. I severely need it while building and for my clearing projects. If possible, would it be too much to ask to have scaffolding in the upcoming update? I'm struggling to complete projects.

    Maybe we can get the scaffoldings ready for the next update :D I can't guarantee that though, so if they don't make it into the npc update, they will be ready shortly after it^^

    The ping is indeed to be expected, but the game shouldn't crash :wat: Do you still run into this issue? Maybe you could send us a report? If the game crashes again, please restart the game (to the main menu), then open the console (key ~ or `) and type "report" (maybe add some additional information like "game crashes when joining a server") and send the report ;) The report automatically attaches the current and the previous log, so if you do that right after a crash, it may contain a few more information about it ^^

    Ich habe den Beitrag mal in einen eigenen Thread verschoben, da das ja nicht direkt auf die UI bezogen war :D


    Was die Zwischenwelt angeht, es gab damals schonmal Überlegungen zu sowas wie verschiedenen "Dimensionen", sprich dass sich nur Spieler sehen, die sich in derselben Dimension befinden. Sowas ist allerdings etwas kompliziert umzusetzen, zumindest was die Welt selber angeht - denn grundsätzlich müsste für jede Dimension eine eigene Welt bereitgehalten werden, was auch insgesamt deutlich größere Anforderungen an den Server stellt (einerseits ein viel höherer RAM-Bedarf, andererseits aber auch mehr Last für den Server, wenn verschiedene Welten in verschiedenen Dimensionen synchronisiert werden müssen)...


    Denkbar wäre lediglich, dass jede andere Dimension keine Weltgenerierung hat, sondern immer komplett leer ist (und der Betreiber selbst dort Landschaften anlegen müsste). Dazu müsste man sich mal Gedanken machen :thinking:


    Ansonsten wird es aber zumindest eine Möglichkeit geben, einen Spieler auf einen anderen Server weiterzuleiten. Theoretisch könnte man so also die Sache mit den Zwischenwelten lösen. Leider wäre das aber nicht nahtlos, d.h. beim Transit zum anderen Server würde der Spieler einen Ladebildschirm haben usw...


    Erweiterte Frage:
    Eigene klein Welt generieren und Bearbeiten per API.
    Wehre soetwas überhaupt mit der geplanten API möglich oder ginge das nur/einfacher über eine Unity Schnitstelle

    Also die neue API wird auf jeden Fall die Möglichkeit bieten, die Weltgenerierung zu beeinflussen ^^ Man kann auf dem Wege also theoretisch ganz eigene Weltgeneratoren schreiben.


    Was genau meinst du mit "Unity Schnittstelle"?^^

    Do you have plans to turn more parts into C++ code or it will remain C#?

    This would be only beneficial for performance-critical things, and it only works for things which don't have much dependencies to other objects and classes ^^ Communication between C# and C++ is a bit tricky, because we can't access managed objects from C++ easily. And on the other hand, we can't turn everything into unmanaged pointers or structs on C#... in general, Unity isn't really made for C++ programming unfortunately, so you can't access the Unity API from C++ directly unless you write a wrapper for it - but this introduces other problems and limitations, and also adds another layer of complexity due to not being able to communicate with Unity directly :dizzy:


    It wouldn't really help if we move causal stuff (e.g. UI handling, inventory handling etc) to C++, for example (in fact that would do more harm than good)...


    But there are still a few performance-critical things which are still written in C# (e.g. chunk modifications). This is something we definitely want to port to C++, but this is a bit tricky (because it still requires access to managed data and also requires proper synchronization of managed [C#] threads), so unfortunately I have no ETA for that yet :/

    An early (incomplete) API release will be available with the next update :) The main focus of that release will be the UI, so some other things may not work fully yet^^


    Will it make possible to change, for example, inventory size of a player or his hotbar? Or this will only affect visuals and API for inventory interactions will be separated?

    Changing the style through the Internals class will only affect visuals ^^ The Style class is mostly based on Unitys IStyle interface, so you can change almost all properties which are listed in their docs.

    I've added a new example image above showing the inventory with a replaced background image (just used the wooden Java background image in this case) ;)


    However, you can't add new inventory slots that way. We may add a method to attach new UI elements to any existing game elements, so in theory, you could add new slots then, but they won't work at all (because the inventory code isn't aware of these additional slots)

    This sounds like DLSS will most likely improve the performance in your case :) About the weather issue, hard to tell if there is really an issue... if you run again into a situation where the weather seemingly has a considerable impact on performance, you could press F3 and check out the second to last line: If either the FMOD CPU has a value greater than ~ 30 or if the "Channels" (at the end of that line) are > 60 or the Virtual Channels are > 500, maybe send a report ^^

    The Java version will definitely remain playable ;) We may release a bugfix update in the future if there are still some people playing the Java version (although it's unclear whether or when this may happen), but there are no more content or feature updates planned unfortunately...


    About the language used by the new version (even though that's a bit OT :D ), large parts are indeed written in C#, but most performance-critical things (e.g. chunk generation) are implemented in plain C++. The game is also mostly working with native memory (i.e. raw pointers instead of arrays), which isn't managed by Unitys ancient garbage collector (therefore it causes less frame drops during garbage collection).

    When compiling the game, however, all C# code is turned into C++ via Unitys IL2CPP. It's by far not as efficient as plain C++, but still faster than C# - although that's not the fault of C# (I don't think that C# is considerably slower than Java), actually it's Unitys old Mono implementation that is so slow.

    Wie wird das Nahrungs-/Trinkbedürfnis genau aussehen? Können die Tiere verhungern wenn man vergisst sie regelmäßig zu füttern? Ich hoffe man wird trotzdem Reisen können ohne dass die Tiere wegsterben.

    Wenn das implementiert wird, dann wird das vmtl. recht großzügig ausfallen ^^ Sodass Tiere sehr lange ohne Nahrung auskommen, in dem Fall dann aber zB keine Eier, Milch etc. mehr geben und ggf. auch der Nachwuchs langsamer heranwächst.
    Es wird aber auch eine automatische Futtermöglichkeit geben (die man aber natürlich von Zeit zu Zeit neu befüllen muss) ;)

    Hi red51 , by this do you mean we could start testing out the UI on a test server even if the UI doesn't have any method calls to update? If so, I would certainly be interested in this.

    We could prepare a preview version of the API for the next update :) It wouldn't be a full API release, i.e. some things (like model loading, database handling etc) don't work, and some events are not wired yet - but the UI part is almost ready now (we still have to implement image loading, but that should be ready in time for the update). Basically you could even use it in production (although there is still a chance that the API may cause crashes, especially if you use non-UI related events and methods) ^^

    We've implemented the UI part of the new API, so we can finally share more information about it. Please let us know if you're interested in a preview version of the API (specifically for the UI).


    If you have any questions or feedback, don't hesitate to post here :)



    Workflow


    The new version internally uses Unitys new UI Toolkit (formerly known as "UI Elements"), which is inspired by CSS. This means the new API no longer maintains a UI based on absolute and relative coordinates, instead they will use a flex layout. You can update the Style of a UI element directly - it determines the visual appearance and position of the element and is mostly based on Unitys IStyle class. However, you can still work with absolute and relative coordinates if you like.


    The new API has two workflows, and both can be combined. The main workflow is the Style-based workflow, while all UIElements also offer some simplified helper methods (like setPosition(), setSize(), setPivot() etc). The latter resembles the old GUI workflow, but internally these methods just update the underlying style.


    When using absolute coordinates, the reference resolution is always FullHD (1920x1080). The positions will be identical on other 16:9 resolutions, so if you place an element at the center using absolute coordinates (X: 960 Y: 560), it will be also centered on 1280x720 or 3840x2160 (4K) (and other 16:9 resolutions). The size will also be identical on all screens, i.e. if the element has an absolute width and height of 128 pixels, the game will resize the element on other resolutions as well.


    The initial API release will provide at least a base UIElement class, a UILabel and a UITextField.


    UIElement is the base class for all UI elements (similar to the old GuiElement class). You can use it as a container or panel. You can also add a background image to them, so they automatically replace the old "GuiImage" class. In other words, the UIElement class is now a combination of the old GuiElement, GuiPanel and GuiImage classes. UILabel is very much like the old GuiLabel class, while UITextField is very much like the old GuiTextField class.


    Note: When using the simplified workflow methods, the origin of the screen (0, 0) will be in the top left corner (unlike the Java version, where the screen origin was in the lower left corner). When working with the style, however, that doesn't matter, because you set the top, left, right and bottom distance on the style directly.

    When using relative values (percent values), the game now uses values between 0-100 instead of 0-1. So if you were using 0.5 in the Java version, this now becomes 50.



    Style and HoverStyle


    In addition to the regular style, all UI elements also have an additional, optional hoverStyle field: It determines the style of the element when it gets hovered with the mouse cursor. This way you could change properties like the color, size etc (e.g. when hovering the element, the color may change to blue or the font size of of the label may become bigger to achieve a hover effect).

    The game handles this automatically under the hood, so when the mouse enters the element, it automatically sets the hoverStyle, and when the mouse leaves the element, it automatically sets the original style.


    The hoverStyle is only used if the element is marked as "clickable" (so the element reacts to the mouse and mouse input). This is done through the setClickable() method (similar to how it worked in the Java version). In addition to the "clickable" flag, there is also a "pickable" flag: It determines if an element should "block" mouse clicks (irrespective of the clickable flag). If "picakble" is set to false, the mouse cursor will ignore the element, so you could click on another element which is behind the panel. If set to true, the panel will block the mouse input, so you couldn't click on elements behind it.



    Childs and Parents


    The new UI also supports childs and parents, like the old GuiElements. You can attach a UIElement to any other UIElement (which then becomes the new parent). The style (position, size etc) of a child then depends on the parent style. Childs also inherit certain style properties (like the font size) - unless they explicitly set them on their style. Moving a parent moves all childs automatically.


    Unlike the Java version, you no longer have to call Player.addUIElement() for all childs - you only have to call it for the parent now, and the game handles all childs (and childs of childs) automatically.



    Modify Game UI


    The Internals class will provide a way to modify the Style of any game UI element. E.g. change the color of the health bar or the background color or image of any game menus. However, you have to use this with caution.



    Message boxes


    The new UI will also provide a simple way to show message boxes to the player. The Player class will provide various showMessageBox() methods for this, where you could provide a callback to get the user selection. There are also similar methods to bring up a color picker or an input dialog, for example.



    Examples


    This is a basic example which creates a black panel centered on the screen with a size of 500x300 pixels containing a centered label. It uses the simplified workflow, which resembles UI creation in the Java version:





    With the new UI, we have a lot more control over our UI elements. We could have round edges on our panels, for example, or rotate elements. The next example uses almost the same code as above, but modifies some style properties (to have rounded upper left corner on the panel and also to rotate the label by 90 degree):





    The next example uses the new flex layout: We want 10 panels to be evenly positioned around the center. We first create an invisible container (we call it "screen") which covers the whole screen. We set "pickable" to false, so it does not block our mouse clicks. We set absolute coordinates, and set top, left, right and bottom to 0 (in other words: the distance to the top, left, right and bottom will be 0 px, so the element covers the whole screen).


    We set the alignItems property to "Center" (because we want our child elements to be centered), justifyContent will be set to "SpaceAround" (so the elements will be evenly positioned in the panel) and flexDirection will be set to "Row" (so they're aligned vertically instead of horizontally).


    For the child elements, there is not much we have to change: We set the width and height to 128 pixels, set a random background color (using a util method) and add them as childs to the "screen" parent. That's it!





    Legacy GUI


    We're thinking about providing a plugin which brings back the old GuiElements from the Java version. They will be based on UIElements. This is mostly for reasons of compatibility (so if you have a big complex UI, you don't have to recreate it from scratch). Please let us know if this is important for you.

    Hey, DLSS (on NVIDIA cards) and FSR (mostly for AMD cards) will indeed improve the performance, but only if you're currently gpu-bound (which is likely on 4K). To get a rough idea of the performance improvement by these techniques, you could go to the graphics settings and change the "Resolution scale" slider to a lower value, e.g. 60% (the game will look ugly then, but this is probably roughly the fps gain you could expect from DLSS/FSR) ;)


    However, it's weird that the weather causes such an FPS drop in your case :wat: The weather effects (rain and snow) spawn quite a lot of particles, but the particles are calculated and handled on the GPU, which makes them very efficient. The wind, on the other hand, always has a fixed cost, i.e. it doesn't matter if it's good or bad weather, so I don't think that's causing this issue :thinking: Maybe it could be something else (maybe a sound issue, consuming too much CPU power etc)..

    Do you also experience the FPS drop if you create a new world, then change the weather by typing weather heavyrain 1 or weather heavysnow 1 or weather storm 1 into console?


    Maybe you could send us a report (so we can make sure there isn't something else causing this issue)? To do that, wait until you run into the frame rate issues, then open the console (key ~ or `) and type "report", maybe add some information like "bad weather = fps drop", then send the report :)