Posts by red51

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

Grundsätzlich ist das nachvollziehbar, aber damit würden die Mülltonnen, die es im Spiel gibt (und die so einen Slot im Inventar ja hinzufügen) irgendwo auch wieder nutzlos werden Es gibt Spiele, da ist so ein Mülleimer-Slot sehr wichtig (vor allem bei 2D Spielen wie zB Terraria, da man sonst zu oft die weggeworfenen Items wieder versehentlich aufhebt), aber bei einem Spiel wie RW ist das glaube ich nicht ganz so dringlich... wie gesagt, normalerweise ist das Mülltonnen-Objekt dafür gedacht. Es macht aber sicherlich Sinn, wenn der Mülleimer auch von Kisten aus zugänglich ist (momentan erscheint der Slot nicht, wenn man an einer Kiste steht).

Hmm... das kann ich leider auf Anhieb nicht reproduzieren. Die Suchfunktion erstreckt sich eigentlich auf alle Blaupausen (auch die in Unterordnern). Es wird aber nur der tatsächliche Name der Blaupause berücksichtigt, also der Name, der beim Erstellen angegeben wird - wenn der Dateiname zB nachträglich geändert wird, dann spielt das zB keine Rolle.

Wenn du das Problem mit einer bestimmten Blaupause reproduzieren kannst, könntest du sie mir evtl. zusenden?

Ja genau, der Auswahlbereich ist leider an die Weltkoordinaten gebunden. Das drehen zu können wäre tatsächlich manchmal praktisch, ist aber momentan leider noch nicht vorgesehen... wir könnten das evtl. einbauen, man müsste sich nur überlegen, wie die Steuerung dafür genau aussehen würde (ohne, dass der Durchschnittsspieler damit vll verwirrt wäre) Dein Vorschlag dazu klingt zwar gut, aber ich weiß noch nicht, ob das wirklich intuitiv genug wäre... das müssten wir mal ausprobieren

Quote from Rüdi

Zusatz: Bitte mal über die Größe der Bp- Vierecks nachdenken (0.25 0.25 0.25 wäre gut).

Auch das wäre grundsätzlich möglich. Wir müssen mal prüfen, ob sich das ggf. nachteilig auf das Raster beim Platzieren von Blaupausen auswirken würde. Ansonsten behalten wir das aber erstmal im Hinterkopf

Wir würden uns wohl aber generell erst daran setzen, nachdem das Welt-Update über die Bühne ist.

Quote from Deirdre

Das Platzieren bzw. Ziehen von Teilen ist mit der Einstellung 2 nicht wirklich besser geworden. Das Verdoppeln einer Reihe geht biel zu schnell und im Nu entstehen wieder mehrere Reihen übereinander. Das Schlimme dabei ist, dass man die zusätzlichen Reihen nicht sofort sieht, sondern meist erst beim Fliegen in den Boden.

Ich weiß leider gerade nicht genau, wie du das meinst Hinsichtlich des Ziehens von Bauteilen haben wir mit dem letzten Update eigentlich nur an den Problemen gearbeitet, die hier besprochen wurden, vor allem die Performance-Probleme sowie den Fehler, dass manchmal Blöcke in 3 Richtungen gezogen wurden (obwohl nur 2 Richtungen eingestellt waren). Tritt dieser Fehler bei dir weiterhin auf?

Quote from Schmitzi

Macht es einen Unterschied für die Performance, wenn man etwas anmalt oder den Gegenstand schon in der gewünschten Farbe herstellt und ein arbeitet ?

Nein, das spielt keine Rolle Generell macht es bzgl. der Performance auch keinen Unterschied, ob ein Bauteil gefärbt ist oder nicht.

Etwas anders sieht es bei Objekten (also Möbel, Türen etc) aus, da hat jedes gefärbte Element einen geringfügig höheren Memory-Verbrauch und wird marginal langsamer gerendert - das spielt aber absolut keine Rolle und dürfte sich in der Praxis nie bemerkbar machen (da man i.d.R. auch nie so viele Objekte platziert wie bspw. Bauelemente).

Quote from Deirdre

Es wäre vielleicht nicht schlecht, wenn die Größe des Tools noch kleiner skailierbar wäre.

