Posts by red51

Quote from Deirdre

Der Undo-Befehl funktioniert beim Terrain nicht wirklich 100%ig.
Leider sieht das Ergebnis bei mir öfter wie auf dem Bild aus. Es handelt sich dabei um größere Flächen die nicht mehr zurückgesetzt werden.
Der Undo-Befehl findet zum Zurücksetzen dann nichts mehr.

Leider ist anhand des Bildes nicht nachvollziehbar, was genau passiert ist bzw. wie das zustande kam Sieht der Chunk denn wirklich so aus (also auch nach dem Neuladen der Welt bzw. wenn du "refreshchunk" in die Konsole eingibst während du dich in dem Chunk befindest)? Sonst könnte das vll auch "nur" ein Anzeigefehler sein.

Ich weiß leider nicht genau, was du meinst Es gibt keine Einstellung für einzelne HUD-Elemente, nur für das ganze HUD. Poste sonst evtl. einmal einen Screenshot, auf welchem das Problem sichtbar ist.

Beziehst du dich auf die Java Version? Ansonsten wäre die Hilfe-Sektion für die neue Version evtl. der passendere Ort für den Thread

Rising World sollte immer Screenshots im eigenen Ordner abspeichern, zumindest sofern du die Screenshot-Funktion von Rising World selbst verwendest. Das ist i.d.R. die Taste, die in den Spieleinstellungen (unter "Steuerung") für "Screenshots" zugewiesen ist. Wenn aber "In Steam Bibliothek speichern" in den Einstellungen aktiv ist (Verschiedenes -> ganz unten), dann macht RW auch dann einen Screenshot, wenn du die Steam-Taste dafür drückst (Steam hat ja seine eigene Screenshot Funktion, ich glaube standardmäßig ist das F12). Wenn das ausgeschaltet ist, dann macht beim Tastendruck der Steam-Screenshotfunktion natürlich nur Steam einen Screenshot (und RW hat nichts damit zutun).

Quote from Rüdi

Das wäre schon schön wenn man direkt über das Inventar wählen könnte, bis dahin sind die Konsolenbefehle aber auch hilfreich. Danke

Ja, das stimmt, ich denke das wäre sinnvoll, wenn wir das noch in die normale Formauswahl mit reinbringen

Quote from Deirdre

Beim Ziehen habe ich Platzieren von zwei Reihen eingestellt. Man muss höllisch aufpassen, dass für eine einzige vorgesehene Reihe nicht mehrere Reihen entstehen. Ich kann jetzt nicht sagen, dass sich durch das Update etwas geändert hat.

Hmm... vielleicht reden wir auch von zwei verschiedenen Dingen. Der Bug im verlinkten Thread war eigentlich der gewesen, dass sich da Werkzeug manchmal so verhalten hat, als wenn es auf "3 Richtungen" gestellt wäre (obwohl es nur auf 2 Richtungen eingestellt war). Das war nicht erst beim Platzieren, sondern schon die Vorschau der Blöcke war so gewesen (also 3 Richtungen).

Wenn du was anderes meinst, kannst du evtl. einen Screenshot oder sogar Video davon posten?

Quote from Deirdre

Beim Ziehen einer Hausdecke mit 111 Block hört der Ziehvorgang auf, wenn die Lücke zur Wand weniger als 1 Block beträgt. Ist das so vorgesehen?

Der Schwellenwert beträgt 0.5, also wenn die Lücke kleiner als 0.5 ist, dann wird da keine weitere Reihe angelegt. Das ist mehr oder weniger gewollt. Ist vmtl. eher eine Glaubensfrage, was besser ist... theoretisch könnten wir das auch ändern

Quote from Deirdre

Die Schatten auf der Mauer habe ich noch nicht oft entdeckt. Sollte nur zu deiner Information sein. Habe mittlerweile die Mauer aber abgerissen, so dass ich es nicht mehr überprüfen kann.

Verstehe... falls es nochmal auftreten sollte, kannst du es ja vll einmal ausprobieren

Quote from Deirdre

Wie wäre es wenn man gewisse Gebiete, fertig gebaute Wasserflächen, einfrieren könnte oder die (Neu-)Bearbeitung "seines" Wasser begrenzen könnte?

Das hatte ich mir im ersten Post ja auch schon überlegt, aber zumindest in puncto Wasserfälle wäre sowas vmtl. schwierig zu handeln (man müsste es im richtigen Moment "einfrieren", aber auch das Tool dazu müsste entsprechend umgesetzt sein)... da müssen wir uns mal überlegen, wie wir da am besten rangehen

