Posts by red51

Danke für die Permissions! Sorry dass es etwas länger dauerte, aber ich kann bestätigen, dass hier etwas faul ist Es gibt manche Prüfungen, bei denen die Area-Permission tatsächlich auf die default.json zurückfällt. Das betrifft zwar nicht den Spieler direkt, d.h. beim direkten Setzen der Spielerpermission wird das korrekt übernommen, aber bei positionsbezogenen Prüfungen ist das problematisch (zumindest bei manchen Permissions).

Mir ist das vorher leider nicht aufgefallen, da Fliegen davon nicht betroffen ist, und bei den Vehicle-Permissions muss ich editownvehicles wohl doch übersehen haben (obwohl ich das ja extra erwähnte), sodass ich mein Fahrzeug trotzdem editieren konnte Clientseitig werden die Permissions übrigens korrekt gesetzt (deshalb tauchen sie in der Permission-Liste als positiv auf), aber die Entscheidungen werden in den meisten Fällen vom Server getroffen, wodurch der Bug verschleiert blieb.

Ich werde das mit dem nächsten Update beheben, danke nochmal fürs Nachhaken! Als schnelle Lösung könntest du entweder die gewünschten Werte direkt in der Area-Permission setzen (diese Problematik taucht nur bei den Permissions auf, die nicht von der Area-Permission überschrieben werden), oder alternativ (um zumindest die Fahrzeug-Problematik zu beheben) in der default.json editownvehicles löschen (der Standardwert dafür ist ohnehin true, d.h. der Spieler wird dann seine eigenen Vehicles weiterhin bearbeiten können).

Quote from SonoBionda

was ich grad nicht schnalle - bezieht sich das wirklich auf eine Gruppenberechtigung, oder ist das im Grunde nicht nur eine umbenannte Standardberechtigung die ebenfalls im Hauptordner liegt?

Ja, das ist eine Gruppenberechtigung, d.h. neue Spieler werden automatisch dieser Gruppe zugewiesen. Prinzipiell dasselbe als wäre der Admin immer da und würde den neuen Spieler manuell der Gruppe zuweisen

Die default.json bleibt davon unberührt.

Quote from Devidian

ok aber wenn ich dich richtig verstehe müsste dann doch wenn ich in default.json *vehicles: false habe in der gruppen.json *vehicles: true und in allen area.json diese werte NICHt gesetzt habe doch der wert true sein oder? das ist aber nicht der fall. Sobald ein spieler eine area betritt scheint nur noch default.json < area permission zu gelten, ohne gruppen permission zu beachten.

Ja, wenn in der Area-Permission dieser Wert nicht gesetzt ist, dann sollte der Wert der Gruppenpermission weiterhin gelten (sofern der Spieler in der Gruppe ist).

Ich habs bei mir auf einem lokalen Server einmal kurz probiert: In der default.json ist zB Fliegen nicht erlaubt. In der Gruppen-Permission ist es explizit erlaubt. In der Area-Permission ist es gar nicht definiert. Innerhalb der Area kann der Spieler weiterhin fliegen (die Area-Permission wird aber gesetzt und überschreibt alles, was darin definiert war, zB Chat)...

Habe testweise auch die editvehicles und editownvehicles Permissions getestet (d.h. in default.json false, in Gruppen-Permission true, in Area-Permission nicht definiert). Auch das funktionierte

Andererseits will ich meine Klappe auch nicht zu weit aufreißen, da du (und SonoBionda) ja schon einige Area-/Permission-bezogene Probleme gefunden habt, die ich auf Anhieb nicht reproduzieren konnte Daher sende mir vll am besten mal die Permissions zu, damit ich sie mir genau anschauen kann (oder nenne mir die genauen Permissions, die nicht funktionieren)

Leider stehen die Biome bzw. neue Regionen momentan noch etwas weiter hinten an Das Problem ist, dass dafür einiges an neuer Vegetation nötig ist (das aber leider auch recht zeitaufwändig ist)... das ist momentan der größte Blocker bei diesem Thema.