Wie genau meinst du das? Das Lösch-Werkzeug hat doch bisher gar keine Größenbeschränkung?

Das ist definitiv nicht gewollt Ich kann das aber leider bei mir nicht reproduzieren, daher frage ich mich, ob es evtl. nur bei bestimmten Auflösungen o.ä auftritt? Welche Auflösung verwendest du bei dir? Und spielst du im Vollbildmodus, Fenstermodus oder " Vollbild im Fenster"? Alternativ könntest du sonst ggf. einmal einen Report senden (dazu bitte die Konsole öffnen und "report" eingeben, ggf. noch als Hinweis "Fehlender Cursor in Konsole" oder so hinzufügen)

Naja, von einem "Bug" kann eigentlich nur bedingt die Rede sein^^ Das einzige "Problem" ist, dass es ca. 1 Sekunde dauert, bis das Terrain-Tool nach dem Einschalten auch aktiv ist. Das ist aber immer nur beim erstmaligen aktivieren so (also wenn du F5 drückst) oder nachdem du den Modus wechselst (1-3). Danach trifft das eigentlich nicht mehr zu. Wir werden das mit dem nächsten Update auf einen kleineren Wert ändern (zb 250 ms), aber wie gesagt, eigentlich sollte auch die 1 Sekunde keine allzu große Einschränkung für den Spieler bedeuten.

Wenn du bei dir noch andere Probleme mit dem Tool hast oder es gar nicht funktioniert, dann sende uns ggf. einen Report nachdem das Problem auftritt

Quote from Deirdre

Gibt es den Bugfix mit dem nächsten Update in einem halben Jahr oder wird das früher sein?

Es sind leider keine Bugfixes mehr für das vorherige Update geplant, das würde die Entwicklung zu sehr aufhalten, daher würden Änderungen erst mit dem nächsten Update erscheinen - was aber definitiv nicht erst in einem halben Jahr kommt. Wenn dem so wäre, dann hätte RW keine Zukunft mehr

Jap, ich denke es wäre sinnvoll, wenn sich die Punktgröße da an die Bauteilgröße anpasst Wir werden das auf jeden Fall anpassen!

Das Löschen von Bauteilen ist tatsächlich noch etwas suboptimal... vmtl. werden wir das dahingehend ändern, dass es dann so funktioniert, wie in der Java Version: Nämlich dass der Mittelpunkt das Bauteils innerhalb des Auswahlbereichs sein muss, damit das Bauteil gelöscht wird (oder anders gesagt, dass das Bauteil zu mindestens 50% vom Bereich erfasst sein muss)

Quote from Messiahs

Hey Red! Ich fänd es schon ausreichend, wenn anfangs erst mal die gemäßigten Biome und damit das nächste Update so schnell wie möglich erscheint. Dazu noch den Bär und den Wolf als erste NPCs und alles ist schick.

Die gemäßigten Biome sind für uns auf jeden Fall erstmal die wichtigsten Biome Was die NPCs allerdings angeht, die werden erst mit dem Update nach dem Welt-Update dazukommen (tatsächlich gehören die NPCs neben dem Welt-Update zu den wichtigsten noch fehlenden Features)

Quote from lenko

Ich denke das hier abgesehen von den geplanten Biomen es ja noch unzählige Möglichkeiten an Biomen gibt die ins Spiel kommen können. hier könnte evtl eine Vorschlagliste mit Abstimmung beiden Seiten helfen.

Also wir sind für Vorschläge zu Biomen jederzeit offen Nach den gemäßigten Biomen sind vmtl. Schneegebiete und Wüsten besonders wichtig... das gute ist aber, dass wir mit der neuen Version viel eher die Möglichkeit haben, weitere "Biom-Updates" zu veröffentlichen, ohne sich um alte Welten sorgen zu müssen (wie bei der Java-Version)

Eine Abstimmung zu einzelnen Biomen ist aber leider etwas kompliziert... einerseits würden wir hier im Forum nur einen Bruchteil der Spieler erreichen (es müsste dann also evtl. schon eher so eine Umfage sein wie die damaligen Umfragen). Andererseits könnte das Abstimmungsergebnis ggf. nicht mit der Entwicklungsplanung zusammenpassen