Ein Konsolenbefehl wäre evtl. denkbar. Wenn man gleichzeitig in den Optionen vll temporär die Geschwindigkeit runterstellt, mit welcher Wasser aktualisiert wird (würde aber nur im SP funktionieren, da das im MP vom Server kontrolliert wird), könnte man einen Wasserfall vll sogar umsetzen. Riecht aber nach Pfusch

Quote from Deirdre

Ich habe bei einigen Seen durch Entfernen der Luftlöcher im Wasser viel Freude mit dem Entfernen von Bubbles auf dem Wasser gehabt. Trotz der Höhenmarkierung im Tool nicht ganz einfach. Reflektionen usw. aus-/ und wieder anschalten, damit die Oberfläche genau untersucht werden konnte.

Das sollte eigentlich kein Problem mehr darstellen Also Dinge wie Löcher in den Grund des Sees buddeln, oder Ufer umgraben funktionieren jetzt schon recht gut.

Schwierig ist es noch, ganz neue und große Seen anzulegen - da merkt man schnell, wieviel Wasser da eigentlich reingeht, da das Wasser sich sofort verteilt und der See gefühlt nur sehr langsam gefüllt wird. Unterm Strich kommen da sehr viele Terrain-Bearbeitungen in kürzester zustande (das permanente Fließen des Wassers und das permanente Auffüllen des Sees).

Unter dem Gesichtspunkt ist es sicherlich nicht verkehrt, jederzeit zwischen statischem und dynamischen Wasser hin- und herzuschalten (dann könnte man große Wassermassen zunächst statisch in Ruhe platzieren und anschließend dynamisch machen)

Zum Steam-Verhalten kann ich dir leider nicht mehr sagen, aber was RW angeht, da kommt es ein wenig darauf an, ob in den Spieleinstellungen unter Verschiedenes -> Screenshots die Einstellung "In Steam Bibliothek speichern" aktiv ist. Standardmäßig ist das aktiv, wenn das aber ausgeschaltet ist, dann agieren die RW Screenshots komplett unabhängig von Steam (sprich sie werden beim Screenshot-Tastendruck [die Taste, die in den Einstellungen definiert ist] vom Spiel erstellt und im Spielverzeichnis gespeichert, Steam bekommt aber nix davon mit).

Grundsätzlich ist das bereits möglich Im normalen Baumenü tauchen die Glasscheiben leider nicht bei normalen Texturen auf (evtl. ändern wir das noch), aber wenn du per Befehl "item construction" oder "item pnb" eingibst, dann erscheint auch eine Texturauswahl mit allen Formen (einschließlich der Scheiben)

Alternativ kannst du auch direkt "item pane" eingeben, um eine Scheibe mit einer gewünschten Textur zu erhalten.

Stimmt, bei dieser Auflösung ist der Cursor tatsächlich nicht vorhanden Danke für den Hinweis, das müssen wir einmal genauer unter die Lupe nehmen

Quote from Deirdre

Beim Platzieren, eingestellt auf 2 Reihen, müsste ich das Platzieren auf 1 Reihe reduzieren, sonst habe ich bei einem Fußboden mehrere Reihen untereinander

Kannst du das evtl. etwas genauer erklären? Meinst du damit, dass das Problem, welches hier beschrieben war, bei dir weiterhin auftritt? Das haben wir eigentlich mit dem letzten Update behoben und leider kann ich das bei mir nicht mehr reproduzieren

Quote from Deirdre

Report konnte nicht gesendet werden.

Dabei handelt es sich leider um dieses Problem: RE: Update 0.4.8: Vegetation, Ackerbau und volumetrische Wolken

Wie gesagt, das passiert, wenn die aktuell eingestellte Auflösung zu groß ist - damit wird die Größe des Reports insgesamt zu groß. Das können wir leider erst mit dem nächsten Update beheben. Ansonsten kann es kurzfristig helfen, wenn die Auflösung im Spiel kurz temporär heruntergestellt wird, um den Report zu senden (nicht schön, aber wie gesagt, das wird mit dem nächsten Update behoben).

Quote from Deirdre

Es wäre schön, wenn beim Terraintool wie in der Java-Version eine Höhenanzeige implementiert würde. So ist das immer eine Art Try, ob die Höhe passt oder nicht.

Das wird mit dem nächsten Update dazukommen

Quote from Deirdre

Bei einer Mauer sind durch die Schatten die einzelnen Blöcke erkennbar. Nicht gut zu sehen, aber dennoch unschön.

Wie genau treten diese Schatten denn auf? Sind die immer sichtbar, oder nur, wenn du die Kamera bewegst bzw. umherläufst? Ich bin mir nicht sicher, ob diese Schatten wirklich von der Sonne stammen... treten sie bei dir auch auf, wenn du testweise die volumetrischen Wolken deaktivierst?

Quote from lenko

red51, du hast ja geschrieben das es in Zukunft auch noch weitere und größere Boote geben wird.