Momentan liegt der Fokus (hinsichtlich der "größeren Features") erstmal bei überarbeiteten Höhlen, Höhlen-POIs und auch Dungeons. Außerdem sind die NPCs noch ein wichtiges Thema (leider zu lange vernachlässigt), vor allem deren Pathfinding/Wegfindung. Die Überarbeitung der NPCs ist momentan im vollem Gange (ebenso wie Höhlen). Wenn das durch ist, können wir auch endlich Meeresbewohner reinbringen.

Danach würde ich eigentlich ganz gerne bewegliche Bauteile in Angriff nehmen. Und wir kommen an einen Punkt, ab welchem ich auch langsam gerne in die letzten großen "Klopperthemen" Züge und Elektrizität reinluschern würde (um wenigstens schonmal ein paar Grundlagen zu schaffen).

Einzelne "Spezial-Biome" (wahrscheinlich unter der Haube als POI umgesetzt) könnte ich mir aber durchaus schon früher vorstellen. Das wären zB Oasen in der Wüste, ggf. auch Vulkane (mit Tessellation verspüre ich einen Drang, Vulkangestein endlich natürlich spawnen zu lassen ). Aber ich finde auch den Vorschlag von Devidian zu Krater-Biomen bzw. Meteroiteneinschlägen sehr interessant! Ich müsste mir mal Gedanken machen, ob die bisherige POI-Logik für diese Spezial-Biome wirklich sinnvoll ist, oder ob das noch ein besonderer Untertyp wird

Ich würde aber auch weitere Biom-Vorschläge begrüßen, vor allem auch was solche Spezial-Biome angeht!

Quote from Ozorvals

Außerdem ist das gemäßigte Biom weniger komplex als die anderen beiden. Sind Änderungen geplant?

Wie genau meinst du das? Wünschst du dir mehr Wälder und Sub-Biome im gemäßigten Gebiet? Oder noch weitere Sub-Biome dafür? Wenn du Vorschläge hast bin ich offen dafür

Tatsächlich ist es so, dass Area-Permissions bzw. spielerbezogene Area-Permissions eigentlich nicht von der Standard-Area-Permission erbt. Area-Permissions sind etwas spezieller, sie sind quasi eher als "Patch" zu verstehen statt reine Vererbung. D.h. es werden nur die Werte überschrieben, die in der Area-Permission definiert sind. Prinzipiell ist es beim Betreten einer Area so, dass die aktuelle Permission des Spielers (default.json oder Gruppen-Permission) temporär die Area-Permission erbt (und nur die Werte überschrieben werden, die in der Area-Permission explizit gesetzt sind).

Als Area-Permission wird entweder eine spielerbezogene Area-Permission genommen (falls gesetzt), oder die Standard-Area-Permission. Beide haben nichts miteinander zutun, d.h. eine spielerbezogene Area-Permission ersetzt für diesen Spieler die Standard-Area-Permission, erbt aber nichts von ihr.

Wenn die default.json nicht existiert, dann werden dort einfach die Standardwerte, die vom Spiel aus definiert sind, genommen (im MP sind die Werte für Spieler so gewählt, dass ein Spieler fast nichts darf). Wenn der Spieler einer Gruppe zugewiesen wird spielt das aber keine Rolle (lediglich für die Keys, die nicht in der Gruppen-Permission gesetzt sind, denn die stammen dann weiterhin aus der default.json).

Die Prioritätskette ist also: default.json < Gruppen-Permission < server.properties-Overrides (optional) < Area-Permission (Default oder spielerspezifisch)

Zum Fliegen-Beispiel: Wenn in default.json Fliegen nicht erlaubt ist, in der Gruppen-Permission jedoch schon, dann sollte der Spieler eigentlich auch in der Area fliegen dürfen - außer die Area-Permission sagt explizit Nein zum Fliegen. Wenn du hingegen Fliegen nur in der Area erlauben willst, reicht es, in der Area-Permission Fliegen zu erlauben.

