Posts by red51

A new update (0.9.2) is available now!
Latest Hotfix: 0.9.2.1 (2026-05-13)

    I'm glad to hear you figured it out :) A "high" spawnrate is indeed quite problematic, since NPCs always spawn permanently, and over time, a dungeon may become overpopulated.


    But I am wondering. since they seem to be spawning slowly and safely now, no overspawning so far, is it safe to leave the spawnrate at 3.0 or is that what is causing this glitch in the first place?

    I'd recommend to set it to a value not higher than 2.0, otherwise you will run into the same issue again. In the game settings (for singleplayer), this value is actually capped at 2.0 (200%), but the server unfortunately accepts any value :|


    However, a value of 2.0 should be fine if you want many skeletons. It will take a few days though until a dungeon is fully populated.


    Hey red51, would the new version be able to actually have a proper setting for this someday?

    Yes, it is our intention to rework the way how the game interprets the spawnrate setting :) Currently this setting not only determines how many NPCs the game will spawn at once, it also affects the checks of the game if any other NPCs are in proximity - this is the main reason why it spawns so many NPCs over time...


    The game didn't crash, my server ramped up to around 2.4GB memory, so I assume this would be technically possible in the new version?

    Basically the NPC handling (rendering, animations etc) is quite efficient, currently the collision detection for NPCs has a big impact on performance: The Java version uses a pretty old physics engine which has limited functionality and also suffers from a few issues. We wrote an overly complex system for NPC collision detection to prevent them from passing through walls or falling through the ground, but this comes at a cost.

    This won't be necessary for the new version, since it uses a much more robust physics engine - so in this regard, the new version will handle NPCs more efficiently.


    Having that said, thousands of NPCs in close proximity will still have a considerable impact on performance in the new version. It's not a big issue at all for the server (NPCs have a rather low memory overhead, and stuff like AI handling is fairly optimized), but rendering them on the client is quite costly. But I can probably say more about that once NPCs are implemented ^^

    Einige Formen haben wir davon schon und mit der Möglichkeit, diese dann noch in der Länge und Breite zu ziehen entstehen auch wieder neue Baumöglichkeiten.

    Einige dieser Formen fehlen zwar (zB der Torus), da bin ich mir nicht sicher, ob das wirklich benötigt wird :thinking: Das meiste davon ist aber mit den bisher vorhandenen Blöcken, der Skaliermöglichkeit sowie auch der Möglichkeit, die Oberseite von Blöcken separat zu skalieren, durchaus bereits umsetzbar ;)


    Bin mir jetzt nicht sicher ob es rechte u. linke Endstücke gibt aber z.B wenn man zwei Werkbänke nebeneinander stellt währe es gut wenn mann die eine Spiegeln könnte das dann die beiden Schraubzwingen entweder innen oder aussen sind.

    Das ist sogar bereits in der Demo möglich: Es gibt eine Taste, mit welcher das aktuelle Bauelement gespiegelt wird (standardmäßig auf "Ende" gelegt, kann aber in den Einstellungen geändert werden [in der Bausektion "Spiegeln" genannt]). Das ist besonders praktisch für Türen (um bswp. Doppeltüren zu erstellen) :)


    Was wären denn die Grenzen bei der Skalierung? Wie groß, lang und hoch kann so ein einzelner Block maximal sein? Ich freue mich schon auf größere Bögen beim Brückenbau :drooling:

    Im Survival-Modus müssen wir uns da noch Gedanken machen, ich denke aber, eine max. Größe von 4 Blöcken wäre sinnvoll (sodass ein Block maximal 4x4x4 Blöcke groß werden kann). Im Creative-Modus liegt das Limit derzeit bei 32 Blöcken (sprich ein Block kann maximal 32x32x32 Blöcke groß werden), eventuell reduzieren wir das aber noch ein kleines bisschen.


    Wie wäre es, wenn man so ein Art Suche einbaut, wo man die Blöcke suchen kann, vielleicht mit diversen Filtern wie grösse, form etc

    Naja, in puncto Größe gibt es ja quasi keine Unterschiede zwischen den Blockformen, denn standardmäßig haben alle Blockformen erstmal die gleiche Referenzgröße. Erst der Spieler ändern ja dann während des Bauens die Größe (so wie man in der Java Version die Größe von Planken und Balken angepasst hat).

    Was die verschiedenen Formen angeht, hier müssten wir einmal schauen, wie sich das ganze letztenendes verhalten wird, sobald wir die entsprechende UI dafür umgesetzt haben. Wenn dort ein gewisser Grad an Unübersichtlichkeit herrscht, könnte man so eine Suche evtl. einbauen.


    Mal ne andere Frage, könnte man einen Blockeditor vielleicht machen, womit man selbst vielleicht eigene Blöcke erstellen kann und diese werden dann ins Game importiert

    Das würde leider ein wenig den Rahmen sprengen, denn dafür müssten wir ja quasi einen eigenen Modelleditor entwickeln (was grundsätzlich nochmal ein ganz eigenes Thema für sich ist) und ins Spiel integrieren :dizzy: Aber der Nutzen eines solchen Features wäre sogar gar nicht so groß wie es scheint, denn die neue Version deckt wirklich bereits nahezu alle benötigten Formen ab ^^


    Könnte man, anstatt separate Formen zu verwenden (ich persönlich bin ja immer noch dafür ^^ ), in der Konsole das gewünschte Teil, also z. B. Arc oder Stair, eingeben

    um den Block sofort in dieser Form zu erhalten

    Ja, das ist für die neue Version schon implementiert ;) Das wird dann über den id Command gelöst (damit kann man dann - zumindest im Creative-Mode - jederzeit die Textur und Form ändern).

    Kurze Frage: Werden die Texturen hier einfach skaliert oder tatsächlich "neuberechnet", damit sie zur Form passen? Erkenne es auf dem Bild nicht ganz.

    Die Texturen bzw. die Texturkoordinaten bzw. die UV-Koordinaten werden neu berechnet, wie in der Java Version ;) Hier mal ein Vergleichsbild mit einer Rampe, bei welcher die Koordinaten nicht angepasst werden (die Textur also einfach gestretched wird):

    Ich bin für Separate Items allerdings für eine Art Spiegeln Funktion damit würde man keine linken oder rechten bauteile mehr brauchen sondern nur ein Endteil spiegeln.

    Kannst du das etwas genauer erläutern? :) Was genau meinst du mit "linke oder rechte Bauteile"?


    Seid ihr noch offen für Blockform wünsche?


    Zurzeit haben wir eine Rampe von 45 Grad auf ein Block

    Mein Vorschlag wäre Flachere Rampen.

    Klar, wir sind immer offen für neue Blockformen ;) Auch nachträglich können wir - anders als in der Java Version - problemlos neue Blockformen hinzufügen ^^


    Was die Rampen angeht: Hier ist es grundsätzlich eigentlich nicht nötig, verschiedene Abwandlungen mit unterschiedlichen Steigungen zu haben. Denn alle Blöcke werden in der neuen Version skalierbar sein, entsprechend auch die Rampen. Wenn man eine Rampe in die Länge zieht (oder die Höhe verringert), hat man automatisch eine geringere Steigung, beim Reduzieren der Länge (oder beim Vergrößern der Höhe) hingegen eine stärkere Steigung. Hier ist mal ein Bild davon, wie das aussehen würde:

    Will the game be easier to mod than the java version?

    Modding will be more or less like in the Java version. The main route to modify the game will be to use the Plugin API ;)


    Also, Will there be ships??

    Yes, ships are planned (although that doesn't seem to be a "behind the game"-question) :D

    When i heard that the game is going with Unity i was thinking if you are going to take the asset aproach that is offered in Unity Store like Map Magic 2 for infinite world, Digger Pro for digging and also MicroSplat to cut the time that it will take to actualy get the game to Unity, i am a bit curious, have you guys build everything from scratch or more to say migrated from Java once you moved to Unity?

    Currently we're mostly staying away from the asset store. We took a look at some assets but most of them aren't really suitable for a game like RW (procedural voxel world with multiplayer). We would give away too much control by using them, so we decided to create most stuff from scratch ;)

    I have the dedicated server software but when I run it, i see a command prompt pop up for a split second then goes away. Thats it. What do I do after that?

    This sounds like an error occurs. As yahwho mentioned, please have a look if there is a file called "errorlog" or "hs_err_pid" in your server directory. Alternatively you can also have a look for a log file in the "Logs" folder. Maybe create a separate topic about that, since this isn't necessarily related to the original issue ;)

    I hope that there will be a little spare time? Perhaps on a holiday? 😃

    We haven't had a vacation last year (except the days between Christmas and New Year), so no, unfortunately that doesn't work. However, if you have any specific questions about development, feel free to ask :)


    I'd suggest looking up videos on people making stuff with Unity - that can give you an idea as to how red51 & friends develop RW.

    Actually our workflow differs very much from the standard authoring way in Unity. Just like the Java version, almost everything is done programmatically (except things like animations, textures etc) ^^

    Denn wenn sie noch nichts verkaufen, besteht wenigstens die Hoffnung, dass dies noch vernünftig implementiert wird

    Naja, bei RW heißt es ja nicht, dass wenn ein bestimmtes Feature verfügbar wird, es dann auch so in der Form in Stein gemeißelt ist und nicht mehr geändert werden kann ^^ Gerade am Anfang kommt es ein wenig darauf an, ob auch bereits alle passenden Items zur Verfügung stehen um einen "vernünftigen" Verkauf zu realisieren. Andererseits wäre es aber auch schade, wenn wir Features solange künstlich zurückhalten würden, bis sie in "perfekter" Form implementiert werden können.


    Wenn wir den Verkauf von Items implementieren werden wir versuchen, den optimalen Weg zu finden, sind aber da dennoch auf Feedback angewiesen. Sicherlich wird man da nachträglich an einigen Stellschrauben herumdrehen müssen. Wenn das Feature also da ist und du findest Ungereimtheiten, lass es uns einfach wissen :)

    Das heißt also ja, dass man die blöcke so umstellen kann das sie aussehen wie eine Regenrinne ODER! wird es eine Regenrinne ins spiel programmiert??

    Sorry dass ich darauf nicht nochmal explizit eingegangen bin: Aber wir haben auch eine halbe Variante des hohlen Zylinders vorbereitet (was sich ideal als Regenrinne eignen würde) ;)


    Würde es da nicht Sinn machen wenn man dafür halbe Rundhölzer nimmt die man anschließend von der geraden Oberseite hin zur unteren Seite verdünnen kann ?

    Dieser Grad der Einstellung wird leider nicht möglich sein :/ Einerseits müsste man für sowas eine einigermaßen "logische" Steuerung haben, die auf alle (oder zumindest mehrere) Blockformen in irgendeiner Form anwendbar wäre, andererseits müssten die Elemente für sowas deutlich mehr Polygone haben - was sich dann wieder in der Performance und Weltgenerierungsdauer niederschlägt.

    Aber in diesem konkreten Fall wird es sowohl halbe hohle Zylinder als auch die normalen halben Zylinder (wie schon in der Java Version) geben. Im Falle einer Regenrinne würden sich dann die normalen halben Zylinder (entsprechend klein skaliert) gut als Endstücke anbieten.


    wird es endlich eine Münzpressmaschine ( <-- weiß gar nicht ob das überhaupt der richtige Name ist :thinking: ) geben und damit eine gescheite ingame Währung?

    Oh, sorry, die Frage ist leider etwas untergegangen :saint: Eine Ingame-Währung ist auf jeden Fall geplant. Ich bin mir aber noch nicht ganz sicher, was die Münzpresse angeht: Ich würde es vmtl. vorziehen, wenn man Geld nicht selber herstellt, sondern nur bspw. durch Handel mit NPCs erhalten kann (oder auch in Kisten finden kann etc). Das würde es einfacher gestalten, ausgeglichene Preise zu haben. Wenn man Geld selber herstellt, dann ist der "Wert" des Geldes letztenendes nur von den benötigten Rohstoffen abhängig (wenn man bspw. aus 1 Goldbarren 10 Goldstücke bekäme, dann heißt das zwangsläufig auch, dass 1 Goldbarren quasi 10 Goldstücke wert ist - entsprechend müssten andere Rohstoffe und Items in Relation dazu bepreist werden). Aber hier müsste man sich nochmal konkret Gedanken machen :thinking:

    Wird die Liste irgendwo persistiert?

    Dieses Plugin speichert seine Teleportpunkte in einer Datei innerhalb des Plugin-Verzeichnisses (und lädt sie nach einem Neustart entsprechend). Also ja, Teleportpunkte bleiben auch nach einem Neustart erhalten ;)


    Eventuell ist das auch ein Problem des 4players Server das die Liste jeden Tag nach Server reboot weg ist

    Evtl. fehlen irgendwelche Schreibrechte für den Plugin-Ordner? Falls du via FTP den Serverordner einsehen kannst, kannst du ggf. prüfen, ob im Plugin-Ordner (also dort, wo auch die .jar Datei des Plugins liegt) eine ".list" Datei vorhanden ist.

    If you have the regular Steam client installed (and if you own the game on Steam), you can also find the dedicated server under "Tools" where you can just download and run it through Steam :)

    However, if you want to set up the server via SteamCMD, this thread contains a few more information about that: Set up a server with SteamCMD

    Of course we could share more details about development, but unfortunately we don't have much spare time for setting up live streams or creating videos which are only relevant to a very small fraction of the community :/

    how about having the block table be able to change the shape of an item already made. so if you made 100 cubes, you can change them to wedges at the table

    The only problem with this approach would be that it requires a separate UI inside the crafting menu (one which allows me to insert the particular stack of cubes I want to modify), which makes the crafting menu a bit more complicated... :/

    In this case, I'd prehaps prefer to rely on a recycler which could give me back the original resources (or at least some of the original resources) so I can craft a new stack.


    also it would be nice to maybe have a finishing table, so once you have the shape you want you can go to the finishing table to get the texture you want. also allow us to change the texture of premade blocks at this table so you dont have bunches of blocks of various shapes with unwanted textures.

    Basically this is a good idea, but it would introduce some issues when it comes to resources: What happens if I want to turn my stack of stone cubes into a stack of wooden cubes? If this still requires wood as ingredient, I could simply craft a new stack :thinking:

    Wie wäre es denn unter F6 die Blöcke auch in der Form auswählbar zu machen um Wände oder Sonstiges in größerem Maße hochzuziehen?

    Wie meinst du das genau?^^


    Den Halbblock gibt es da (noch) nicht

    Den Halbblock wird es so in der neuen Version nicht mehr geben, weil dafür eigentlich kein Bedarf mehr ist ^^ Da alle Blöcke skalierbar sein werden kann der reguläre Block einfach in der Höhe um die Hälfte verkleinert werden um dasselbe Resultat zu erhalten. Wenn mehrere Blöcke gleichzeitig platziert werden (in Reihe bzw. als Fläche), passen sich alle Blöcke entsprechend dem ersten Block automatisch an.


    Zu den Bildern: Die Möglichkeiten sind toll, allerdings frage ich mich auch wer diese bis zum Ende ausschöpfen würde.

    Also von dir hätte ich am allerwenigsten erwartet, dass du ein zusätzliches Bau-Feature hinterfragst :lol: Nicht böse gemeint ;)

    Aber die Möglichkeit, die Oberseite eines Blockes separat zu verschieben empfinde ich als Laie recht praktisch - schon Dinge wie ein Dachstuhl lassen sich damit einfacher erstellen (man könnte den Balken in dem Fall zwar auch einfach drehen, aber dann überlappt er teilweise wieder mit anderen Dingen). Und auch das Verkleinern der Oberseite ist manchmal vorteilhaft, denn dann könnte mit nur 1 Block recht schnell ein abgeschrägter Sockel bspw. für meine Säule erstellt werden (mit konventionellen Mitteln bräuchte man sonst 1 Block, 4 Rampen und 4 Rampen-Eckstücke).


    Zugegebenermaßen sind das alles Dinge, die auch in der Java Version mit Planken schon möglich waren. Es gab ja streng genommen fast nichts, was in der Java Version wirklich unmöglich war, denn mit Planken konnte man irgendwie fast alles "tricksen" (auch wenn manche Dinge extrem kompliziert und umständlich waren). Der "große Fortschritt" in der neuen Version soll daher ja eher darin liegen, das Handling und die Tools zu vereinfachen, um das Bauen allgemein zu entspannen - das soll die Nerven der Profis schonen, und gleichzeitig den Nicht-Profis ermöglichen, etwas mehr als nur ein würfelförmiges Haus zu erschaffen ;)


    Wie wird das mit den Dreiecken sein? Bisher nur durch Aneinanderreihung von Dreiecken und Magnetfunktion verdickbar. Der Sizebefehl funktioniert aufgrund der Dreidimensionalität nicht. Eine vierte Dimension wurde bereits irgendwann mal angesprochen. Gibt es da schon neue Erkenntnisse?

    In der neuen Version wird es wohl Planken und auch dreieckige Planken (wie in der Java Version) so in der Form nicht mehr geben :!: Denn dadurch, dass alle Blöcke skalierbar und frei beweglich und drehbar sind, decken sie quasi all diese Situationen bereits ab (statt einer Planke kann man zB einfach einen Block dünner skalieren). Die Trennung von Bauelementen (Planken) und Blöcken in der Java Version war eher suboptimal, daher war es unsere Intention, beides zusammenzuführen. Man wird dadurch einerseits weiterhin im "Minecraft-Stil" mit Blöcken bauen können (mitsamt Raster usw), aber diese Blöcke können jederzeit frei skaliert oder gedreht werden, und auch das Raster kann in der Größe verändert oder ganz ausgeschaltet werden, so wie Planken und Balken in der Java Version - man hat also die Vorteile aus beiden Welten.


    Was die Dreiecke angeht, diese gibt es in der neuen Version bereits als Blockform ^^ Auf dem Trello-Bild ist dieser Block zu sehen: https://trello-attachments.s3.…22f4924/constructions.jpg

    Und logischerweise wird auch dieses Dreieck (wie alle Blöcke) in alle Richtungen skalierbar sein.


    Kombiniert mit der oben erwähnten Funktion, die Oberseite eines Blockes separat zu verschieben, kann man aus dem gleichschenkligen Dreieck auch jederzeit ein rechtwinkliges Dreieck erzeugen (indem man einfach die Spitze nach links oder rechts bewegt).

    Thanks a lot for your feedback so far :) Obviously this isn't an easy decision and both approaches definitely have their pros and cons.


    Maybe have universal block for creative mode, and non-universal for survival?

    This feature definitely makes sense in creative mode, however, we're mainly looking for a solution in survival mode ^^ The Java version already had a few feature which worked fine in creative mode, but were extremely cumbersome in survival mode. We want to encourage people to create amazing buildings in survival mode too, without having too much trouble or quitting the game out of frustration...


    How about crafting/adding another work station called "A Recycler" so we can put anything that we don't want and get a % back of that material ???

    Having a recycler would be definitely a great addition, irrespective of how we handle the blocks (a recycler would be useful for all kind of items) :)


    Exactly. Convenient, simple. For creative i see the positive effect.


    For survival.. In that case we can get rid of most work benches. Why have a grinder? Just do it in inventory. Why have a spinning wheel? And so on

    It is our intention to find a good balance between realism and convenience ^^ But I'm not sure if this is really the same as removing all crafting stations and enable the player to craft items just from the inventory: Basically you still need a crafting station to turn your raw material into a processed element. E.g. turn wool into cloth, turn metal and wood into a tool, or turn stone or wood into a construction element (i.e. a block).


    With an undo option wrongly created things could be past.

    I'm not sure about an undo-feature for crafting :thinking: Having that for building (e.g. when accidentally removing a plank or object) may be helpful though...


    Basically i would skip the step to craft something. The block bench would be a useless step as it's just a passage from stone to block

    You still have to select the desired material / texture at the workbench - you just don't have to decide which shape you want to craft. It's like having a generic "construction element" which can be post-processed when placing it. Actually IRL you would also modify your construction elements while building: If you build a wooden cabin and find out the size of one of the planks don't fit, you would simply cut off the protruding part.


    I've also posted this already in the german topic, but I guess it makes sense to move this discussion to the english section as well :saint: If changing the shape of a block after crafting it is problematic, there is also another aspect that may cause trouble - the ability to change the size of a block while building. The new version enables you to resize any block while building without the need for special tools (just like the planks and beams in the Java version). Why am I able to enlarge a block to 3 times its original height and let's say 5% of its original thickness, but I'm unable to remove a part of it and turn it into a slope?


    Now one could argue that we could remove the resize-feature so people have to craft the correct size right at the workbench, but I guess that would be very cumbersome and frustrating :dizzy:


    We're also working on a feature which allows you to move the upper part of a block independently of the lower part. I don't want to promise too much, but for instance, you could just resize the upper part of a block to turn it into a square pyramid with the apex truncated. I've attached two images about that feature:


    This feature gives you a lot more possibilities when it comes to building, but you can only use it to its full potential if you can modify the block at any time (just like the ability to resize a block). This feature effectively also changes the shape of the block, so if I'm able to do that, why can't I just turn the block into a slope or cylinder :thinking:


    It would be a pity if this feature was only accessible in creative mode :(

    Erstmal vielen Dank für das bisherige Feedback :) Offensichtlich ist das Thema keine ganz so einfache Angelegenheit, und beide Ansätzen haben definitiv ihre Vor- und Nachteile.


    Insgesamt schreit es hier auch nach der Möglichkeit der Speicherung von eigenen Formen, es wäre Recht mühsam sich die Daten dann immer über ein Menü für ein simples Dreieck. Solche speicherungen wären aber so oder so sehr positiv.

    Wenn der "Multiblock" Einzug halten sollte, dann wäre es durchaus sinnvoll, dass die zuletzt gewählte Form für einen Stack gespeichert bleibt - damit ich schnell (ohne in irgendwelchen Menüs rumzufummeln) bspw. zwischen Blöcken und Treppen wechseln kann (angenommen ich hätte einen Stack Blöcke und einen Stack Treppen im Inventar).


    So gesehen ist der Multiblock also sehr vergleichbar mit dem klassischen Ansatz (separate Items), lediglich die Herstellung unterscheidet sich.


    Ich denke das ein universelles Bauelement nur was für den creativ Modus wäre

    Im Creative-Modus macht sowas durchaus Sinn, aber mir gehts bei dieser Entscheidung tatsächlich in erster Linie um den Survival-Modus ^^ Wir möchten sicherstellen, dass man auch Survival-Modus tolle Bauwerke erstellen kann.


    Wie soll das den jeweils Schritt für Schritt aussehen ?

    Folgendes Szenario: Ich möchte eine Plattform (aus Blöcken) mit abgeschrägten Ecken bauen, benötige dafür als Blöcke, Rampen und äußere Rampeneckblöcke.


    Variante 1: Klassischer Ansatz wie in Java

    Ich gehe zur Blockbank, suche die gewünschte Textur aus, und crafte die benötigte Anzahl an Blöcken. Dann wähle ich an der Werkbank die Rampe aus, und crafte die benötigte Anzahl an Rampen. Zum Schluss suche ich noch die Rampenecke raus und crafte sie ebenfalls. Habe dann 3 Stacks und verbaue sie. Wenn mir auffällt, dass noch was fehlt, gehe ich wieder zurück zur Blockbank und crafte weitere Elemente


    Variante 2: Multiblock mit änderbarer Form

    Ich gehe zur Blockbank, suche die gewünschte Textur aus, und crafte die insgesamt benötigte Anzahl an Blöcken (wäre dann eher als "Bauelement" zu titulieren). Ich bekomme entsprechend meinen Stack an "Bauelementen". Ich gehe dann zurück zur Baustelle, verbaue die Blöcke, danach wechsel ich die Blöcke (über ein Menü) in Rampen und verbaue die Rampen, zum Schluss wechsel ich die Form in "Rampenecken" und verbaue die Eckstücke. Alternativ: Ich teile meinen Block-Stack anfangs auf 3 Stacks auf und verwandel den 2. Stack direkt in Rampen und den 3. in Rampenblöcke.


    Wie intuitiv wäre denn die eine einzige Version für neue Spieler? Wenn ich mir vorstelle, als absoluter Neuling anzufangen, noch keinen Plan von der Steuerung habe, und mir eine erste kleine Hütte bauen will? Wie leicht oder schwer wäre das dann für mich?

    Das ist etwas schwer zu sagen... möglicherweise werden manche Spieler die Möglichkeit übersehen. Wobei man natürlich dazu sagen muss, dass es auch Spieler gab, die in der Java Version übersehen haben, dass man die Blockform ändern konnte :thinking: Vermutlich nehmen sich da beide Ansätze nicht viel :D Allerdings hätte man bei der Multiblock-Variante eher die Möglichkeit, die Funktion zum Ändern der Form hervorzuheben (wohingegen sowas im Crafting-Menü schneller untergehen könnte).


    Das Ändern an sich hingegen (wenn man die Funktion gefunden hat) wäre allerdings sehr einfach von der Steuerung her.


    Ich habe extreme Probleme mit der Mausrad-Benutzung. Es gibt 2-Tasten Mäuse die das Rad gar nicht haben

    Ich würde da das Mausrad vermutlich nicht bei involvieren. Sinnvoll wäre hier ja eine separate Taste (und optional auch die Möglichkeit, das per Rechtsklick im Inventar zu erledigen) womit ein Radial-Menü oder ein sonstiges Menü (zB wie die Pflanzenauswahl im Creative-Mode der Java Version, wenn man I drückt) aufgeht.


    Ich kann mich auch daran erinnern, dass es Spiele gibt mit einer Inventar Liste wo sich das gewünschte Teil frei wählbar ist. Minecraft Tekkit glaube ich.

    Das müsste ich mir mal genauer ansehen :thinking:


    um formen zu erstellen die es in der Auswahl nicht gibt. Stell mir da so was vor wie ein Hammer oder Säge. wo ich zb ein Brett an einer Kante abschrägen Kann in den Winkel wie ich ihn brauch. und zusätzlich einen Stempel oder oder Stanze wo ich Blöcke mit einen Loch ( egal welche form und Größe) ausstanzen kann

    Also das wäre an sich unabhängig von der Frage, ob Blockformen separate Items sein sollen oder nicht. Die Möglichkeit, dass man eigene, individuelle Blockformen selbst erstellen kann, ist momentan leider erstmal noch nicht vorgesehen. Das wäre zwar ein wirklich tolles Feature, die Umsetzung jedoch mit erheblichem Aufwand verbunden.


    Aber auch wenn vorgesehen sein soll, dass bestehende Formen nachträglich verändert werden können (zB beliebige Teile ausgestanzt werden sollen), würde das einige Probleme nach sich ziehen: Es müssten pro Bauteil deutlich mehr Informationen gespeichert werden, und auch die Generierung von Chunks mit Gebäuden würde länger dauern - besonders angesichts der Tatsache, dass in RW ja schnell mal mehrere Tausend oder gar Hunderttausend Bauteile verbaut werden :wat:


    Wird es die Möglichkeit geben über die Konsole weiterhin seine Rampe, Stairs usw. zu bekommen? Grundform +/- last position) ?

    Ja, wie oben erwähnt, können wir so einen Command auf jeden Fall anbieten :)


    Es wird so viel Wert auf immersion gelegt, mit den ganzen werkbänken, Arbeitsschritten, usw und hier will man einfach im Inventar ohne Werkzeug oder Bank aus einem z. B. Quadratischen Beton block ein Dreieck machen. Ich bin, ehrlich gesagt etwas überrascht von diesem Ansatz. Das macht doch das bauen im survival etwas beliebig.

    Ich kann das Argument auf jeden Fall nachvollziehen, Immersion ist uns auch durchaus wichtig, allerdings möchten wir ja trotzdem manche Dinge nicht unnötig verkomplizieren. Beim Bausystem bin ich ohnehin etwas skeptisch, ob hier wirklich ein hoher Grad an Immersion erreicht wird (auch schon in der Java Version) :thinking: Streng genommen müssten wir ja dann auch verhindern, dass Blöcke skaliert werden können: Der User müsste die gewünschte Größe dann schon im Vorfeld an der Werkbank festlegen. Das wäre deutlich realistischer, aber vmtl. auch ein vielfaches frustrierender und umständlicher =O


    Tatsächlich aber können Blöcke ja jederzeit größer und kleiner skaliert werden - immerhin auch ohne Werkzeug. Ich kann einen Block also während des Bauens durchaus 3x so hoch und nur 5% so dick wie vorher machen. Warum kann ich ihn dann nicht auch abschrägen und zu einer Rampe machen?


    Es gibt aber auch ein weiteres Feature, an welchem wir arbeiten, was mit strikten Trennungen der Blockformen kollidiert: Die Möglichkeit, bei Blöcken bspw. die Oberseite unabhängig von der Unterseite zu bewegen oder zu skalieren. Ich will zu diesem Feature zwar noch nicht zu viel versprechen, aber ich habe von einem derart bearbeiteten Block mal zwei Bilder gemacht:


    Dieses Feature eröffnet völlig neue Baumöglichkeiten. Aber auch das müsste (genau wie die allgemeine Blockgröße) idealerweise jederzeit anpassbar sein, nicht nur an der Werkbank, sonst geht ein großer Teil des Nutzens wieder verloren. Spätestens mit diesem Feature müsste man sich ja berechtigterweise die Frage stellen, warum ich sowas machen könnte (was ja effektiv auch quasi die Form des Blockes ändert), aber nicht zu einer Rampe oder Zylinder wechseln kann :thinking:


    Man könnte vielleicht argumentieren, dass dieses Feature (sowie auch die Größenanpassungen von Blöcken) nur mit einem bestimmten Werkzeug möglich werden, aber dann befürchte ich, dass das ein nicht unwesentlicher Teil der Spieler niemals herausfinden wird und das Bausystem nur zu einem Bruchteil auskostet :(


    Die Sache ist also gar nicht so einfach :D


    ich würde es schön finden wenn die 2 formen auch den weg ins spiel finden würden
    eine kegel und ein halbe kegel

    Das kann ich auf jeden Fall auf die Todo-Liste packen :) Der große Vorteil ist, dass wir in der neuen Version jederzeit neue Blockformen hinzufügen können, ohne, dass alte Welten in Mitleidenschaft gezogen werden.

    Könnte man auch halb kreise machen die von innen leer sind und somit eine regenrinne ensteht, die eventuell auch wirklich funktioniert mit dem kommenden wasser update? and good job looks nice :thumbup:

    Wie Avanar schon sagt, leider wird das Wasser nicht diesen Detailgrad haben beim Fließen :silenced: Aus Performancesicht ist das technisch einfach nicht möglich, zumindest nicht im größeren Maßstab. Richtig physikalisches Wasser, bei welchem quasi jeder Tropfen simuliert wird, ist zwar heutzutage im kleinen Stil bereits möglich (wenn man bspw. ein kleines Becken oder so hat, oder als visueller Effekt beim Auskippen eines Eimers), aber wir müssen bei RW das System ja so auslegen, dass es auch funktioniert, wenn wir einen ganzen See oder komplexe Flüsse oder so haben. Hinzu kommt ja auch die Möglichkeit, dass sich unter einem See bspw. ein komplexes Höhlensystem befinden könnte, welches beim Umgraben des Sees geflutet wird.


    Das nächste Problem wäre hier auch der Multiplayer, denn das Wasser müsste ja korrekt synchronisiert werden (und unabhängig davon auch persistent in der Welt gespeichert werden). Selbst wenn wir relativ große Wassertropfen verwenden (zB mit einem Durchmesser von 5 cm, was für eine Regenrinne wohl schon fast zu groß wäre), würde ein größerer See locker aus Milliarden oder gar Billionen solcher Tropfen bestehen, was beim Synchronisieren und auch beim Abspeichern der Welt - trotz Kompression - schnell in den Terabyte-Bereiche gehen würde :dizzy:

    Wurden hier die Formkosten berücksichtigt? Denn beim universellen Ansatz wäre es ein wenig schade, wenn man einen ganzen Block verbraucht, obwohl man nur z. B. einen Kegel platziert hat. Theoretisch könnte man hier pro Form verschiedene "Kosten" haben, die dann vom Stack abgezogen werden, aber dann wäre eine Stackgröße nicht mehr im natürlichen, sondern im reelen Zahlenbereich.

    Schwierig... wir arbeiten bei den Stacks ja nur mit ganzen Zahlen, da wäre es kompliziert, bspw. nur einen halben Block abzuziehen wenn zB eine Rampe o.ä. platziert wird :thinking: Ich weiß auch nicht, ob es "schön" wäre, wenn Blockstacks alternativ als Kommazahl dargestellt werden: Man hätte zB 100.0 Blöcke in der Hand und nach dem Platzieren wären noch 99.25 Blöcke übrig :wat:


    Das Problem besteht aber mehr oder weniger unabhängig von der Entscheidung, ob es verschiedene Items oder ein universelles Item gibt, denn auch in der Java Version hatten die verschiedenen Blockformen (die ja als separate Items behandelt wurden) ja bereits die gleichen Resourcen gekostet wie der Standard-Block.


    Was man aber evtl. machen könnte wäre groß skalierte Blöcke teurer machen. Sprich wenn ich einen riesigen Block mit der Größe 4x4 platziere, dann würde er 16 Blöcke vom Stack abziehen. In der Java Version gab es da ja ebenfalls keine Berücksichtigung (eine Mini-Planke war genauso teuer wie eine große Planke), und tatsächlich ist die Sache nicht ganz so trivial, da es beim Platzieren für den User ja auch irgendwie ersichtlich sein müsste, wie teuer das ganze wird... wir müssen uns hier mal Gedanken machen :nerd:


    Verschiedene Formen in einem Item kenne ich aus diversen anderen Spielen. Ich habe das immer verflucht, da das Handling meistens sehr seltsam und extrem umständlich war. Raft, Empyrion, Conan glaube ich und gewisse Spiele bei denen irgendein Kreissegment herumgedreht werden muss, um eine Auswahl zu treffen. Sehr umständlich, meiner Meinung nach.

    Am intuitivsten wäre vmtl. tatsächlich ein Radial-Menü (quasi die selbe Art an Menü die wir auch für unsere Türen in der neuen Version verwenden). Optional könnten wir auch zusätzlich einen Command dafür anbieten. Wie gesagt, das Spiel könnte auch die letzte Blockform für den gewählten Stack abspeichern, sodass man es nur 1x ändern muss (pro Stack).


    Aber ist es denn unabhängig davon wirklich einfacher, im Crafting-Menü bis zur entsprechenden Blockform (waren ja zuvor die Pfeile links und rechts neben dem Block) durchzuklicken? Zumal sich manche Formen ja auch teilweise etwas ähneln.

    Und auch beim Einlagern werden die Kisten schnell voll: Ich habe anbei mal ein Bild aus der Java Version von einer Kiste angefügt, in welchem sich fast alle Blockformen in gerade mal 4 verschiedenen Texturen befinden. Obwohl es nur 4 versch. Texturen sind, ist die erste Seite schon voll :thinking: Und dabei fehlten in der Java Version ja noch jede Menge Formen...

    Ist das etwa eine Sternform, bei der man die Zacken (und deren Tiefe) einstellen kann?

    Hehe, naja, dieser Grad an Einstellmöglichkeiten ist momentan leider noch nicht drin :saint: Man kann Elemente zwar wie auch in der Java Version in alle Richtungen vergrößern oder verkleinern, aber nicht direkt ihre Struktur ändern (also bspw. nur einzelne Teile des Elements skalieren).

    Wie auf dem Bild zu sehen wird es ja bspw. auch "hohle Zylinder" (passend für Röhren) geben, aber es gibt leider noch keinen Weg, die Wandstärke zu ändern (das fällt quasi in die gleiche Kategorie wie die Tiefe der Zacken bei der Sternenform zu ändern).


    Vielleicht kommt diese Funktion aber noch rechtzeitig fürs kommende Update hinein.


    Nichtsdestotrotz werden beide Elemente trotzdem schonmal verfügbar sein (lieber haben als brauchen) ;) Die Sternenform könnte sich in der jetzigen Form vll für geriffelte Säulen anbieten (natürlich mit anderer Textur).


    Wir sind aber übrigens auch für alle möglichen Wünsche was neue Formen usw. angeht offen. Die neue Version hat - anders als die Java Version - quasi keine Beschränkungen mehr was die maximale Anzahl an Blockformen angeht. Und wir können auch jederzeit neue Formen hinzufügen, ohne, dass es für alte Welten Probleme gibt.