Spätestens wenn es Tiere gibt, brauchen wir mindestens ein Transportboot oder Floß um ua die Gefangenen Tiere auch auf die eigene Insel zu transportieren. Praktisch wäre auch eine Möglichkeit eine oder Mehrere Kisten/Tonnen ( je nach Bootgröße) platzieren zu können. Grad wenn es noch keinen Packesel gibt und das ganze gesammelte Material nach Hause soll.

Ja genau, mehr Boote und auch größere Boote bzw. Schiffe sind geplant, übrigens auch ein Floß

Bei den größeren Booten sowie dem Floß wird man die Möglichkeit haben, zumindest Objekte (und ggf. auch Bauelemente, bin mir da aber noch nicht ganz sicher) darauf zu platzieren, also Kisten, Lampen etc.

Was Tiere angeht, da müsste man sich einmal überlegen, wie der Transport am besten vonstatten geht. Das Spiel bräuchte eine passende Mechanik, um Tiere generell zu führen (damit man sie auch überhaupt erst aufs Boot oder in die Nähe des Bootes bekommt)

Quote from Yaromid

Könnte man damit denn in der Zwischenzeit einen "Hack" machen, indem man irgendwo in seinem See eine "Aushöhlung" einbaut, damit das "überschüssige" Wasser dort reinfließt?

Nach aktuellem Stand würde die Aushöhlung wohl trotzdem irgendwann voll- bzw. überlaufen Ein anderes Problem ist aber unter Umständen auch die Performance, da der Wasserfluss in dem Fall durchgehend berechnet werden muss.

Wir müssen daran noch etwas herumschrauben... momentan ist die "unendliche Wasserquelle" generell noch brandgefährlich, da man sich damit zu schnell seine Welt zerstören kann (wenn man irgendwo auf einem Berg einen großen Blob "unendliches Wasser" platziert, und ein sehr kleines Update-Interval für Wasser eingestellt ist [=schnelles Fließen], dann flutet man sich ruck zuck einen Großteil seiner Welt, ohne, dass man mit den Terrain-Werkzeugen noch rechtzeitig gegensteuern könnte) Das müssen wir unbedingt noch anpassen, da wir vorher den unendlichen Wassertyp zumindest nicht im Creative-Modus anbieten könnten...

Evtl. wäre ein "halbstatischer" Wassertyp sinnvoll, welcher dann eher so ein Verhalten wie in Minecraft an den Tag legt (sprich er kann nur eine bestimmte maximale Distanz fließen und verbleibt dann statisch in seiner Position). Ich bin mir sicher, dass wir langfristig eine adäquate Lösung finden, ich weiß nur nicht, ob das Teil des ersten Updates sein wird

Der "Screenshots" Ordner im Rising World Verzeichnis hat grundsätzlich keine Relevanz für Steam. Darin können Bilder also grundsätzlich nach eigenem Ermessen gelöscht werden, ebenso der Thumbnail Ordner. Du kannst auch einstellen, dass das Spiel gar keine separaten Thumbnails erzeugen soll (in den Spieleinstellungen unter "Verschiedenes" -> "Screenshots").

Steam hingegen speichert Screenshots in einem ganz eigenen Verzeichnis, nämlich im unter \Steam\userdata\<AccountID>\760\324080\screenshots\ (im Fall von RW). Der Dateiname der Bilder dort beinhaltet das Datum, also zB "20220721173510" für den 21.07.22 17:35:10 Uhr, gefolgt von einem Unterstrich und einer Nummer (meistens "_1"). Dort ist auch ein eigener "thumbnails" Ordner.

Damit Screenshots im Steam-Client auftauchen, müssen die in dem Ordner abgelegt werden (und vmtl. auch einen passenden Dateinamen haben, wie oben beschrieben, bin mir da aber nicht sicher). Manuelle Änderungen am Ordner erkennt Steam scheinbar erst, wenn der Steam-Client neugestartet wird.

Quote from Deirdre

Ich meinte die Größe des Löschquadrates bzw. -Rechtecks.

Ich weiß leider noch nicht, was du meinst Das Lösch-Werkzeug kann doch beliebig klein skaliert werden (hier ein Bild des Lösch-Tools neben einem 1x1 großen Block, aber wie gesagt, geht sogar noch kleiner als auf dem Bild):

Quote from lenko

Ich würde zusätzlich eine Dreipunkt-Variante zum Löschen gut finden. So könnte Mann etwas genauer scalieren

Ähnlich wie hier wäre die größte Herausforderung dabei vmtl. eine passende Steuerung anzubieten, damit das nicht zu fummelig wird Wir müssen damit mal etwas herumexperimentieren und schauen, welche Optionen sich da anbieten würden

