Posts by red51

    Actually we need a better implementation of the cloud saving. There is only a limited filespace available per user, so we have to be careful about what we store. Since some people have several worlds with loads of images, this may exceed their cloud storage.
    Once we have more time, we will give the user more control about the cloud saving, i.e. he can determine which worlds he wants to store in the cloud (and also determine if images should be stored as well or not).


    However, changing the way how missing images are displayed is on our list ;) So proabably there will be just an "N/A" image or something like that

    This is more or less the way I have taken: I sub-class GuiPanel (the nearest type among the ones existing) to add specific child elements with specific relationships among them. A show(player) method adds the GuiPanel directly via Player.addGuiElement() and, in addition, a loop adds each child, again via Player.addGuiElement().

    This sounds like a good approach. Maybe we can also add a protected "onAttach()" method (or something like that) which will be called once a gui element is added to the player screen. If you sub-class a GuiPanel then, for example, you could just override this method, and add all childs via Player.addGuiElement() (so it wouldn't be necessary to call a specific method like show())

    Well, this doesn't work unfortunately. If you try to add a custom GuiElement to the player screen (or what's the reason behind sub-classing the GuiElement class?), the client doesn't know how to display it. Currently every API GuiElement is covered by a "real" element in our underlying gui, so if you create a custom GuiElement in your plugin, the client doesn't know what to do


    It's more preferable if you just create a regular class which consists of your particular GuiElements. Instead of adding it to the player gui directly (by calling Player.addGuiElement()), you might add a method to your gui class instead (something like "addToPlayerGui(Player)" for example) which adds the particular gui elements manually.

    Basically we wanted to cover the case that there might be a gui element in the future which isn't clickable. So currently every gui element which is supposed to be clickable has to override these methods and expose them to the public API.
    If we come to a point that we find out that there will be no gui element without the clickable-functionality, we might change this^^

    Also es gibt keine grossen freien flächen, klar kann man mit allen mögliche Seeds versuchen

    Das ist wahr. Das wird sich im Laufe der Zeit auch nochmal etwas ändern. Komplett freie Flächen wird es vermutlich aber tendenziell weniger geben (realistisch betrachtet müsste in einer unberührten Welt fast überall Wald sein, aber ich denke es macht Sinn, wenn es größere Flächen gibt auf denen nur vereinzelt ein paar Büsche stehen o.ä)


    Mir wäre es aber lieber, wenn man die Umgebungsvariablen näher bestimmen könnte. Also wieviele Bäume auf einer bestimmten Umkreis geben soll, wieviel Wasser die Welt enthalten soll usw.

    Das ist auf jeden Fall geplant. Sowas erfordert leider viel Feintuning, sodass wir uns diesem Thema immer nur schrittweise nähern. Insbesondere Einstellmöglichkeiten, wieviel Wasser (bzw. ob überhaupt) vorhanden sein soll, und auch Einstellungen hinsichtlich der Biome (vor allem auch die Möglichkeit, ein Startbiom auswählen zu können) wären wichtig.


    nur wenn man fast bei jeden neu erstellten Welt in einem Wald oder gar hoch oben auf einen Berg landet ist das nicht grade motivierend

    Zumindestens das "auf einer Bergspitze spawnen" ist etwas suboptimal, das wird noch geändert ;)


    Schöne Seedübersichten gibt es auch nicht

    Es kursieren zwar ein paar Seeds im Forum, leider muss man aber auch berücksichtigen, dass alte Seeds nicht mehr zwangsläufig die selbe Welt ausspucken, nachdem durch irgendwelche Updates die Weltgenerierung verändert wurde (bspw. führt ein Seed von vor den Biomen nun zu einer ganz anderen Welt).


    Wenn ich mir verschiedene Maps ansehe, war das vor dem Wasserupdate nicht so extrem.

    Das Wasserupdate hat an den bestehenden Biomen eigentlich nichts geändert. Einziger Unterschied sind Seen, welche ja in einem regulären Biom spawnen können, und dort dafür sorgen, dass das Terrain generell abschüssiger wird (damit die "Grube" effektiv mit Wasser gefüllt werden kann). Hier findet sich also grundsätzlich sehr unebenes Terrain. Aber wie gesagt, normale Wälder oder Wiesen sind nicht betroffen.


    I think everybody (the dev team included) will agree that the survival aspects of RW are yet under-developed and so far the focus has been on creation / construction. This may change in the future, as the game still has a long way to go.

    100% agree. Although it's our intention to focus more on survial and exploration aspects (especially the introduction of the new playermodels will be an important foundation for survival)


    I suspect however that the two perspectives (creative and survival) are very hard (almost impossible?) to fully develop both in the same context

    Well, of course one could probably never compare this game to some "pure" survival games (like Rust, DayZ etc), or more precisely, to those games which fully concentrate on survival. If this was our intention, we wouldn't have "wasted" time and resources in creating a procedural voxel terrain :D But on the other hand, there are definitely a lot of possibilities in terms of survival, especially when talking about a "more challenging" gameplay :)


    The voxel concept upon which RW is based, for all its advantages, also has disadvantages: flat is totally flat, the minimum difference in level is one block, the only possible continuous slope is 45° and so on. Natural terrain characteristics are rather different.

    This is true. This is probably the biggest limitation about the terrain. Although it would be possible to use data grid with a higher precision (some very few other games do that), this would result in a higher memory consumption, and the game would have to process more polygons. We already put these resources in things like the construction system (i.e. building with planks etc), I'm afraid having a more precise terrain in combination with extensive buildings (some users create buildings consisting of tens or hundreds of thousands of construction elements =O ) might end up in an unplayable state...
    However, once the game is in beta, we want to do some tweaks to the terrain ^^


    Every lake, beach is unven, terrible

    That's basically intended, in order to make sure the water doesn't flood adjacent areas

    Das Dungeonupdate (welches auch ein paar andere Dinge mit sich bringt) wird nicht mehr lange auf sich warten lassen, einen genauen Termin nenne ich lieber nicht, aber vorher werden keine anderen Updates mehr erscheinen, d.h. die Dungeons kommen als nächstes ;)

    Bitte nur 1 Thread erzeugen, mehrere Beiträge bzgl. der gleichen Thematik führen nur zur Unübersichtlichkeit im Forum ;)


    Verwendest du die Steamversion? Benutzt du ein 32 oder 64 Bit Betriebssystem? Befindet sich im Spielverzeichnis eine Datei mit dem Namen "errorlog" oder "hs_err_pid"? Was für eine CPU, und was für eine Grafikkarte verwendest du?

    You can find all items in the definitions database of the game. Just open the "commons.jar" in your data subfolder with a zip program (e.g. WinRar), navigate into the commons/definitions subfolder, there you find a file called "definitions.db". You can extract this file and open it with an SQL editor (e.g. Navicat). Inside this database file you find a table called "Items", this table contains all items with their according id.
    About the variation, basically it's just relevant for blocks or construction elements (determining the texture).


    Alternatively here is an overview of the current items in the game:

    1) Assumption: as far as I can tell, plug-in ID's are always sequential, i.e. in increasing order and without 'holes'. Can this be documented and 'cast in stone'?

    Yes, that's basically true. Unless an unexpected error occurs when loading a plugin, there shouldn't be any "holes".


    if "reloadplugins" has been used (and possibly under other circumstances too), plug-in ID's may start with any integer

    That's also true. There is an internal counter which does not get reset to 0 when reloading the plugins. So if 10 plugins are loading (using id 0 to 9), and you use the "reloadplugins" command, the first plugin will have id 10, the 2nd plugin id 11 etc.


    it would be nice however if the process could be streamlined somewhat, for instance by providing a Plugin.getAllPlugins() method returning an array (or ListArray or whatever) of all installed plug-ins.

    Yes, that makes sense. This method will be added with the next update ;)

    Bleibt das Loch auch nach einem Reconnect bestehen, bzw. auch wenn der direkt die Kante zum fehlenden Chunk bearbeitet wird (oder F10 im Creativemodus verwendet wird)?


    Wegen dem Gras, hat dein Kollege ggf. in den Einstellungen "Grasverdeckung" ausgeschaltet? Beim Platzieren von Blockreihen oder von Construction Elementen (Planken etc) wird Gras nicht entfernt, sondern lediglich davon verdeckt - sofern diese Option aktiv ist. Leider erfordert das Aktivieren dieser Einstellung (also falls sie zuvor deaktiviert war) momentan einen Spielneustart.

    Während setp die Positionspräzision und setr die Rotationspräzision einstellen, kann mit setl die Präzision beim Skalieren (also Vergrößern oder Verkleinern) eingestellt werden.
    Mit savep/saver/savel wird die aktuell eingestellte Positions-/Rotations-/Skalierungspräzision dauerhaft gespeichert, bleibt also auch nach einem Neustart aktiv. Mit resetp/resetr/resetl kann der gespeicherte Wert wieder auf den Standardwert zurückgesetzt werden, allerdings wird der aktuell eingestellte Wert dadurch nicht zurückgesetzt (d.h. man sieht diese Änderung erst nach einem Spielneustart)... das könnte man ggf. ändern ;)


    Generell sind diese ganzen Befehle eher als "Workaround" gedacht. Nachdem das Bausystem überarbeitet wurde, wird man sowas direkt über eine GUI einstellen können (natürlich werden die Befehle aber weiterhin vorhanden bleiben).

    Yes, that's true. Someone else also mentioned this issue some while ago. The next update will introduce a Player.deleteAttribute(String key) method which allows you to remove an attribute :)

    Well, actually the Areas are causing some problems. There is still some debug code left which causes various issues in certain cases, that will be fixed with the next update.
    However, this isn't related to your problem. Using sub-classes of Area causes trouble, since the "equals()" method in Area doesn't check if the other object is an instance of Area (it only compares the classes, so the sub-class isn't considered to be an Area). This will be changed with the next update ;)