Posts by red51

Quote from Deirdre

Was bedeutet das im Einzelnen? Was bedeutet unnused (Single- /Multiplayer) differenziert?

Ist dieser Befehl eher für Multiplayer gedacht, wenn der Spieler nicht mehr auf dem Server spielt, um das ewige Suchen und manuelle Löschen mit dem Rcon-Tool zu vermeiden?

Normalerweise werden beim Entfernen eines Bildes aus der Spielwelt (also beim Kaputthauen eines Posters) die Bilddateien im Welt-Ordner nicht entfernt. Dadurch wird unnötiger Speicher belegt... das ist natürlich in erster Linie im Multiplayer ein Problem, da hier schnell viele tausend Bilder im Laufe der Zeit zusammen kommen.

Mit dem Befehl cleanupimages werden in der Java Version dadurch alle Bilddateien von der Festplatte gelöscht, von denen es keine Instanz mehr in der Spielwelt gibt.

Der Befehl funktioniert im SP und MP, ist aber tatsächlich eher für den MP gedacht

Quote from Deirdre

Wie funktioniert das? Ich habe ja schon mehrmals angesprochen, dass ich einen 90° Winkel standardmäßig beim Neubeginn des Spiels eingestellt haben möchte.

Der Saver Befehl ?, wie funktioniert der überhaupt?, scheint ein unknown command zu sein.

Der setr Befehl sollte ja bekannt sein. Mit saver hingegen kann der aktuell eingestellte Rotationswert (der mit setr eingestellt wurde) dauerhaft gespeichert werden, sodass er beim nächsten Spielstart automatisch aktiv ist. Intern wird das dann lediglich in der config.properties Datei gespeichert (unter "game_construction_rotation_precision")

Hmm... die neue Version ist eigentlich darauf ausgelegt, dass der zuletzt verwendete Wert gespeichert bleiben soll (anders als die Java Version, bei welcher das immer auf einen Standardwert zurückgesetzt wurde)

Da die neue Version auch - anders als die Java Version - diese Werte getrennt für Dinge wie Blaupausen, Bauelemente, Pflanzen etc. speichert, wären das mindestens 9 zusätzliche Einstellungen, wenn man das von Hand ändern können sollte...

Ich weiß nicht, wie vorteilhaft es tatsächlich wäre, wenn das Spiel den Wert immer zurücksetzt... wenn es noch mehr Resonanz dazu gibt, dass sowas erwünscht ist, könnte man das ggf. implementieren (die aktuelle Implementation müsste dafür umgeschrieben werden).

Ansonsten wäre aber vll die Plugin API eine Lösung dafür. Man könnte recht einfach ein Plugin erstellen, welches die Werte bei jedem Laden einer Welt wieder auf einen beliebigen Standardwert setzt. Das Nachteil wäre allerdings, dass dies nicht im Multiplayer funktioniert (es sei denn das Plugin wird auf dem Server installiert)

Quote from Deirdre

Wäre es spieltechnisch machbar, die Oberfläche einer gesetzten Blaupause zu bearbeiten? Das Spiel müsste dann natürlich die Form erkennen, bei der das möglich ist.

Ich wüsste leider nicht, wie das aussehen soll... denn die Blaupause enthält ja i.d.R. viele Bauteile, die so an sich gesehen auch keine einzelne Oberfläche besitzen... aber auch sonst können Blaupausen bzw. die einzelnen Elemente darin nicht "verzerrt" werden (das ist leider auch der Grund, warum Blaupausen nicht in alle Richtungen individuell skaliert werden können)

Quote from SteffiOneiro

A) Wenn ich eine Fläche auswähle und diese plaziere, plaziert sie sich nur manchmal aber nicht immer. Das finde ich seltsam. Einmal passiert etwas, beim nächsten Versuch passiert wieder gar nichts. Da dachte ich, ob das Tool F 5 überhaupt schon voll funktionsfähig ist?

Hmm... kann es sein, dass das bei sehr großen Bereichen passiert? Hier gibt es scheinbar tatsächlich einen Bug, dass der Bereich zwar auf 128 Blöcke begrenzt ist, mit dem Tool aber ein deutlich größerer Bereich markiert werden kann (dann aber trotzdem nur ein 128 Block großer Bereich gefüllt wird) Das müssen wir noch fixen.

Oder hast du das Problem auch bei kleineren Bereichen? Falls ja, könntest du sonst ggf. einen Report senden? Lasse dafür am besten die Bereichsauswahl aktiv und öffne dann die Konsole (Taste ^). Gibt dort "report" ein und füge ggf. noch weitere Infos hinzu (zB "Kann kein Terrain platzieren" o.ä)

Quote from SteffiOneiro

C) Was ich fälschlicherweise mit F5 Punkt 4 gebaut habe und nicht gut aussah, bekomme ich auch nicht wieder gelöscht. Wie lösche ich die selbe Fläche wieder? Der Befehl "Undo" in der Konsole hat in dem Fall auch immer nicht funktioniert. Irgendwie war ich gestern ziemlich ratlos.

Normalerweise kannst du den Bereich löschen (also das Terrain innerhalb des Bereichs), indem du die Taste ENTF drückst^^

Quote from SteffiOneiro

E) Wenn diese Karten ohnehin zufallsgeneriert erstellt werden, währe es toll wenn man zukünftig eine Prozentangabe bzgl. Berge und Wassermenge etc. auswählen könnte oder zumindest mehrere Karten zur Auswahl hätte. Vielleicht kommt das ja auch mit einem künftigen Update und ich greife hier mit meinem Unwissen über das geplante irgendwie vor? Meine Fragen und Probleme sind aus meinem Spiel entstanden, wo ich nicht richtig umsetzten konnte, was mir so vorschwebte. Ich hoffe, meine Fragen und meine Kritik wird hier konstruktiv verstanden.

Das ist zumindest geplant, also dass man Einfluss darauf nehmen kann, wieviele Berge vs. Flachland es gibt... leider kann ich bisher noch nicht sagen, wann das genau kommt. Vmtl. erst, nachdem alle wichtigen Kernfeatures in der neuen Version implementiert sind (sodass wir die Storepage updaten können)

Quote from Deirdre

Was mich stört, ist die fehlende Möglichkeit des Texturwechsels bei 4.

Das ist tatsächlich ungewollt, das wird sich mit dem nächsten Update ändern

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

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)^^

Quote from SonoBionda

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

Quote from noci

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

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

Quote from noci

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.

Quote from noci

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

Quote from noci

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).

Quote from noci

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

Alles klar, mit dem nächsten Update wird es dann den Befehl toggleterrain geben, mit welchem sich das Terrain inkl. Vegetation ein- und ausschalten kann (im MP gibts dafür dann eine gleichnamige Permission, die standardmäßig deaktiviert ist)

Quote from Avanar

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 Schwieriges Thema

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) Auch nach einem Neustart des Spiels sollte der zuletzt eingestellte Wert aktiv bleiben (auch wenn er über setr geändert wird)

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

Quote from SteffiOneiro

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 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^^

Sorry für die späte Antwort! So einen Befehl können wir aber grundsätzlich einbauen

Soll das Terrain dabei komplett ausgeschaltet werden (also auch keine Kollision mehr etc)? Soll es nur das Terrain betreffen, oder auch Vegetation, Gras etc?

Quote from Kyo

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

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

Quote from ArcticuKitsu

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 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 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

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

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...

Quote from noci

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"?^^

Quote from paulevs

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

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^^

Quote from paulevs

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 ), 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.

Quote from Desmagu

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)