Posts by red51

Hmm yeah the dungeons will be indeed a problem for the "findbase" command, since dungeons just consist of regular blocks, construction elements, objects etc. Although dungeons never consist of very much blocks or construction elements per chunk, so unless you just had a small base, I guess it's still possible to find it with the "findbase" command.
Nevertheless, I guess it makes sense to modify the findbase command a little bit, so you can look for certain objects, for example.

But something like " ownership" of objects is planned, this would be quite useful for stuff like the AreaProtection script/plugin, for example

Well, converting a resource to a file is tricky. Basically the file doesn't really exist, since it's part of the jar (the OS treats the jar as a single file).
Usually you would load a resource by using the getResourceAsStream(), which returns an InputStream. However, unfortunately there is currently no way to turn it into an "ImageInformation" or "ModelInformation" object (well, ofc you could store your resource as a file, and then load the file, but that's crap).

I guess we will add a new constructor to ImageInformation/ModelInformation which accepts an InputStream. Maybe we will also add a convenient way to load a resource directly. I hope we get that ready for the next update

Das hat mich in den letzten Tagen auch genervt Wird geändert!

Well, the server performance doesn't suffer very much from posters. Only thing you have to keep in mind is the used bandwith when a client downloads an image. A client only downloads images which are in his proximity, and only if there isn't already a cached version of the image in his game directory.

However, when it comes to the clientside performance, things are getting more critical: Basically every "visible" image has to be loaded into the player's RAM (direct memory) and VRAM. If there are too many different images close to each other, some players (who don't have that much RAM) may run out of memory. Here it's important to limit the maximum image size per user (you can do that in the permissions). You have to keep in mind that a 1024x1024 px image consumes 4 times more memory than a 512x512 image, for example. So having many small images isn't a big deal (e.g. having 1000 32x32 px images consumes less memory than a single 1024x1024 px image), but it becomes a problem when using many big images.

To cut a long story short: Don't worry too much about posters, it really depends on where those images were placed (if a player has a lonely house far away from everything else it's really not a problem when he uses many images), and also the max image size matters.

Btw, the file size on your harddrive does only matter when it comes to the bandwith. When loading an image into memory, we can't use compression yet (due to patent reasons), so the memory consumption per images is much higher than the actual file size (it's basically like storing a .bmp image).

Sorry for my late response! We did not release any updates recently, so maybe it was just Steam updating some dependencies or whatever

I would just like to mention that you always have to be careful about the reloadplugins command. Unloading and reloading classes during runtime is definitely not intended in Java, so there is always a chance that this leads to strange behaviour. Basically this command is mainly there for having an easy way to test plugins without the need to restart the game/server.

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

Quote from Miwarre

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

Quote from Bogus

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

Quote from Bogus

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.

Quote from Bogus

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

Quote from Deirdre

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

Quote from Deirdre

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.

Quote from Miwarre

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)

Quote from Miwarre

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 But on the other hand, there are definitely a lot of possibilities in terms of survival, especially when talking about a "more challenging" gameplay

Quote from Miwarre

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 ) might end up in an unplayable state...
However, once the game is in beta, we want to do some tweaks to the terrain

Quote from Deirdre

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

Bzgl. dieses Fehlers könntest du mal probieren, in der "config.properties" Datei den Wert "game_threaded_loading" auf false zu ändern, und prüfen, ob der Absturz weiterhin auftritt (allerdings wird durch diese Änderung der Spielstart verlangsamt)

Ich weiß leider noch nicht ganz genau, was das eigentliche Problem ist Was meinst du mit "automatisch hinfliegen"? Bewegt sich die Spielerfigur selbständig? Handelt es sich dabei um Änderungen der Blickrichtung, und/oder um Änderungen der Position?

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:

Automatisches Fliegen?

Quote from Miwarre

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

Quote from Miwarre

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.

Quote from Miwarre

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

As @PhartBlast mentioned, you can't play the Steam-version of the game without Steam, only the standalone.

About the issue you're having, please post the full log.

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.