Beschränkt sich das immer auf einen Sektor oder kann man auf der Karte auch z. B. angrenzende Sektoren/Inseln sehen?
Aktuell ist es immernoch auf den jeweiligen Sektor beschränkt. Möglich ist aber definitiv auch angrenzende Sektoren anzuzeigen (und auch geplant), aber ich weiß leider noch nicht, ob das zum Update noch rechtzeitig reinkommt 
game is russian how to change english
The game does not support Russian (only English and German are supported atm), so if it's Russian in your case, it looks like you've installed an unofficial language pack (i.e. replaced or added new language files).
If you've modified existing game files, you can revert to the original state if you verify the integrity of the game cache in Steam: https://help.steampowered.com/…/view/0C48-FCBD-DA71-93EB
If you've added new language files, you can simply delete them. If you play the Java version, the language files are stored in the risingworld-core.jar in the "data" folder (so to fix this, just verify the game files, as mentioned above).
If you play the new version, the language files are located in the "_New Version/Data/StreamingAssets/Languages" folder (each language has a separate .json file there).
Thanks for your feedback! 
The only thing I would say is the wolves still need a bit of work on the look, especially around the face, the fur isn't quite poofy enough it looks like fur textured skin more than fur. It's hard to balance look and performance for lower end machines so not that bit of a deal.
Basically the wolves are as fluffy (or not fluffy) as the other animals 
Right now the game doesn't render any fur specifically (mostly for reasons of performance), except for the lion (but it only uses very basic fur).
Having said that, we've done some preparations for better fur rendering in general, while still keeping an eye on performance. We don't have an ETA yet, but once it's ready, it will make most animals more fluffy (please bear in mind that this is still work-in-progress and only provides a basic fur rendering - fully fledged fur rendering is not possible without killing the performance unfortunately) 
I don't see any of those other than the wolves O.o
Here you can see the latest additions Activity List
When saving a blueprint, the save-request is sent to the server first (in multiplayer). The server then decides whether or not the player is allowed to create the blueprint, which elements are to be included etc, and send this back to the client - then the save indicator goes away and a save dialog shows up where you provide the name etc for the blueprint (only then the blueprint is actually stored on your hard drive).
If the save indicator does not go away, it indicates that the client didn't receive a response from the server (or something else went wrong) 
A report would be indeed helpful to find out what's going on there (as mentioned by Deirdre )
Nein, es wird leider erstmal kein Satellitenbild o.ä geben. So schade das auch ist, es ist technisch leider in Unitys HDRP momentan im Grunde nicht so einfach möglich, sowas performant umzusetzen 
Anders als in der Java Version haben wir nicht genug Kontrolle darüber, wie die Szene gerendert werden soll. Darüberhinaus hat explizit die HDRP die nervige Einschränkung, dass ein Rendern der Szene von einer anderen Position als der Spielerposition aus exorbitant teuer ist.
Bei der Karte beschränken wir uns daher erstmal auf die Kernfunktion, die eine Karte erfüllen soll - nämlich in erster Linie ein Navigationswerkzeug zu sein. Viele Spieler haben derzeit Schwierigkeiten mit der Orientierung, d.h. sich auf der Insel zurechtzufinden, ihr Lager wiederzufinden usw. Dieses Problem soll mit der Karte vorrangig gelöst werden.
Anders als in der Java Version wird die Karte nicht mehr gerendert, sondern anhand der Terraindaten generiert. Bei so einem Ansatz ist es quasi unmöglich, Gebäude zu inkludieren (da jedes Bauteil eine beliebige Größe und Drehung haben kann, kann es im Grunde nicht rasterisiert werden, zumindest nicht in einem performancetechnisch akzeptablen Rahmen). Der Vorteil ist aber, dass dadurch die gesamte Insel dargestellt werden kann (und anders als in der Java Version nicht immer nur ein recht kleiner Teil aufgedeckt wird).
Auch wenn dir die Lösung nicht reicht, wie gesagt, leider gibt es momentan keine Alternative. Technisch sind wir da durch die HDRP zu eingeschränkt. Uns sind die Hände leider gebunden. Das heißt aber nicht, dass sich das niemals ändern wird: Wenn es in der HDRP entweder mal mehr Kontrolle über sowas geben sollte, oder wir auf eine andere Render-Pipeline umsteigen, können wir auch durchaus wieder eine Map wie in der Java Version anbieten (wahrscheinlich würde die Karte in ihrer jetzigen Form aber bleiben, stattdessen würde dann zusätzlich ein GPS-Gerät o.ä. hinzukommen, mit welchem man so ein Satellitenbild anzigen könnte).
Hey red51, I left you a private message, and I have some little suggestions that I like to suggest you, if you want it... Or you are very busy now with the incoming update? Should il wait better?
Hey, sorry for not responding to the private message yet The update indeed kept me a quite busy the last weeks... I'll get back to you later (at the latest when the update is ready)
Tolle Bilder von den Segelboot und den Wölfen.
Danke für das Feedback
Dark Megatron Ja stimmt sieht gut aus, außer die Frau die sieht eher wie ein Mann aus da ist noch Luft nach oben .
Aber vielleicht sieht sie nur auf dem Bild etwas unvorteilhaft aus
Es ist eine Mischung aus beidem Etwas Luft nach oben ist da tatsächlich noch, es sieht aber auf dem Bild auch etwas unvorteilhaft aus 
Es ist aber auch auf anderen Bildern so, dass dann irgendwas anderes unpassend wirkt (entweder die Augen sind komisch, irgendwas wirkt schief usw)...
Ich kann aber sagen, dass es im fertig Update weniger problematisch aussehen wird 
Can you identify a door exactly or is it just by raycast layers? Either will work for what I am experimenting with.
You mean through the Plugin API? If you have an ObjectElement instance, you can get the definition from it via getDefinition() and check if the type is Type.Door. If you're working with events (e.g. if the player interacts with the object), the object events already have a getObject() method to get the according ObjectElement instance directly.
But of course you can also get the object from a raycast. The code to get an object via raycast and check if it's a door could look like this:
Is there an ID or Type where I can detect door objects in the databases?
Where do you want to detect them specifically? In the definitions.db database? Or the world database files?
In the definitions database, there is a "type" column in the objects table which is Door for every door object.
In the world databases (i.e the files stored in your world folder), however, you cannot access this data easily. The game serializes and compresses all objects in a chunk, so they're stored as a non-human-readable blob (binary data).
Usually it's better to use the Plugin API for this.
Nachtrag: Es macht ja wahrscheinlich Sinn, sowas separat pro Npc zu steuern? Während ich zwar noch nicht sagen kann, wann eine allgemeine Steuerung bzw. die Möglichkeit, Definitions zu überschreiben, reinkommt, könnten wir zumindest mit dem nächsten Update einbauen, dass das Behaviour (und ggf. die AttackReaction) pro Npc gesetzt werden kann
While furnaces aren't really implemented in the API they do put quite some information to the logfile. Interestingly this information seems to be enough to do a rudimentary smelting skill.
That's a very creative solution 
There is only one small pitfall: the "Player.log" file is only used in singleplayer. The log file for the dedicated server looks a bit different instead, using the current date and time as file name (called "2024-05-13-12-15-51.log", for example)...
However, we could add a new API method Server.getLogFilePath() with the next update which always provides the full path to the current log file^^
FurnaceOutOfFuel
I'd probably prefer to keep this a bit more generic, and since furnaces are treated as MetaObjects by the game, a MetaObjectStatusChangeEvent would be more suitable maybe?
FurnaceOreSmeltingComplete
Basically the Java version had an ItemTransformEvent for this (called per item which "transforms" to another item, e.g. ores getting smelted etc). Actually this event is also in the new version, but it's not exposed to the API yet... we're not sure about the naming convention, since the name isn't intuitive and could be misleading. Maybe it's better if we call it "ItemProcessEvent" instead (called everytime a world item changes, e.g. ores getting smelted, items getting crushed in the grinder etc)? On the other hand, we already have an NpcTransformEvent, so maybe it's better if we stick to that naming convention? IDK...
hmmm I guess the "empty" item i had was invalid. what about rising an exception if someone calls a function if an invalid item? getTypeID()
We could add that with the next update
I guess that's a good idea but when trying to add clothing or construction i realized there's stuff like color or texture required too. I was to lazy to check but I have a feeling I would have to read that one from the item in the event and then use it later.
The addItem() method already has a "variant" parameter (which would also work for clothes or objects). In case of construction elements, the variant is just the texture - so this would also be covered by a generic addItem() method which takes a string.
Setting colors, however, isn't possible that way. But we could "fix" that by adding a setColor() method to the according item instances, i.e Item.ConstructionItem etc
Maybe instead of using the name, the onPlayerCraftItemEvent could get something like an extended recipe which contains not only the recipe definition but also all those additional parameters. If this full definition was a pure java object and could be arbitrarily stored it could be used at any time to create that object.
I'm not sure about that... it wouldn't be connected with the implementation on native side Right now all definitions on Java side are generated automatically (based on the native definitions), because maintaining them manually would be a lot of work (and also quite error prone).
Basically all definitions (including recipes) are intended to be generic and universally valid (i.e. not bound to a particular crafting action), so it never contains individual parameters (like the amount of items the player wants to craft or the optional color he defined)...
Ich packe das mal auf unsere Liste Momentan wäre sonst aber als Workaround ggf. auch ein Poster verwendbar dafür, oder?
Unfortunately this is indeed a bug But it will be fixed with the next update
1) you cant save the item provided in the event. start a timer and get the item back in the timer callback. While the object stored is still an item it seems to be empty at that point in time.
Basically you can do that, but if you cache the item and use it at a later stage, make sure the item is still valid then (i.e. make sure the item hasn't been removed or disposed in the meantime). To do that, you can call item.isValid()
While I do understand that this is a result from how the data is structured in the game, IMHO for the api this is WAY to complicated
As mentioned above, determining which item you have to add to the inventory based on a recipe is indeed a bit tricky, but a generic addItem() method which simply takes a String would definitely simplify this (you'll only need to pass recipe.name to the method then, without having to determine the recipe type)
Yes, if you want to change the permission group after a certain amount of time, you have to use a plugin for that. Unfortunately the scheduler isn't capable to do that atm: the time intervals aren't bound to a player, for example, so they're not suitable to determine the total play time. Also, the scheduler doesn't support any kind of branching, so it doesn't provide enough control to achieve that Basically the scheduler is mainly intended to perform generic tasks (e.g. send messages to player, handle server restarts, change the ingame time or weather etc).
I don't know if i missed it, but can someone tell me if this plugin works fir the current version of unity please?
Unfortunately plugins for the Java version need to be recompiled for the new version... and depending on how the plugin was made, it may also require some minor changes (this topic contains an overview of the differences for plugin creators). So unless the plugin creator posted an updated plugin for the new version specifically, it won't work unfortunately
Yet that's not that much helpfull in my case as I want to create a generic wrapper which basicaly replaces the in game crafting. You might ask why I'd like to do that, to me the instantaneous crafting just doesn't feel right so I tried to create a short delay by aborting the original craft, start a timer, fill a progress bar and once a certain time has passed add the craft result to the player inventory ;-).
You could grab the item from the PlayerCraftItemEvent and check what item it is, similar to how james1bow suggested above, e.g. like this:
System.out.println("Player crafted construction element: " + construction.getConstructionName()); //prints "block", for example
System.out.println("Player crafted object: " + object.getObjectName()); //prints "workbench", for example
System.out.println("Player crafted clothing item: " + clothing.getClothingName()); //prints "mininghelmet", for example
System.out.println("Player crafted blueprint: " + blueprint.getBlueprintName()); //prints "My summer house", for example
first, there's no object definition for a primitive workbench but a item definition so using this as criteria to choose between addItem and addObjectItem doesn't work.
Primitive workbenches are objects, so they're represented by an ObjectDefinition. However, crafting recipes never store object definitions, they only store item definitions. In case of the workbench, the item definition references the generic "objectkit" item - this is how most objects are represented in inventory. Similar to the generic "constructionitem", which represents almost all construction elements, or the generic "clothingitem", which represented all types of clothes.
But getting the correct item from a Recipe is indeed a bit tricky... internally the game stores some meta data (to determine the type of item) which is unfortunately not accessible by the API... what you could do is to check the RecipeType: If it's RecipeType.Object, you can use the recipe name to get an ObjectDefinition. If it's RecipeType.Clothing, use the recipe name to get a ClothingDefinition. If it's RecipeType.Block or RecipeType.Construction, you can get a ConstructionDefinition from the name. Else it's a regular item (where you can use the name to get an ItemDefinition).
But if you're still inside the PlayerCraftItemEvent, it's still better to check the actual item instance (as mentioned above)
Having said that, I think it would be useful if we add a new addItem() method which just takes a String. There you could just provide the target item/object name and the game would automatically determine the type of item it has to add (this would work for items, but also for objects, clothes, construction elements etc)
on the way I discovered a further issue, how to add a blueprint item to the inventory?
Unfortunately there is no method to add a blueprint to the inventory yet (because there was little use for such a method yet, since a client could only use his local blueprints anyway). But I can put this on our to do list
does tell true for both a workbench as well as for lumber.
Hmm... that's not supposed to happen 
The condition if (item instanceof Item.ObjectItem object) should only be true for the workbench in this case, not for lumber. Are you sure it's true for lumber? Unfortunately I wasn't able to reproduce this on my end If you use the code above for the PlayerCraftItemEvent, the output for lumber should be "Player crafted regular item: lumber"
Basically it already works like that (more or less) The game distinguishes between regular items (tools, weapons, food etc, basically everything that's solely used in inventory), objects (furniture, workbenches, doors, lamps), construction items (blocks) and clothing items.
The addItem method is relevant for all regular items, i.e. all items which are represented by an ItemDefinition. In this case, the itemID is always the ID of the definition:
Objects (like the workbench) don't have an item definition (internally objects in inventory are almost always represented by a generic "objectkit" item which contains additional information to determine the actual object). If you write Definitions.getItemDefinition("workbench");, null is returned (because there is no item that is called "workbench", and the game does not have an ItemDefinition for this object).
Objects are represented by ObjectDefinitions instead: to add an object (furniture, workbenches, doors, lamps etc) to the inventory, you have to use the addObjectItem method instead:
Clothes and construction items (blocks) use ClothingDefinitions and ConstructionDefinitions accordingly.
To find out if you need to get an ObjectDefinition or ItemDefinition etc, you can use the description above as a rule of thumb (tools/weapons => item, furniture/workbenches => object etc). Alternatively you can take a look at the definitions.db file (in the game directory under Data/StreamingAssets/) , which contains all definitions. To open the file, you'll need an SQLite browser (like DB Browser or Navicat). Everything that's stored in the items table is represented by an ItemDefinition, everything that's stored in the objects table is represented by an ObjectDefinition, everything that's stored in the constructions table is represented by a ConstructionDefinition and everything in the clothes table is represented by a ClothingDefinition
Unfortunately the LOD surface level indeed does not take caves into account yet Usually it's not a big problem (because there shouldn't be many steep caves near the surface), however, there is indeed always a hard-coded steep cave at the center of each island (which goes down straight to hell). Originally we've added it for testing purposes, but decided to keep it in the game for the biomes&caves update. Maybe we will remove it in the future.
Unfortunately I can't give an ETA when caves will be taken into account for the LOD surface level, however, a workaround would be to take this particular cave into account when teleporting to the center of an island. It has always the same layout. It's definitely not an elegant solution, but could work for now. The surface hole always goes down roughly 32 blocks (but only if the surface of the island at this position is above sea level, i.e. 90).
