Posts by red51

A small new update is available now!

    Wird es den Lua-Wrapper noch geben?

    Das kann ich nicht sagen, theoretisch möglich wäre das schon, kommt ein wenig auf die Nachfrage drauf an. Eigentlich wollen wir Lua aber nicht unbedingt als Skript-Sprache für RW pushen, da hier viel Performance verschenkt wird (Hauptproblem ist die fehlende Multi-Threading-Funktionalität, die für RW extrem wichtig ist). Aber auch wenn wir den Lua Wrapper anbieten, müssten bestehende Lua Skripte voraussichtlich trotzdem etwas angepasst werden, damit sie mit der neuen Version kompatibel sind :nerd:

    Mich würde Mal die WASSER Frage interessieren. Wird es da auch gleich Wasser geben ? Wie sieht es mit dem Fließverhalten aus ? Mir würde das Fließverhalten so wie bei mc komplett reichen. Würde heißen das es dann so 6-7 Blöcke weit fließen kann, aber auch das wenn man am Ufer gräbt, sich der Wasserspiegel automatisch angleicht was ich am wichtigsten dabei finde.

    Wasser wird es in der Demo leider noch nicht geben, bisher haben wir noch nicht viel am Wasser gearbeitet :silenced: Der erste Release mit Wasser wird aber dafür dann direkt dynamisches Wasser beinhalten. Unser bisheriger Zeitplan (kann sich natürlich noch ändern) sieht so aus, dass wir jetzt zunächst die erste spielbare Version auf Vordermann bringen (hier und da noch Feinschliff am Terrain und Vegetation, und noch viele Kleinigkeiten [zB zumindest ein einfaches Settings-Menü usw]), danach steht das Bausystem im Vordergrund (also es in eine Release-fähige Form bringen), und dann möchten wir uns um die Spielerfiguren und Item-Animationen kümmern (in dem Bereich gibts noch einige ungeklärte Fragen). Danach kommt der Multiplayer zum Abschluss (prinzipiell ist der schon drin, aber es fehlt noch richtige Player-Sync und ein dedicated Server), und vmtl. wird es dann in Richtung Wasser und sowas wie NPCs gehen.


    Rising World sieht so realistisch aus, warum denn dann beim Wasser zurückstecken? Hat dieses Spiel doch gar nicht nötig, auch wenns länger dauert.

    Ich würde mir auch realistisches Wasser wünschen, aber wie Avanar und lenko schon sagen, das ist in dem Umfang leider (noch) nicht möglich. Dazu müssten einzelne Wasserpartikel (oder Tröpfchen, wie Avanar beschreibt) simuliert werden. Es wären zwar vmtl. auch hinreichend gute Ergebnisse möglich, wenn diese "Tröpfchen" etwas größer ausfallen (sagen wir mal 5x5cm), aber sowas ist im großen Stil leider nicht umsetzbar. Es gibt zwar viele nette Wasserdemos auf YT, aber hier gehts immer nur um sehr kleine Bereiche. Es wäre also mit heutiger Hardware auf jeden Fall umsetzbar, dass man eine Wanne voller "realistischem" Wasser hat, oder vielleicht ein ganzer Teich. Alles darüber hinaus stößt aber an die Grenzen. Ein ganzer See mit "realistischem" Wasser, der leerläuft und eine Höhle flutet, wäre schlicht unmöglich (zumindest in dieser Form).


    Bei RW kommt hier sogar noch ein anderes Problem hinzu: Die Änderungen müssen irgendwie gespeichert werden. Wenn die Auflösung des Wassers also so genau ist, dass jeder einzelne (große) Tropfen gespeichert wird, würde das enorm viel Speicherplatz benötigen. Wenn ein "Wassertropfen" 0.05 Blöcke groß wäre (würde gehen, wäre aber schon ein sehr großer Tropfen), wären das pro Block 20x20x20, also 8000 "Tropfen". Wasser würde fürs Speichern also bis zu 8000x mehr Speicherplatz benötigen. Im Multiplayer kommt hier die Synchro hinzu, die Tropfen müssten also auch synchronisiert werden (und verursachen entsprechend bis zu 8000x mehr Traffic).


    Sowas ist wie gesagt mit heutiger Hardware im kleinen Maßstab möglich, aber nicht für ganze Spielwelten. Und wenn eine persistente Welt oder Multiplayer hinzu kommt, sieht es erst recht düster aus :dizzy:


    How to place different water in Unity

    Unfortunately this has nothing in common with actual water ;) This is basically just a static surface that looks like water, but it has no behaviour like water. In fact this video just shows how to drop a ready-to-use asset (which wouldn't be compatible with RW anyway) into the scene editor :D


    Rising World has a randomly generated world, which means the world is generated at runtime. It's not available in the editor (because the world always looks different, depending on the selected seed). The scene in our editor is basically completely empty :D


    So in RW, water has to be generated programmatically. And it has to be actual "3D" water (if this makes any sense). While most games with a static, pre-designed world can simply declare the whole area below a certain elevation (e.g. sea level) or below a surface as "water", this wouldn't work in RW (since there could be always a cave under a pond, for example).


    Biggest issue is to implement flowing water though. RW has a modifiable environment, so water has to react to a changing environment. Flowing water is computationally very expensive, especially in a multiplayer world (where everything has to be synced with other players). There aren't many games out there that have to deal with this issue, so of course there is no solution for this available somewhere "out-of-the-box" ^^


    Ich würde auch gern einen oder mehrere Wasserfälle in Rising World sehen, vieleicht gibt es da ja mal die Möglichkeit das man Wasserfälle in verschiedenen Größen als Objekt setzen kann, somit wäre der Wasserfall zwar statisch aus einer Textur, für mich aber eine klare Alternative

    Das wäre definitiv umsetzbar ;) Natürlich bis zu einem gewisssen Grad eingeschränkt, aber in vielen Situationen dennoch geeignet. Wir könnten darüberhinaus auch ein "Wasser-Objekt" anbieten, also quasi nur eine einfache, skalierbare Wasseroberfläche. Die würde sich zwar nicht wie Wasser verhalten, aber wie Wasser aussehen. Damit könnte man zumindest auf kleineren Flächen Wasser "faken" (zB Wasser in einer Badewanne, oder in einem Eimer, oder einer Tränke etc).

    i can say that some models do crash it. i have been using this plugin to test .obj and .dds textures for the customitemloader before i worry about the itemdef and icon files. ive had some .obj files not allow the server to boot as well it will load it then crash the server and not allow it to restart. i could try to find the error logs if it would help in any way

    Can you maybe send me one of the models in question (+ the according texture) via PM? If there is an issue with the model, maybe it's something the game can catch (so at least it doesn't crash anymore) :) If you have an additional error log, that would also be helpful

    Heißt es dann, dass ich mit einem Plugin ein Auto programmiere und das Plugin auf einem Server installieren kann wenn die API die Funktion dafür hat?

    Wenn die API das unterstützt, dann ja ^^ Wobei es natürlich auch immer einen gewissen Spielraum gibt, den man dabei hat. Denn auch wenn es in der API keine direkte "FügeAutoHinzu()" Funktion gibt, so kann man versuchen, das anderweitig umzusetzen: In dem Fall könnte man zB das Modell eines Autos laden (das kann die API bereits) und darauf warten, dass ein Spieler damit interagiert. Das Plugin könnte sich nun für diesen Spieler merken, dass dieser in einem Auto sitzt, und die Spielerposition entsprechend regelmäßig updaten (an die Position des Fahrersitzes setzen). Wenn der Spieler nun zB die Vorwärtstaste betätigt, dann könnte man das Auto-Modell (mitsamt) Spieler nach vorne bewegen, beim Lenken entsprechend drehen usw. Bis hierhin ist alles auch mit der jetzigen API bereits möglich. Schwieriger wird es, das Auto an das Terrain anzupassen und Kollisionen richtig zu behandeln (wenn der Spieler zB gegen eine Wand fährt). Hier sind zwar einzelne Funktionen für sowas bereits in der API (zB raycast()), aber das wird trotzdem kompliziert - und stößt teilweise an die Grenzen. Neue Funktionen, die im Laufe der Zeit zur API hinzukommen, werden das sicherlich einfacher machen, aber es würde sich bei so einem Unterfangen trotzdem um ein sehr umfangreicheres Plugin handeln.


    Anders sieht es aus, wenn es bereits Fahrzeuge im Spiel gibt: Dann kann die API eher die Funktionen dazu bereitstellen (womit die Umsetzung eines solchen Plugins 100x einfacher wird). Dann könnte ein Plugin zB sein eigenes Modell einfügen, das Verhalten an das eines im Spiel bestehenden Autos anpassen, und das wars dann auch schon ;) So funktioniert das derzeit zB mit den Custom Items: Man kann recht einfach eine neue Spitzhacke oder ein neues Schwert einbauen (weil es sowas bereits im Spiel gibt), aber wenn man einen Flammenwerfer einbauen möchte, wird es kompliziert (weil es keine noch Mechanik für sowas im Spiel gibt).


    Du musst dir das immer so vorstellen, dass die API quasi nur bestehende Funktionen bereitstellen kann. Wenn du eine Funktion in der API aufrufst, kümmert sich das Spiel im Hintergrund um den Rest. Daher kann die API prinzipiell nur das bereitstellen, was das Spiel auch bereits kann.

    ZB über ein Plugin eigene Sounds abspielen ist möglich (weil das Spiel weiß, wie man Sounds abspielt), aber bspw. Gamepad-Support über ein Plugin einbinden ist nahezu unmöglich.


    Von den Dingen, die das Spiel kann und weiß, versuchen wir, so viel wie möglich über die API zugänglich zu machen, aber fehlende Funktionen fallen meist erst dann auf, wenn man selber ein Plugin schreibt (was wir aus Zeitgründen ja nicht so häufig machen). Dafür haben wir entsprechend die API-Wünsche Sektion^^

    Die Grenzen zwischen Mods und Plugins sind manchmal fließend, und auch der "Mod" Begriff wird häufig weit gefasst. Auf RW bezogen kann man es sich aber so vorstellen:

    • Eine Mod wäre eine Modifikation der Spieldateien. D.h. irgendjemand würde zB das Spiel dekompilieren, irgendwas am Code ändern, und die geänderten Dateien dann quasi als "Mod" zur Verfügung stellen. Hier sind generell keine Grenzen gesetzt. Nachteil ist, dass mit nahezu jedem Update des Spiels die Mod inkompatibel wird (sofern die modifizierten Spieldateien vom Update betroffen sind). Außerdem muss für den Multiplayer jeder Spieler (sowie der Server) die gleiche Mod installiert haben. Mehrere Mods parallel zu benutzen ist auch immer etwas schwierig, vor allem, wenn die Mods die gleichen Spieldateien oder Stellen im Code verändern. Zudem ist das Erstellen einer Mod auch ziemlich kompliziert, da der dekompilierte Code schwer leserlich ist und über keinerlei Dokumentation verfügt
    • Plugins hingegen verwenden die vom Spiel bereitgestellte API. Die API ist quasi eine Schnittstelle, die bestimmte Spielfunktionen nach außen trägt (und Plugins auch über versch. Ereignisse informiert, zB wenn ein Spieler Schaden bekommt usw) und über die die Plugins dann mit dem Spiel kommunizieren können. Vorteil ist, dass Plugins nach Spiel-Updates in den allermeisten Fällen kompatibel bleiben (es sei denn die API verändert sich). Auch reicht es im Multiplayer aus, wenn das Plugin auf dem Server installiert ist, da es ohnehin nur dort ausgeführt wird (und der Server sich um die Synchronisierung mit den Clients kümmert). Mehrere Plugins zu verwenden ist auch weit weniger problematisch als bei Mods, und Plugins zu erstellen ist - im Vergleich um Erstellen einer Mod - tausendmal einfacher, da die API einfach aufgebaut, öffentlich einsehbar und gut dokumentiert ist. Nachteil von Plugins ist, dass nur Dinge gemacht werden können, die die API auch bereitstellt. Derzeit erlaubt die API zB Custom Items einzubinden, aber zB noch keine Custom NPCs. Die API wird aber mit jedem Update umfangreicher und bietet mehr Freiheiten. Auch haben wir dafür die Sektion im Forum "API Wünsche" eingerichtet, in welcher Plugin-Entwickler auf fehlende API-Funktionen aufmerksam machen können


    Modding (also klassisches Modding) war in RW schon immer möglich und wird auch immer möglich bleiben, aber hierfür sind fundierte Programmierkenntnisse, viel Zeit und Geduld sowie Nerven aus Stahl nötig. Daher ist unsere Priorität, die Plugin-API voranzutreiben.


    Die neue Version ist zwar in C# und C++ geschrieben, aber für die Plugin-API werden wir weiterhin auf Java setzen. Wir haben uns zwar lange Gedanken dazu gemacht, aber Java bietet in diesem konkreten Fall mit Abstand die meisten Vorteile:

    • Java ist schnell, also spürbar schneller als Skriptsprachen wie zB Lua. Zwar nicht ganz so schnell wie C++, aber mit einer C++-API hätten wir wohl die Büchse der Pandora geöffnet (einerseits ist der Umgang mit C++ schwieriger als mit Java, das würde vmtl. viele Leute abschrecken, andererseits können schon minimale Fehler in Plugins das Spiel zum crashen bringen - ohne, dass man herausfinden könnte, dass der Fehler von einem Plugin verursacht wurde)
    • Java läuft quasi in einer eigenen Umgebung, d.h. wenn ein Plugin Amok läuft, wird nicht sofort das Spiel in Mitleidenschaft gezogen (*natürlich kann ein Plugin das Spiel trotzdem durcheinander bringen, aber zwischen Spiel und Plugins ist quasi ein sehr großer "Sicherheitspuffer")
    • Die alte API kann weitestgehend übernommen werden und auch bestehende Plugins müssen nur minimal angepasst werden, damit sie mit der neuen Version kompatibel wird. Das gilt auch für die Dokumentation, die haben wir im Laufe der Zeit mit vielen Beispielen gefüllt, und es wäre doof, wenn man wieder bei 0 anfangen müsste
    • Java ist als vollwertige Programmiersprache deutlich mächtiger als die meisten Skriptsprachen. Es gibt richtiges Multi-Threading (was allein für das Spiel enorm wichtig ist), richtiges I/O Handling, Netzwerkfunktionalitäten, und wenn man es wirklich Ernst meint auch die Möglichkeit, Java mit C++ bzw. nativen Libraries zu koppeln und mit ihnen zu kommunizieren


    Über Java ist es grundsätzlich aber auch möglich, Skriptsprachen einzubinden. Wir haben damals begonnen, einen Lua-Wrapper als Plugin zu schreiben (damit wir Lua endlich hätten rauswerfen können, durch den Wrapper hätten Leute aber weiterhin Lua Skripte laden und benutzen können). Wenn man das benutzt fallen die Geschwindigkeitsvorteile natürlich wieder weg (denn die Skriptsprache wäre dann wieder der Flaschenhals), aber der Vorteil von Skriptsprachen ist natürlich, dass diese einfach zu bedienen sind

    Thanks Celtic Hummingbird :)


    On the water textures. Can you use the ones in the java version?

    Well, basically water in RW isn't just a texture, instead it's a result of multiple render passes (to achieve the final look, including depth-based transparency, refractions, reflections etc) ^^ We'll probably take a similar approach for the Unity version, but rendering works totally different there. In addition to that, shaders use a different language in Unity (HLSL [the DirectX shader language] instead of GLSL [the OpenGL shader language]), so we have to rewrite them from scratch anyway^^

    Objekte werden fast ausnahmslos tatsächlich durch ein einzelnes Item repräsentiert (das "objectkit") und haben daher immer dieselbe TypID. Die eigentliche Objekt-ID ist hingegen im "ItemAttribute" hinterlegt. Das "Item.Attribute" ist abstrakt, davon gibt es aber die Ableitungen "Item.ObjectAttribute" (für Objekte), "Item.ClothingAttribute" (für Kleidungsstücke) und "Item.CustomItemAttribute" (für CustomItems).


    In deinem Fall suchst du das "Item.ObjectAttribute", worüber dann die Methode getObjectID() zugänglich ist (die die Objekt-ID zurückgibt). Also:

    Java
    Item.Attribute attr = item.getAttribute();
    if(attr instanceof Item.ObjectAttribute){
    Item.ObjectAttribute obj = (Item.ObjectAttribute) attribute;
    //Dies ist deine gesuchte Objekt-ID
    short objectTypeID = obj.getObjectID();
    //Die Objekt-Variation ist in der Item-Textur gespeichert (standardmäßig 0)
    int objectVariation = item.getVariation();
    }


    Die Objekt-ID könntest du nun zB mit der ID aus einer ObjectDefinition vergleichen um herauszufinden, um welches Objekt es sich genau handelt ;)

    I'm not really used in model using, but is there a way to pretent i. E. To show false models at start up?"otherwise the game could fail

    This wouldn't necessarily help regarding the issue raised by the OP (depending on what's considered a "false model"), but irrespective of that, I agree that it would be helpful if the game could at least detect "broken" models. However, this is only possible to a certain degree - the game (or more specifically the server, where the plugin is actually executed) could only check a few basic things. Not sure what's happening right now if a broken model is loaded, does the game actually crash? :huh: IIRC there should be just an error message in the console :thinking:

    J3o is a file format used by the JMonkeyEngine (to store scene information, but in case of RW it only contains models). Converting it to other formats (like .obj) is technically possible (you have to open the model in JMonkey and write your own converter), but AFAIK there are no tools for that available out of the box...

    red51 Heißt das, dass das Raster nicht mehr senkrecht zu nutzen ist, oder mehr variabel ist?

    Öhm... nicht unbedingt. Es stellt nur sicher, dass Objekte trotzdem den Boden berühren, wenn der Boden angeschaut wird (statt wie vorher dann entweder über den Boden zu schweben oder im Boden zu stecken). Beim Anschauen einer Wand trifft das dann nicht mehr zu - wobei wenn es um Objekte geht, also Möbel, dann ist das Platzieren an Wänden (je nach Objekt) ja ohnehin (wie auch in der alten Version) eingeschränkt.


    Apropos Raster. Wenn ich eine Tür im Raster setzen will, ist das Raster immer auf Maximum gestellt, egal was ich eingestellt hatte. Das ist nicht sehr praktisch.

    Die neue Version wird zumindest die zuvor eingestellte Rastergröße beibehalten ;)


    Wenn Mithril keine Verwendung hat (bisher), könnte es auf Multiplayer-Servern mit reinem Survival und Handel eventuell als Währung genutzt werden?

    Das wäre an sich keine schlechte Idee ^^ Aber das Problem würde natürlich bestehen, dass ein Erz existiert, was zumindest im Singleplayer keine Verwendung hätte (und das Vorhandensein von Erzen ohne Verwendungszweck wurde tatsächlich schon das eine oder andere Mal als Kritikpunkt in Reviews angeführt) :saint:


    Vielleicht wäre es aber generell gut, wenn es grundsätzlich eine Währung gäbe, die im MP von Admins kontrolliert wird (bzw. auch im SP entsprechend durch Handel mit Tradern) :monocle:

    Was soll das jetzt genau heißen?

    Also in der alten Version war es so, dass das Raster (also das Grid) ja eine "feste" Position hatte. Wenn nun bspw. der Boden aus halben Blöcken bestand, und man darauf zB eine Tür oder ein anderes Objekt platzieren wollte (mit aktivem Raster), dann steckte das Objekt entweder ein Stückchen im Boden oder schwebte in der Luft. Dasselbe passierte auch, wenn ein Objekt mit aktivem Raster auf Terrain platziert wurde (da die Oberfläche des Terrains nicht genau auf der gleichen Höhe wie von Blöcken ist). Das wird sich in der neuen Version anders verhalten.

    dachte ich könntet ihr doch gleich auch bestimmte Sachen mit programmieren . wie zbs. Skalierung von Blöcken

    Ja, das ist auf jeden Fall unsere Intention :) Generell nutzen wir die Gelegenheit, uns um viele "Altlasten" zu kümmern, d.h. alle Dinge, die bisher aufgeschoben wurden. Dinge wie das Bausystem oder die Weltgenerierung implementieren wir direkt von Grund auf neu. Skalierbare Blöcke werden auf jeden Fall umgesetzt.


    und das ihr die slaps vielleicht so programmiert, das sie wie bei den Holzteilen ,auch wenn sie in der Auswahl mittig oder darunter sind Objekte wie Stuhl, usw. auch platziert bar sind ohne das sie dann schweben , oder bei Decken die optisch höher gesetzt wurden dadurch nicht ,die Lampen usw , in der Luft hängen.

    Ich weiß nicht ganz, wie du das meinst? :thinking: Beziehst du dich dabei auf das Platzieren von Objekten mit aktivem Raster/Grid? In dem Fall habe ich gute Nachrichten, denn in der neuen Version wird das Raster nicht mehr ganz so statisch sein, stattdessen orientieren sich Objekte (also Möbel, Türen, Lampen etc) immer am Boden.


    Und jetzt meine Frage1 : werdet ihr wieder das imaginäre Metall , Mithril,( wofür es keine Verwendung bis her gab ) wieder in die Welt mit generieren lassen?

    Nach derzeitigem Stand wohl erstmal nicht, da das Erz (aufgrund des fehlenden Verwendungszwecks) in der Vergangenheit teilweise durchaus für Verwirrung gesorgt hat... Sobald wir aber ein Item haben, wofür sich Mithril (oder auch ein anderes fiktives Erz) anbieten würde, würden wir das wieder einbauen ;)


    und Frage 2 : wird es ohne Konsolenbefehl es möglich sein Texturen von anderen Blöcken .usw. zu benutzen? Würde zu mindestens den Texturencheat unterbinden.

    Ja, auf jeden Fall. Ich würde das zwar wie Deirdre auch nicht als "Cheat" bezeichnen, aber generell wollen wir versuchen, weitestgehend von Konsolenbefehlen wegzukommen und alles über eine GUI zugänglich machen (auch Befehle wie das bisherige "setp", "setr" usw) ^^

    Currently the only solution for this would be to load multiple models (1 model per texture). Basically this could be incorporated into the plugin to handle this automatically, but it's a bit tricky. Under the hood the game still requires a separate model per texture (unless a TextureArray is used, but that requires a special setup and introduces a few limitations).


    We're thinking about adding a better way to handle this in the new version, maybe it will use submeshes.


    The only thing you could do now as a workaround would be to merge all textures into a single atlas. For 3ds max, there is a plugin out there which bakes all used materials into a single texture automatically, but I'm not sure if there is also a similar thing for Blender :thinking: If there is no such tool available for Blender, you have to do that manually :silenced:

    The "editnpc" command currently uses the spawnnpc permission :thinking: It definitely makes sense to move that to a separate permission, we'll change that with the next update, but unfortuantely we have no ETA for that yet :|

    Thanks a lot for your feedback Groovaholic and zfoxfire:)


    also will you be adding water/pounds (static or animated) in the first tech demo or is that a way off yet? any screen shots would be nice if you have any

    Unfortunately water won't be ready for the demo :silenced: We've done some preparations for it though, but we still don't have any water shaders ready (the part which makes water look "good"), so whenever we're using water placeholders currently, they just have a plain blue color :D Like this one:


    I'm hoping that Unity already has volumetric water handling baked in. Perhaps water is closer than we think

    Unfortunately there is nothing like that available out-of-the-box in Unity (and even if there was something available, I doubt it would work on a larger scale) :| We're definitely facing some technical limitations when it comes to dynamic water (modern hardware is still not powerful enough to simulate 100% accurate physical water on a large scale), but we'll certainly find a sufficient solution ;)

    Rising World is a 64 bit application and therefore there are basically no limits about the addressable amount of memory ;) However, as a Java application, the game has to pass the required amount of RAM to the VM before starting the game, this means the game cannot allocate more RAM if it runs out of memory.


    The amount of memory the game allocates depends on the amount of system RAM (at least this applies to the Steam version of the game). If you have more than 10 GB, the game will allocate up to 7 GB. Usually this is sufficient, but if you're using lots of custom images or create buildings with a high level of detail, it might be necessary to allocate more RAM. To do that, you can add a launch option in Steam: Rightclick on RW in your Steam library -> Properties -> Set launch option -> enter +memory DIRECT HEAP (replace DIRECT with the amount of direct memory [i.e. native memory used by textures, meshes etc], and HEAP with the amount of heap memory). For instance, if you want to assign 12 GB to the game, you could write +memory 6144 6144

    Generell ist das Ertrinken von NPCs tatsächlich nicht so schön... im Idealfall sollten NPCs das Wasser ohnehin vermeiden, aber vor allem das von dir erwähnte Problem mit den Reittieren ist natürlich ärgerlich - das sollte sich auf jeden Fall ändern. Wir haben leider noch nicht begonnen, an den NPCs für die neue Version zu arbeiten, daher kann ich noch nicht ganz so viel dazu sagen, aber wir werden das auf jeden Fall im Hinterkopf behalten. Vmtl. ist es am sinnvollsten, wenn NPCs - falls sie doch mal ins Wasser gelangen - einfach schwimmen (zumindest je nachdem, um was für einen NPC es sich handelt)^^