Sorry for the late response! If you don't get a reply within a few days or a week, it's totally fine to bump the topic. Unfortunately I also tend to lose track of the Java sections of the forum (this isn't your fault, it's my fault, restructuring the forum is still on my to-do list).

However, unfortunately the log files only cover the most recent and previous game session, so they are only helpful immediately after such a problem occurs. Ideally send a report from the game right when you notice that something is missing or weird, this will automatically attach the log files. It's basically the only way to find out what's really happening.

There is a bug that objects and plants sometimes don't get loaded properly on clientside, but this is typically fixed by reloading the chunk (either by moving away or by reloading the world). Losing objects permanently for no reason is that seems to happen extremely rarely... if someone ran into such an issue before, it was typically related to "Gravity", i.e the objects did break because they had no contact to the ground.

However, recently I found a bug that caused gravity to break objects in rare cases, even if they had contact to the ground or something solid (originally this issue was raised in connection with blueprints). This might be responsible for the objects to disappear in your case.

I've also expanded the logging to the "Events.db", so whenever an object is deleted, it will be tracked. When sending a report after the next update, a dump of this file will be attached automatically (this should make it easier to find out why a particular object disappeared).

But as a quick fix in the meantime, you can turn off Gravity for objects (and plants) in the game settings. That should prevent objects from breaking.

Quote from Petrel76

Can anyone launch fireworks after last update? I've just found that I can't. After I ignite a firework rocket, sparks keep bursting from it for seconds, minutes, tens of minutes... but the rocket doesn't go up. Maybe it's caused by the item placement, that it sticks too strong to the ground?

Unfortunately it's indeed a bug, as mentioned by LoneRanger It affects fireworks, but also dynamite and grenades... but it will be fixed with the next update

This is unfortunately a bug, caused by the gravity checks for objects (and plants) If gravity checks are enabled, the game checks if an object/plant has contact to the ground (or a wall), and if there is no contact, the object breaks (if it was just created a few moments ago, the game spawns the object as item instead of breaking it). When placing a blueprint, this check is sometimes executed too early (before the full collision is actually built), so the game thinks the object has no contact to the ground or walls.

I will try to get this fixed with the next update. But in the meantime you can also disable gravity checks in the game settings (turn off "Enable Gravity for Objects" in the Miscellaneous settings), that should prevent the objects from breaking

Wie SonoBionda schon sagt, das gibt an, ob jemand das Produkt besitzt bzw. in seiner Steam-Bibliothek hat. Früher hat Steam das mit einem kleinen Maus-Symbol angezeigt, das wurde aber nun durch die drei Striche (oder "Bücher") ersetzt

Quote from noci

Gibt es für undobp eigene Rechte Eintrag?

Nee, leider nein Das wird über den normalen undo abgedeckt. Wäre eine separate Permission für Blaupausen denn sinnvoll?

Ja, theoretisch können wir das via Permissions auch für den Survival ermöglichen

Du möchtest also in Areas das Teleportieren (überall hin) erlauben und außerhalb der Areas nicht, ist das richtig?

Quote from noci

In dem zusammenhang wehre es nicht Schlecht wenn mann auch nur in Areas hinein Teleportieren könnte. Also von Stadt zu Stadt.

Das ist wahrscheinlich etwas schwieriger umsetzbar, da Areas auf der Karte nicht angezeigt werden bzw. dort bisher noch nicht berücksichtigt werden... wäre aber trotzdem ein interessantes Feature! Ich packe es auf jeden Fall mal auf die Liste (wirds aber leider nicht mehr ins nächste Update schaffen)

Quote from noci

Aktuell ist es mit Plugins noch nicht möglich, Karten Interaktionen abzufangen.

Es wäre wahrscheinlich auch sinnvoll, das in dem Zuge direkt umzusetzen bzw. die nötigen Events (und Kartenzugriff) für die API bereitzustellen

Quote from noci

