Posts by red51

A new update is now available, introducing "Points of interest" and many more changes!
Latest hotfix: 0.9 (2025-10-31)

    Danke für die Tabelle und den Log Ludy :):thumbup: Ich muss sagen, dass ich mir das leider nicht erklären kann... beim Kleinhauen der Bäume spawnt das Spiel eine Setzlinganzahl zwischen saplingcountmin und saplingcountmax (wie es in der "plants" Tabelle der definitions.db) festgelegt ist :thinking: Ich kann leider auch nichts entdecken, was das verhindern sollte...

    Das einzige, was ich ändern könnte, ist im Grunde etwas mehr Variation beim Seed für den Zufallsgenerator (der die zufällige Zahl zwischen min und max ermittelt) - momentan wird dafür einfach nur die einmalige ID des Baumes verwendet. Bei zusammenhängenden Bäumen kann das zwar tendenziell öfter gleiche Werte ergeben, sollte aber eigentlich nicht so festgefahren auf einen Wert sein...


    Wir werden mit dem nächsten Update aber auch eine Ausgabe hinzufügen, die die tatsächliche Anzahl an gespawnten Setzlingen enthält. Falls das Problem also nach dem Update weiterhin bestehen sollte, melde dich bitte nochmal ;)

    Leider ist noch etwas unklar, ob die FPS bei dir dauerhaft niedrig bleiben (also auch, wenn du dich nicht bewegst), oder ob das nur beim Bewegen passiert? Laut den Logs werden bei dir Warnungen gespammt (die von der Engine kommen), weil scheinbar mehrere Schränke mit einer negativen Größe platziert sind (und die Physikengine damit nicht umgehen kann). Das kann grundsätzlich bereits die Ursache für die Frameeinbrüche sein (allerdings nur beim Laufen, nicht beim Stillstehen). Das werden wir mit dem nächsten Update dahingehend abändern, dass das keine Warnungen mehr verursacht.


    Terraforming geht irgendwann nicht mehr fließend, d. h. Glätten funzt nur durch Klick, klick anstatt wie vorhe

    Ich hatte dir das ja schonmal geschrieben, dass das dann der Fall ist, wenn das "Durchgehende Bearbeiten" mit STRG rechts ausgeschaltet wird. Dann wird nur noch 1 Befehl pro Klick ausgeführt.


    Ich komme mir vor wie in der Java-Version.

    (Alles soll heutzutage schneller, moderner und besser sein, aber vieles ist immer noch nicht ausreichend, da die nächste Neuerung die alten bzw. fast neuen Sachen wieder über den Haufen wirft).

    Uff... leider kann ein Update auch neue Probleme mit sich bringen, besonders wenn das Update umfangreiche Änderungen enthält. Wir testen jedes Update so gut es geht, aber es gibt soviele Fälle, die wir nunmal nicht alle durchtesten können. Und es wäre wohl im jetzigen Zustand nicht zu rechtfertigen, wenn Updates um weitere Monate verschoben werden, nur damit alle Spezialfälle durchgetestet werden. Wenn wir auf ein Problem aufmerksam werden, versuchen wir es so schnell wie möglich zu beheben. Gravierende Bugs gibt es meist eigentlich nur wenige (und wenn, dann werden die i.d.R. zeitnahe behoben).


    Ich hab das mal gescreenshottet. Lights habe ich anscheinend sehr viele, aber ohne Licht ist es an dieser Stelle stockdunkel, weil ich da noch keine gesetzt habe, der Boden besteht noch aus Erde.

    Die Anzeige der Constructions bezieht sich leider nur auf den aktuellen Chunk, in dem man sich gerade befindet, daher lässt das leider keine Rückschlüsse zu, wieviele Bauteile insgesamt verbaut sind. Die Anzahl der Lichtquellen ist mit 872 aber ziemlich hoch.


    Auffällig ist auch, dass relativ viele virtuelle Soundchannel in Verwendung sind und die CPU Last durch FMOD (die Audioengine) relativ hoch ausfällt (vorletzte Zeile). Das werden alles wahrscheinlich Loop-Sounds sein. Was hast du in der Gegend denn überwiegend an Lichtquellen platziert? Fackeln, Lagerfeuer, oder moderne Lampen etc?


    Das einziege was mir sonst noch aufgefallen ist, sind die (Pending)Ausstehenden Bytes, aber da weiß ich nicht wo her die kommen können
    Bei mir ist nicht ganz so viel gebaut, aber ich bekomme da nicht ein Byte zusammen
    Ich weiß das nicht zubeurteilen aber 81Mb in knapp 2,5min. an Ausstehenden Daten ist vieleicht der Ansatz wo Red was dazu sagen kann

    Das ist grundsätzlich harmlos: Die Zeile zeigt an, wieviele Pointer bzw. nativer Memory allocated wurde. Pending bezieht sich dabei auf die Pointer und Memory, die noch freigegeben werden müssen, "Total" ist die Gesamtanzahl an Bytes, die seit Spielstart schonmal allocated und wieder freigegeben wurden. Besonders bei hohen Sichtweiten oder bei vielen Bauwerken kommen da schnell jede Menge Daten zusammen (locker auch bis in den Gigabytebereich) - ist aber wie gesagt eigentlich unproblematisch ^^

    Eine Sprühpistole wie in Empyrion wäre auch nicht schlecht. Im Gegensatz dazu ist das Färben in Rising World leider mittelalterlich

    Empyrion spielt nunmal auch in einer deutlich moderneren Ära... es war naheliegend, in RW, welches nicht nur in der Modernen spielt, zunächst einen klassischen Pinsel bzw. Farbrolle zu haben. Natürlich kann man später auch eine Sprühpistole einbauen....


    Hier mal die "Farbkatastrophe" - verwendet wurden die Farben per Schnellauswahl ohne Anpassung - ganz links die Originalfarbe und was dabei herauskommt auf der Schattenseite und auf der Sonnenseite

    Danke für die Screenshots! Du hast recht, dass es derzeit eher eine Lasur als ein wirkliches Anmalen ist... nur wie gesagt, ein richtiges "Übermalen" (also als Deckfarbe) würde unterm Strich vmtl. eher dazu führen, dass alle Blöcke mehr oder weniger gleich aussehen werden... theoretisch könnte man in der aktuellen Situation als Workaround auch einen weißen Putzblock nehmen und anmalen - der dürfte eigentlich weitgehend der Originalfarbe entsprechen.


    Ich persönlich weiß zwar nicht, ob das Färben in seiner jetzigen Form wirklich komplett unbrauchbar ist... aber man könnte grundsätzlich noch einen weiteren Farbmodus einbauen, in dem die Farbe dann wie oben beschrieben als Deckfarbe fungieren würde. Ich bin mir nicht sicher, ob das als Standardmodus sinnvoll wäre.. einerseits ist es tatsächlich suboptimal, wenn der angemalte Block von der Originalfarbe abweicht, andererseits schränkt eine einfache Deckfarbe die Möglichkeiten aber auch etwas ein. Das Problem ist nur, dass wir das nicht einfach so ändern können (da dadurch ja dann bestehende angemalte Bauwerke ihr Aussehen ändern würden, was vll problematisch sein könnte). Es wäre also eine Weltkonvertierung erforderlich. Das ist mittelfristig aber eh geplant (damit wir das Feature einbauen können, dass jede Blockseite einzeln angemalt werden kann), wahrscheinlich würde man das dann in dem Zuge auch hinzufügen^^

    Hmm... is there a particular reason you want a version from 2016? ^^


    In Steam it's basically possible to download an old version of a game via console. You have to search for the manifest ID of the depot you want to download. The Java version of RW uses the "Game" depot (for the main game data) and separate depots for Windows, Linux and Mac (containing the executable, Java etc).


    There are some guides on the net which explain how to do that (e.g. this one) ;)

    Diese Events und Funktionen werden alle im ersten Release drin sein und müssten eigentlich auch funktionieren ^^

    Wir haben viele Events etc. aber noch nicht unter Realbedingungen testen können (und es ist nicht auszuschließen, dass im Laufe der Zeit auch wieder irgendwas kaputt gegangen ist), wenn also nach dem API Release irgendwas nicht funktioniert, sag einfach Bescheid :D

    Ich habe schon jede Menge technische Spielereien vor Augen, wenn ich an bewegliche Blöcke denke; angetrieben und selbsttreibend (Motor + Getriebe)? Von Spielern stoppbar (Blockieren / Fernbedienung)?

    Perfektion wird das natürlich erst später i.V.m. dem Stromsystem erlangen (in welchem man dann genau festlegen kann, wann sich welcher Block bzw. Motor wie weit bewegen soll) ^^ Mal sehen, inwieweit das anfangs schon ausgestaltet sein wird^^


    wenn man vielleicht auch mal über so etwas wie einen Storage Block nachdenken könnte, der einen unabhängig von den vorgegebenen Lagerungsmöglichkeiten wie Truhe und Fässern machen würde

    Das hört sich interessant an. Wie hast du dir den Storageblock ungefähr vorgestellt? Also wirklich eine Art quadratische Kiste, die ca. die Abmessungen eines Blockes hat?

    Aus 2023-03-30-23-46-45.log in Zeile 153: [ERROR] [00:37:21] UNABLE TO ACQUIRE LOCK ON CHUNK LIST (CP 233 48), LOCKED BY ServerChunkWorkerThread_0 [7]!

    Wenn dieser Fehler vereinzelt auftritt, ist das grundsätzlich nicht so schlimm. Das kann manchmal passieren, wenn zB ein neuer Spieler connected und viele Weltdaten auf einmal anfordert. Der Fehler wird dann manchmal mehrfach ausgegeben, aber das muss quasi als 1 Ausgabe betrachtet werden (also immer dann, wenn der Zeitstempel der gleiche ist).


    Der Fehler ist auch erstmal folgenlos - in dem Moment, wo er auftritt, kann es aber zu kleineren Verzögerungen kommen (Welt kann nicht abgebaut werden o.ä). Nicht schön, aber meistens auch keine Katastrophe.


    Erst wenn dieser Fehler regelmäßig auftritt, wäre das etwas besorgniserregender ;)


    Ja bei dem ersten Log wollte ich mit shutdown 60 (in der Game-Console) das Spiel Schlißen, weil unerwarteter Besuch auf dem Server gab, eigendlich dachte ich das es wie beim restart nn klappt mit einer Warnung (geht da noch ein Update ;) )

    Das wäre keine schlechte Idee, ich packe das mal auf die Liste ;)


    Mir kommt es so vor als ob das Beenden das Servers mit angemeldeten Spielern den Fehler verursacht, vieleicht in die Richtung mit dem belegten Prot, es wirkt für mich so als würde das Spieler abmelden und das Speichern sich harken

    Meinst du den obigen Chunk-Fehler? Das ist in dem Fall denkbar, aber das kann dann erst recht ignoriert werden - es führt nur dazu, dass der Spieler möglicherweise keine Chunkdaten mehr erhält (was er aber beim Herunterfahren des Servers eh nicht mehr täte) ^^

    Auf das Speichern o.ä. hat das keinen Einfluss.


    Was den belegten Port angeht, bislang ist das in den meisten Fällen nicht vom eigentlichen Spiel verursacht, sondern vom Webserver (der die Serverliste mit Daten füttert). Falls du das Problem mit dem belegten Port nach einem Restart noch hast, kannst du mir davon ggf. einen Log senden? ;)


    Die Pflanten sind doch soch angelegt das sie ein Zeitstempel bekommen wenn sie gesetzt werden und sie haben eine feste Wackstums Zeit, runtime wird dan die verbleibende Wackstums Zeit Berechnet?

    Nicht ganz, zwar haben Pflanzen in der Tat einen Zeitstempel, wann sie gesetzt wurden, das Wachstum wird allerdings als separate Variable (also die restliche Wachstumsdauer) heruntergezählt. Daher wird das auch nur weitergezählt, wenn das Spiel bzw. der Server läuft.


    Wir konnten noch feststellen das die Problematik mit den Setzlingen nur auf Servern auftritt, es kommt wohl auch auf die menge an.

    Für ca. 30 Bäume gab es jawails 2 Setzlinge, dann gab es 3 Setzlinge pro Baum, eine weiterer Random konnte nicht festgestellt werden, es waren ca. 100 Bäume +- Baumstammverhälnis der einzelnen Sorten (alzahl der Baumstämme wurden durch 6 geteilt)

    Um welche Bäume handelte es sich denn dabei? Die jeweiligen Bäume haben eine unterschiedliche Anzahl an max. Setzlingen, die sie von sich geben :thinking:


    Vielleicht kann es noch einen Hauch von Farbe bekommen. Es sind ja immer Mineralien drin. Der Hammer wäre Dreckbrühe beim Bergbau / zum Klärwerk.( .. da gibt 's nur Oberflächenspiegelungen)

    Mehrere Wassersorten sind auf jeden Fall noch geplant :) Dazu wird auch dreckiges Wasser gehören, langfristig aber auch Dinge wie Lava, ggf. Öl etc.


    Vielleicht sollte die Partikelgröße des H2O individuell (eigene Grafikkarte) eingestellt werden können.

    Leider ist das nicht möglich :/ Das Wasser muss bei uns persistent sein (also die Zustandsänderungen müssen in der Welt gespeichert werden, zB wenn das Wasser irgendwo hinfließt oder abfließt), daher muss das Wasser von der CPU berechnet werden statt von der GPU. Dabei ist das Wasser an die Auflösung des Terrains gebunden (d.h. eine Wasserzelle bzw. ein Wasser-Voxel ist so groß wie in Terrain-Voxel). Wenn wir eine feinere Abstufung wollen, müsste auch das Terrain eine feinere Abstufung bekommen - das würde aber zu viele Probleme mit sich bringen (2x so genaues Terrain [was für Wasser vmtl. immernoch nicht klein genug ist] bedeutet 8x mehr Daten, 8x mehr Polygone und 8x langsamere Weltgenerierung) :silenced:


    Die einzige Einstellung, die wir momentan anbieten können, ist daher die "Wasser Update-Intervall" Einstellung (unter Grafik). Das bestimmt, wie häufig das Wasser pro Sekunde neu berechnet werden soll...

    ich habe das geliche Problem. Spiele im Einzelspieler Modus "Survival". Bei mir wachsen die Setzlinge auch nicht (ist es normal das ich die auch wieder aufnehmen kann?)

    In der Zeit sind schon andere Bäume auf der Karte neu gewachsen. Sind auch schon vor vielen Stunden gepflanzt worden.

    Ja, es ist normal, dass man Setzlinge wieder aufheben kann (das ist dafür gedacht, dass wenn man sie versehentlich falsch platziert, man das korrigieren kann) ^^


    Was das Wachstum betrifft, wir haben tatsächlich noch einen Fehler finden können, der in manchen Fällen dafür sorgte, dass das Wachstum nach dem neuladen zurückgesetzt wird (teilweise führt das dazu, dass manche Pflanzen gar nicht mehr wachsen)... das werden wir so schnell wie möglich beheben :) Als Workaround könntest du lediglich in den Spieleinstellungen (unter "Verschiedenes") die Wachstumszeiten beschleunigen, dann kann das Problemumgangen werden.

    Das Spiel verwendet den HSV Farbraum statt RGB. Grundsätzlich kann damit auch jede Farbe ausgewählt werden, aber zugegebenermaßen ist das bei dem Farbwähler wie in Photoshop schon einfacher...


    Sobald wir etwas mehr Luft haben, werden wir das wahrscheinlich umschreiben (sodass das Spiel auch einen RGB Wähler verwendet) ;)


    was mich aber vollkommen nervt ist das ich eine dunkle Farbe auswähle die Farbe auftrage und mich dann die Farbe quietschend leuchtend ist und nichts im geringsten mit der ursprünglichen Farbauswahl hat. Derzeit kann man die Farbauswahl auch komplett weglassen denn es kommt NIE die gewünschte Farbe raus!

    Oha, das ist schon etwas heftig, wenn du das sogar als komplett unbrauchbar empfindest :wat: Wenn du eine dunkle Farbe auswählst und stattdessen eine leuchtende Farbe rauskommt, dann ist da irgendwas faul :thinking: Kannst du ggf. die BlockID und den Farbton posten? Bzw. Screenshots davon? Das wäre sehr hilfreich!


    Man muss allerdings bedenken, dass bei Bauelementen die Farbe nicht einfach nur aufgetragen wird (wie bei Möbeln), also quasi als Deckfarbe, sondern die Grundfarbe des Baumaterials miteinfließt. Das führt logischerweise dazu, dass ein bestimmter Farbton auf jedem Block etwas anders aussieht.

    Wenn Farben auf Blöcken wie Deckfarben wirken, würde letztenendes jeder angemalte Block gleich aussehen (egal, aus welchem Material er besteht). Effektiv schränkt das die Möglichkeiten in meinen Augen schon arg ein :hushed:

    Handelt es sich dabei um selbstplatziertes Wasser? Dort gleicht sich die Oberfläche leider nicht immer zu 100% aus, was zu kleinen Stufen in der Wasseroberfläche führen kann. Das liegt leider an der Mindestgröße einer Wasserzelle... ist also momentan leider noch eine technische Limitierung, das wollen wir in Zukunft aber ändern ;)


    Mit natürlichem Wasser sollte sowas aber eigentlich nicht auftreten.


    Was die fliegenden Pflanzen angeht: Auch das kann leider manchmal passieren, auch wenn es nicht schön ist... beim Generieren der Welt liegt dem Spiel nicht das exakte Terrain vor, sondern nur die darunterliegenden Voxeldaten (quasi so, als handele es sich um eine Blockwelt à la Minecraft). Anhand dessen sucht das Spiel dann die passende Höhe und Ausrichtung für Pflanzen.

    Erst nachdem die Weltdaten generiert sind, baut das Spiel das eigentliche Terrain zusammen (also die "smoothe" Repräsentation der Voxeldaten) - die können allerdings geringfügig abweichen. In seltenen Situationen ist es dann manchmal so, dass Pflanzen keinen Bodenkontakt mehr haben.


    Da gibt es leider keine Universallösung für, stattdessen müssten wir uns die Weltdaten an dieser Stelle genau anschauen und gucken, wie diese Konstellation verhindert werden kann. Falls du sowas nochmal entdeckst, könntest du uns ggf. einen Report senden? :)

    Ist die Framerate nur bei einer bestimmten Blickrichtung niedrig, oder unabhängig davon? Oder ist sie zB nur beim Laufen gering?


    Bleibt das nach dem Neustart weiterhin so, bzw. tritt das erst nach einiger Spielzeit auf?


    Wenn du in einer Situation bist, in der die Framerate gerade besonders gering ist, sende am besten in dem Moment (also in dem die FPS so gering sind) einen Report ;)


    Was den Vergleich mit anderen Spielen angeht, leider ist das nicht aussagekräftig, vor allem wenn es um Spiele mit fester Spielwelt geht... die Grafikqualität spielt dabei nur eine absolut untergeordnete Rolle. RW wird immer wesentlich mehr Overhead haben als andere Spiele mit fester Spielwelt. Ein Großteil der Optimierungen, die in einer festen Spielwelt vorgenommen werden, fallen in RW leider aufgrund des Genres komplett weg :silenced:

    Stimmt dies überhaupt noch ?

    Grundsätzlich ja ^^ In erster Linie sind diese Anforderungen auf die Java Version ausgelegt, gelten grundsätzlich aber auch für die neue Version. Was vll etwas knapp bemessen ist ist der minimale Arbeitsspeicher von 4 GB... sowas lässt nur minimale Sichtweiten zu. Außerdem ist die Mindestangabe von 2 GB VRAM zumindest unter Linux heikel: Seit der neuesten Unity Version ist der VRAM-Verbrauch unter Vulkan (Linux) drastisch nach oben geklettert, sodass auch hier 2 GB höchstens für minimale Grafikeinstellungen reicht.

    Unter Windows hingegen sollte das aber kein Problem sein (hier reicht teilweise sogar 1 GB bei Mindesteinstellungen aus) ;)


    Was man aber ändern könnte wäre die "Optimal" Sparte, denn eine GTX 1080 reicht zwar vollkommen für die neue Version aus, aber nicht unbedingt für maximale Einstellungen (vor allem wenn man zB 4K anstrebt). Das werden wir in Zukunft nochmal etwas anpassen (spätestens wenn die neue Version die Java Version ersetzt hat)^^

    Gilt das Tutorial auch für die neue Version?

    Wenn ich das richtig verstanden habe, ja. Oder?

    Leider gibt es für die neue Version noch keinen Support für TexturePacks :/ Das ist zwar geplant, leider ist aber noch nicht abzuschätzen, wann das kommen würde... es würde aber dann auch anders funktionieren als in der Java Version, denn einerseits sind die Ordner nun anders aufgebaut, andererseits arbeitet die neue Version mit deutlich höheren Auflösungen (bis zu 2048px, statt die maximal 512px in der Java Version).

    Auch bestehen Texturen jetzt nicht mehr aus nur einem einzigen Bild, sondern brauchen für eine korrekte Darstellung idealerweise noch weitere Texturen (mindestens eine Normal-Map [manchmal auch Bump-Map genannt])... da müssen wir uns mal Gedanken machen, wie wir das am besten integrieren ^^

    aber wegen den Gruppen spekuliere ich ja noch auf die Plugins mit Enter und Leave Events :D

    Meinst du Events beim Ändern der Gruppe? Oder Events fürs Betreten/Verlassen von Areas?


    Ansonsten wenn du noch konkrete API Wünsche hast, wäre jetzt noch der passende Zeitpunkt für Last-Minute-Änderungen :D


    Ja nur bei Verschachtelung [...]

    Danke für die gute Erläuterung! :thumbup: Ich sehe das Problem... leider etwas schwierig zu lösen (aufgrund der Art und Weise, wie das Betreten verhindert wird)... ich muss mal schauen, was sich da machen lässt. Irgendeine Lösung finden wir da bestimmt ;)


    In der gruppe (die ich nutze) habe ich den areablock eingefügt (alles auf True gesetzt) wird auch (canenter&canleave) nicht berücksichtig

    Leider funktionieren canenter und canleave nicht für Gruppen (da diese Permissions nur für Areas gelten) :|

    It is actually our intention to make each block side individually paintable ;) Unfortunately this requires a world conversion (because all existing construction elements in old worlds need to be updated for this), and the last two major updates already changed so many world-related things that we didn't want to risk breaking any worlds :saint: But it's still on our to-do list ^^

    red51 Warum muss eigentlich dieser Umweg über bewegliche Blöcke gemacht werden? Könnte man diesen Weg nicht überspringen und gleich Scharniere integrieren?

    Die beweglichen Blöcke werden das eigentliche Kernfeature sein, während Scharniere darauf basieren würden (also davon abgeleitet werden). Die Intention hinter beweglichen Blöcken ist eigentlich, dass man damit insgesamt mehr Freiheit hat (und nicht "nur" Scharniere, die ja in erster Linie für Türen gedacht wären).

    Mit den universellen beweglichen Blöcken könnte man allerlei beweglichen Strukturen bauen, zB Windmühlen, Wasserräder, Ventilatoren, aber auch Aufzüge oder bewegliche Platformen. Natürlich auch Türen (sowie Schiebetüren).


    Ich denke auf die Sound Geräusche können wir erst einmal verzichten.

    Damit sprichst du dich ja aber eher für die beweglichen Blöcke aus ^^ Ich hatte ja oben beschrieben, dass Scharniere *eigentlich* gar nicht unbedingt notwendig sind, wenn es bewegliche Blöcke gibt. Der einzige "Vorteil" von Scharnieren wäre, dass sie zB direkt einen Türsound hätten.


    Ansonsten sind die generischen beweglichen Blöcke aber eindeutig die flexiblere Lösung (da sie eben nicht nur auf Türen beschränkt sind). Daher wollen wir das auch unbedingt zuerst einbauen - und wenn es danach noch weiterhin Bedarf nach Scharnieren geben sollte, könnte man sie immernoch hinzufügen^^

    Oh, sorry da habe ich mich Falsch ausgedrückt :dizzy: es ging um das Fällen von "natürlich gewacksenen" Bäumen, egal mit welcher Axt, gibt es immer einen Festen Wert an Baumsetzlinge, bis zum Server neustart

    Achso :D Aber eigentlich sollte auch das weiterhin dynamisch vom Server entschieden werden... im Spiel ist ein Mindest- und ein Maximalwert für Setzlinge definiert (also wieviele Setzlinge spawnen sollen), und es wird jedes Mal beim Fällen des Baumes ein neuer Zufallswert zwischen diesen beiden Werten ermittelt (also immer pro Baum) :thinking:


    Vll ist der Zufallsgenerator etwas einseitig sodass er zu oft die gleichen Werte ausspuckt... das könnten wir ggf. noch etwas anpassen :monocle:


    Was allerdings nur beim Spiel- bzw. Serverstart festgelegt wird ist der Mindest- und Maximalwert in der Datenbank (das wird nur einmalig ausgelesen). Das wäre nur relevant, wenn du die definitions.db Datei zur Laufzeit modifizierst. Das meinst du vermutlich nicht, oder?


    red51 Gibt es noch mal ein Update vor dem nächsten größeren Update? Tiere kann man auf selbstgebaute Sachen nicht setzen, die verschwinden darunter, das heißt ein Dach wird nicht als Begrenzung gesehen.

    Ja, bald kommt das API Update (mit welchem auch einige Bugs behoben werden). Das Tier-Problem ist momentan leider noch nicht behoben, das wird sich aber höchstwahrscheinlich noch bis zum Update ändern ;)


    Ich habe mal beide mit gegeben, beim neustarten tauchen gelegendlich Crunch Fehler auf, Aber auch ohne die Fehler ist das mit dem Grow-Reset, diesmal hat aber das Offline weiterwacksen nicht geklappt, es waren 5 min. ruhe und es hätten mindesten zwei Bäume das nächste Level erreich sollen (sie wurden im 2 min. Tackt gepflanzt)

    Danke für die Logs! :thumbup: Auf Anhieb sieht erstmal alles i.O. aus soweit... wie genau beendest du den Server? Laut Log sieht das nach einem relativ abrupten Herunterfahren aus... eigentlich sollte das aber so oder so nicht zu einem Datenverlust führen :thinking:


    Ich muss mir das mal genauer ansehen... leider ist auf Anhieb nichts direkt ersichtlich, warum die Growthtime zurückgesetzt wurde :silenced:


    Was meinst du mit "Crunch-Fehlern"?


    Und was meinst du mit "Offline weiterwachsen"? Pflanzen wachsen generell nur während das Spiel bzw. der Server läuft. Oder meinst du was anderes?^^