Im Creative-Modus wäre ein dauerhafter Mülleimer-Slot vielleicht gar nicht so verkehrt, ich packe das mal auf unsere Liste

I've tried to explain them a bit in this topic RE: Player Animation's

Basically the game is written with multiplayer in mind, so it consists of a server and the clients (even in singleplayer, you can think of it like an "integrated server"). Plugins are always executed on the server, so you can't get a result from a player immediately (because the server has to request that data from the client first). For instance, if you want to get the text from a text field (which only exists on the client), the server has to retrieve that data from the client first (or more precisely, there is a minor delay between the call and when the result is available). That's where callbacks are being used.

A callback is basically like a "method" (containing your code) that gets executed once the server receives the result from the player. In this case, once the server received the text field text from the client, it invokes the callback method. For example:

textField.getCurrentText(player, (String txt) -> {
    //This is your method body, i.e. the code that gets executed when the server gets the text.
    //The current text of the text field is stored in the "txt" parameter
});

The Java language features which are relevant in this case are anonymous classes and so called lambda expressions (you can find lots of information about these things on google)

The original idea was indeed to have blueprints just create some sort of "construction site" in survival, either spawning a storage box to put the requires resources, or a "ghost" structure you can interact with There was a discussion about that some time ago in the German forum section: https://forum.rising-world.net/thread/11576

An alternative approach that had been suggested was to have the resources as requirement to craft the blueprint (which could then be placed anywhere without intermediate steps).

Actually we're still not sure which approach would be better. The latter would be a bit easier to implement, so maybe we will stick to that approach for the time being. In order to fix the resource problem for bigger structures, we could add a chest to the blueprint table (where you could deposit the required resources), or maybe the blueprint table could use resources from nearby chests automatically. Not sure about that

Thanks for the explanation! I must admit I never came into contact with that term before

From a visual point of view, wouldn't it look like the current "dense fog" we already have in the game (i.e. the effect you get via weather densefog 1)? So the only difference would be that it would have an impact on the temperature, and wouldn't go above a certain altitude?

Das Thema ist tatsächlich etwas schwierig Es wird zwar "unendliche Wasserquellen" geben, aber die hätten wohl tatsächlich das Problem, dass sich das Wasser darunter ansammelt. Zwar ist auch hier eine Begrenzung drin, sprich das Wasser "versickert" nach einer bestimmten Distanz, aber bei kleineren Wasserfällen könnte das trotzdem ein Problem darstellen.

Die ideale Lösung wäre eigentlich, wenn man das Fließen des Wassers in einem bestimmten Stadium "einfrieren" könnte, sodass man einerseits die Fließoptik hat, andererseits das Wasser einigermaßen dem Terrain angepasst ist. Allerdings ist es vmtl. schwierig, sowas in einem Tool umzusetzen (und auch schwierig als User, den richtigen Zeitpunkt zu erwischen)...

Ein vordefiniertes Objekt oder ein Partikeleffekt, wie lenko vorschlägt, ist natürlich die einfachste Lösung (auch aus Performance-Sicht am vorteilhaftesten), aber tatsächlich leider auch etwas unflexibel.

Ich denke, dass wir uns nach dem Welt-Update nochmal ernsthafte Gedanken zu dem Thema machen müssen. Wir müssen insgesamt auch prüfen, inwieweit die Fließmechanik angepasst werden muss, und auf welche Probleme wir insgesamt noch stoßen.

Für die Zukunft (nach dem Welt-Update) ist auch nochmal ein zusätzliches Wasser-Update geplant: Das Welt-Update wird zwar fließendes Wasser beinhalten, mit welchem man uneingeschränkt interagieren kann (und insgesamt wird das Wasser in dem Update dadurch bereits deutlich umfangreicher als in der Java-Version sein), aber in Zukunft werden wir die Fließmechanik nochmal verfeinern und erweitern und vor allem auch den Wasser-Shader und die generelle Wasseroptik anpassen (in einem eigenständigen Update).

Vielen Dank für das Feedback

Die Boote sind tatsächlich aus der Java-Version, die waren ja auch dort ein eher neueres Feature, sodass da eigentlich kein Bedarf war, die von Grund auf neu zu machen^^ Allerdings haben wir die Boote optisch etwas angepasst, sodass sie in der neuen Version geringfügig besser aussehen. Und man wird sie natürlich passenderweise färben können

Es kommen später aber auf jeden Fall noch Segelschiffe und generell größere Boote hinzu.

Quote from Yaromid

(wie ist in eurem Zweierteam eigentlich die Arbeit aufgeteilt?)

Darauf kann ich leider gar keine konkrete Antwort geben, da es immer etwas unterschiedlich ist und auf das Feature drauf ankommt