Aber bei beiden Varianten müsste mann noch überlegen, wie mann das auf der Karte Visualisieren kann, das in bestimmte bereiche hinein Teleportiert werden kann.

Es ist geplant, dass mehr auf der Karte visualisiert bzw. gezeichnet werden kann (Linien, Bereiche usw), damit könnte man dann auch grundsätzlich Areas darstellen

Quote from Deirdre

Generell sollte es eine Teleportmöglichkeit durch das Spiel geben.

Ein Teleport-System, mit welchem man mehrere Teleportpunkte (dauerhaft) festlegen und bei Bedarf immer wieder dorthin teleportieren kann wird es möglicherweise noch ins nächste Update reinschaffen (sonst spätestens ins Update danach)

Quote from SonoBionda

Ich hab das auch gelesen ... naja gut ... da steht ja auch ein "Probably"

https://steamcommunity.com/app…5816/#c565910803680706944

Stimmt Sorry, habe ich glatt vergessen Es sind zwischenzeitlich ein paar andere Themen dazugerutscht, die eigentlich etwas unerwartet waren... aber gut, vielleicht wird Juli noch was (wenn dann eher in den nächsten 1-2 Wochen), sonst August.

Quote from Kryssi_79

aso, ich meinte Unity Komponenten aufzulisten die schon auf GameObject oder prefab drauf sind. !
NICHT alle die Unity so hat ... uff
Unteranderem will ich wisse ob z.B.: addComponent erfolgreich war, oder welche Komponente kann ich mit setComponentProperty glücklich machen

Achso, das habe ich falsch verstanden So macht das auf jeden Fall mehr Sinn. D.h. du möchtest eine Liste aller Components, die auf dem geladenen Prefab vorhanden sind? Im Falle des Basis-GameObject hingegen wäre es dann meist wahrscheinlich Transform, MeshFilter und MeshRenderer, bei Prefab hingegen dann ggf. noch die vom User im Editor erstellten Components.

Ich muss nur mal schauen, wie wir das am besten umsetzen... der Server lädt normalerweise gar keine Assetbundles, sondern nur der Client. Es gibt bereits eine Ausnahme (getAllAssetNames()), aber für Components müssten die ganzen Prefabs geladen werden (samt Texturen usw). Vmtl. wäre hier ein Cachen zwingend erforderlich, damit Mehrfachaufrufe nicht den Server zuballern... ich schaue mir das auf jeden Fall mal genauer an

Quote from noci

Also ist meine Vermutung mit dem Winkel falsch?
Generell oder nur für das Abfallen der Objekte bei BP's?

Weder noch, der Winkel kann dabei durchaus eine Rolle spielen Ebenso die Skalierung. Es hängt tatsächlich von mehreren Faktoren ab, kann aber auch rein zufällig passieren. In Fällen, wo ohnehin keine Verbindung besteht, fallen Elemente aber natürlich ebenfalls ab.

Da du es in deinem Beitrag explizit erwähntest: Zusätzlich zu undo gibt es auch noch undobp, womit die letzte platzierte Blaupause zurückgesetzt wird (dann muss man sich nicht schrittweise durch die letzten Änderungen wühlen) Aber eine richtige Undo-Liste ist auch noch in Arbeit, vll schafft sie es ins nächste oder übernächste Update.

Quote from Kryssi_79

red51 kannst du bitte API Methoden einbauen die Unity Komponenten aufzulisten.

Jein... also grundsätzlich wäre das möglich, aber das Problem ist, dass es in Unity so unendlich viele Komponenten gibt, ein nicht unwesentlicher Teil davon aber entweder veraltet, inkompatibel oder nicht für die HDRP geeignet ist

Um wirklich alle kompatiblen bzw. sinnvoll einsetzbaren Komponenten zu erhalten müssten wir eigentlich von Hand eine Liste anlegen... wofür würdest du die Liste denn benötigen? Für ein konkretes Plugin, oder für eine allgemeine Übersicht (zB im Wiki)?

Quote from Kryssi_79

inklusive einer Klasse in der API die UnityComponent repräsentiert mit 3,4 Infos mehr und Methoden wie string getName()

List<UnityComponent> getAllUnityComponents()

Schön wäre es wahrscheinlich, aber so ein 1:1 Mapping ist auch manchmal unerwartet viel Arbeit (besonders wenn es von der allgemeinen Grundklasse "Component" ausgeht)... und würde wahrscheinlich ein umfangreiches und sauberes Planen erfordern (unzureichend durchdachte Design-Entscheidungen in der API sind immer doof, da wir das dann meist nicht mehr so einfach ändern können)

Sinnvoll wäre das aber wahrscheinlich auch erst dann, wenn es in der API auch wirklich entsprechende Repräsentationen jeweiliger Components geben würde (zB Rigidbody, VisualEffect usw). Andererseits gibts aber bereits zB "Collider" usw, d.h. hier müsste eigentlich alles zu diesem eher universelleren System zusammengeführt werden... unter der Haube wiederum ist es aber oft kein 1:1 Mapping, da auf dem Server ohnehin keine Unity-GameObjects o.ä vorliegen, sondern das ganze nur abstrakt repräsentiert ist... und manche Quirks der Unity HDRP von der API ohnehin ausgeblendet werden (zB dass eine Light-Component alleine nicht ausreicht, sondern ebenfalls eine HDAdditionalLightData-Component erforderlich ist, gleichzeitig aber nur die Hälfte der Light-Component-Properties funktionieren, während die andere Hälfte als gleichnamige Methode in HDAdditionalLightData zu finden ist usw).

Unterm Strich leider wahrscheinlich wirklich einiges an Aufwand

Quote from Kryssi_79

eine API Methode die Unity MonoBehaviour Methoden per Reflection aufrufen kann

z.B.: invokeMonoBehaviourMethod() oder so

Theoretisch müsste das eigentlich auch mit invokeComponentMethod() funktionieren (da MonoBehaviour von Behaviour abgeleitet ist, welches wiederum eine Component ist) Welche Methode von Behaviour/MonoBehaviour würdest du denn auf dem Wege aufrufen wollen?

Ich kann bestätigen, dass das leider ein Bug ist: Beim Platzieren von Blaupausen wird die Schwerkraft-Berechnung (effektiv ist die dafür da, alle Objekte und Pflanzen zu zerstören, die keinen Kontakt zum Boden oder einer Wand haben) manchmal zu früh durchgeführt, bevor also die restlichen Elemente platziert sind. Ich werde das mit dem nächsten Update korrigieren

Aber bis dahin sollte das Ausschalten der Optionen Abhilfe schaffen.

Das Spiel bzw. genau genommen die Plugin API bietet tatsächlich eigentlich schon alle notwendigen Werkzeuge für sowas Areas wären gut geeignet als Trigger Volume, es gibt OnEnter/OnLeave Events, und natürlich ebenfalls eine unendlich lange Liste an Dingen, die dann ausgelöst oder gemacht werden könnten.

Die wahre Kunst besteht nun darin, sowas im Spiel verfügbar zu machen (also damit man nicht gleich ein Plugin schreiben muss, was für die meisten User ohnehin keine Option ist). Effektiv sehe ich da zwei Möglichkeiten:

1. Entweder ein User hat Bock ein Plugin zu schreiben, was genau diese Events und Methoden ins Spiel trägt und dort bequem über eine UI o.ä. verfügbar macht (so wie noci auch schon andeutet)

2. Das Spiel macht alle Plugin Events und Methoden leichter zugänglich, d.h. ohne Notwendigkeit, ein Plugin zu schreiben (effektiv das, was 1 liefern würde, nur halt als Bestandteil des Vanilla-Spiels)

Auf 1 haben wir natürlich keinen direkten Einfluss. Aber zu 2 gab es damals schonmal Überlegungen, sowas teilweise über den Creative-Modus zugänglich zu machen. Ist natürlich nicht wenig Arbeit... aber wäre im Gegenzug auch ein extrem mächtiges Werkzeug und ich denke, dass so einige Spieler davon profitieren könnten. Es ist irgendwo (in Klammern geschrieben) auf der Todo-List, aber weniger als "das-wird-bald-kommen"-Feature, sondern eher als "really-nice-to-have-aber-kA-wann-es-wirklich-kommt"-Feature

Aber vll ist ein Plugin-Ersteller ja schneller

Der Flugmodus hat standardmäßig eine vereinfachte Steuerung, d.h. beim Drücken von Shift (Taste für Sprinten) fliegst du schneller, beim Drücken von Alt (Taste für langsames Gehen) fliegst du langsamer.

Wenn du die Fluggeschwindigkeit einstellbar haben möchtest (wie in der Java Version), d.h. mit Shift + Mausrad, dann musst du in den Einstellungen unter "Verschiedenes" die Einstellung Flugmodus Geschwindigkeit auf Fortgeschrittener Modus stellen

Quote from RoderickE

## Rising World - Dedicated Server Version 0.9.1 (15) Settings ##

If you're using SteamCMD, this topic contains more information about installing or updating the server Dedicated Server Setup [New Version]

In short, you need to execute app_update 339010 validate to update the server to the latest version.

Quote from RoderickE

So, what's new in 0.9.2?

You can find the changelog in the latest news post (just scroll a bit down to find the changelog): Update 0.9.2: Animal Breeding, Item Placement, better Controller Support [EN]

Quote from Devidian

Apropos, gibt es schon einen ungefähren ETA für das nächste Update?

Vermutlich diesen oder nächsten Monat

Quote from Devidian

Viel cooler wäre wenn man die Schiffe irgendwann selber bauen könnte

Der Wunsch wurde immer wieder mal geäußert (vor allem auch auf Fahrzeuge bezogen)... was zumindest geplant ist ist die Möglichkeit, größere Schiffe zu bebauen. Um vll den Spagat Richtung "selbstgebaute Schiffe" hinzubekommen wäre die sinnvollste Lösung wahrscheinlich ein Grundgerüst pro Fahrzeug-Typ zu haben, welches man dann bebauen könnte. Bei Booten/Schiffen wäre das vll ein Floß

Quote from FioO

Ich dachte jetzt ,man hätt die Sturm dynamik auf dem wasser noch mal erhöht.

Tatsächlich ist der Sturm selber gar nicht anders, neu sind bei dem Bild eigentlich nur die Wellen Derzeit gibt es keine richtigen Wellen auf dem Ozean, zwar stellt das Spiel das Wasser so dar, dass es eine gewisse Struktur hat, aber effektiv ist das Wasser immer platt bzw. flach. Mit dem Update würden richtige 3D Wellen dazukommen (und natürlich dabei auch das Bootsverhalten spürbar ändern), besonders bei Unwetter werden es auch entsprechend stärkere Wellen.

Quote from noci

Ich hätte gerne das ein Plugin-Ordner genauer Untersucht wird und hier auch weitere *.jar mit in die Ladeliste einbaut.

Grund: Durch meine Spielerein ist die ToolsAPI auf ca. 20Mb gewachsen. Ich habe da einige Libs und möchte die in einer Separaten Datei/Plugin auslagern. Es würde Sinn mache die beiden in einem Plugin-Ordner abzulegen.
Aber dann gewinnt das Alphabetische Plugin im Ordner, aus dem dann die plugin.yml herangezogen wird für die Prio und so. Ich glaube die weiteren werden dann nicht mehr geladen.
Können hier im Ordner alle Plugins gefunden werden?

Theoretisch müsste das bereits möglich sein Standardmäßig prüft das Spiel, ob es einen "lib" Ordner gibt (innerhalb eines Plugins) und lädt die .jars darin dann als Abhängigkeit. Wenn hingegen ein Plugin als Lib für andere Plugins dienen soll, musst du die loadorder in der plugin.yml anpassen, wie Devidian schon sagt. Das Spiel lädt Plugins in der Reihenfolge abhängig ihrer loadorder (bei gleicher loadorder dann hingegen alphabetisch). Für ein Plugin, was als Dependency eines anderen Plugins dient, müsstest du entsprechend eine niedrige loadorder wählen (zB die vorgeschlagenen -999)

Quote from noci

Algemein, wenn der WorkShop kommt, hat der auch eine Größenbeschränkung? Müsste ich mir dann noch gedanke über die Plugin Größe machen?

Bei Steam gab es damals mal eine Größenbeschränkung, aber meines Wissens nach gibt es die nicht mehr (d.h. kein Limit mehr). Ich würde dennoch versuchen, Plugins und Mods so klein wie möglich zu halten, da die Downloadgeschwindigkeiten in Steam manchmal deutlich schwanken können...

Ansonsten scheint es aber bei mod.io ein Limit zu geben. Online finde ich 8 GB, weiß aber nicht, ob das wirklich noch aktuell ist (ist schon ein paar Jährchen alt). So 100% steht noch nicht fest, ob wir lieber zu Workshop oder mod.io gehen (Steam würde die breitere Masse erreichen, mod.io hingegen plattformunabhängig sein und auch für nicht-Steam Versionen funktionieren)

Quote from Nomja

Ich wollte mal einfach fragen, wann ein neues Update in Planung ist und evtl was drin ist?

Voraussichtlich diesen oder nächsten Monat, aber leider kann ich noch nicht 100% sagen, was alles seinen Weg ins Update finden wird Kommt ein wenig darauf an, ob das Update noch im Juli oder eher im August erscheint.

Die gute Nachricht: Wir haben mit der Arbeit an einigen großen, wichtigen Features begonnen (bewegliche Teile, bessere Höhlen, besseres NPC Pathfinding usw), die werden aber nicht im kommenden Update reinkommen.

Ausnahme könnten die Höhlen sein: Aber hier würde ich das vll erstmal als "experimentelles Feature" reinbringen, d.h. man kann sie für neue Welten testweise aktivieren. Würde da gerne etwas Feedback sammeln und wenn alles passt, würde ich sie für alte Welten rückportieren.

(das Problem ist nämlich, dass die Integration in Bestandswelten immer etwas heikel ist, vor allem aber wenn die Höhlengenerierung Probleme macht oder wir doch nochmal ändern wollen, das wirklich unheimlich viel Aufwand ist... daher lieber erst etwas Feedback sammeln)

Das nächste Update wird in erster Linie die oben gezeigten Ozeanwellen reinbringen (mit neuer Bootsphysik etc) und das Wasser wurde generell angepasst (Fließverhalten usw). Außerdem sind viele Altlasten behoben, die schon ewig Probleme machten (zB "Geisterblöcke" die bei Terrainbearbeitung übrig blieben und im LOD zu Spitzen führten, Harke kann Terrain nun weicher gestalten usw), und generell eine Reihe Bugs behoben. Die Änderungen in der Plugin API sind auch umfangreich (auch wenn das für viele Spieler natürlich auf Anhieb erstmal nicht so relevant ist).

Alles andere, woran wir momentan noch arbeiten (zB Items beim Reiten benutzen) ist noch unfertig, da kommts ein wenig darauf an, ob es in den nächsten 1-2 Wochen fertig wird oder nicht

Quote from FioO

Auf Steam wurde geschrieben, dass du Ende diesen Monats, damit rechnen kannst.

Die Info ist zwar nicht komplett falsch, aber wo genau hast du die her? Oder wer hat das gesagt? Ich kann mich eigentlich nicht erinnern, mich verplappert zu haben (zumal ich wirklich nicht 100% sicher bin, ob es wirklich diesen Monat kommt)  

Danke für die Info! Dass Umbruch manchmal fehlerhaft durchgeführt wird ist mir auch schon aufgefallen, doch dass Rich Tags auch zerstört werden können wusste ich noch nicht Jedenfalls sollten beide Probleme mit dem nächsten Update endlich behoben sein