Posts by red51

Die Idee ist gar nicht so schlecht, ich packe es auf jeden Fall mal auf unsere Todo-Liste

Momentan hat das leider eine eher geringe Priorität, weil einerseits der Nutzen einigermaßen überschaubar ist, andererseits es ohnehin nur ein bestimmter Teil der Nutzer wirklich verwenden kann. Bis vor kurzem war ein weiteres Problem, dass DirectX 12 (welches dafür nötig ist) in Unity wirklich grottenschlecht umgesetzt war. Auch ohne Raytracing sorgte DirectX 12 in Unity im Vergleich zu DirectX 11 für einen fast 50%igen Performanceverlust.

Unity hat letztes Jahr aber den DirectX 12 Support verbessert und proklamiert, dass man die Performance nun fast so gut wie in DirectX 11 sein könnte. Leider ist der VRAM Verbrauch deutlich höher und manche Entwickler melden weiterhin spürbar schlechtere Performance im Vgl. zu DirectX 11. Und wie gesagt, wir reden hier noch bei einem 1:1 Vergleich von DX11 und DX12 (ohne Raytracing usw).

Wenn die Unity-DirectX12-Problematik abgehakt ist, ist schon wieder greifbarer, dass wir Raytracing anbieten. Nichtsdestotrotz wird sowas nicht vor dem Storepage-Update passieren können...

Quote from Yaromid

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

Quote from efesliefes

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!

Quote from CursedXistence

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)

Quote from FoxTheHyena

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

Quote from Methamorphoosys

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)

Quote from Dark Megatron

Tolle Bilder von den Segelboot und den Wölfen.

Danke für das Feedback

Quote from TheKing

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

Quote from angriff

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:

player.raycast(10, Layer.getBitmask(Layer.OBJECT), true, (result) -> {
    //Check if we got a result and it's an object
    if (result != null && result.getLayer() == Layer.OBJECT) {
        //Get the object id
        long id = result.getObjectGlobalID();

        //Get the object chunk position
        Vector3i chunkPos = result.getObjectChunkPosition();

        //Get the object element with that id
        ObjectElement o = World.getObject(id, chunkPos.x, chunkPos.y, chunkPos.z);

        //Verify that object is not null
        if (o != null) {
            //Get object definition
            Objects.ObjectDefinition objectDef = o.getDefinition();

            //Check if object is a door (determined by Type.Door)
            if (objectDef.type == Objects.Type.Door) {
                //Do something with the door, e.g. open it via setStatus() etc
            }
        }
    }
});

Quote from angriff

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

Quote from sapier

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

Quote from sapier

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?

Quote from sapier

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

Quote from sapier

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

Quote from sapier

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

Quote from sapier

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

Quote from sapier

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

Quote from sapier

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

Quote from UndeadSolstice

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

Quote from sapier

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:

@EventMethod
public void onPlayerCraftItem(PlayerCraftItemEvent evt) {
    //Get crafted item
    Item item = evt.getItem();

    //Check if item is a construction element
    if (item instanceof Item.ConstructionItem construction) {
        System.out.println("Player crafted construction element: " + construction.getConstructionName()); //prints "block", for example
    }

    //Check if item is an object
    else if (item instanceof Item.ObjectItem object) {
        System.out.println("Player crafted object: " + object.getObjectName()); //prints "workbench", for example
    }

    //Check if item is a garment
    else if (item instanceof Item.ClothingItem clothing) {
        System.out.println("Player crafted clothing item: " + clothing.getClothingName()); //prints "mininghelmet", for example
    }

    //Check if item is a blueprint
    else if (item instanceof Item.BlueprintItem blueprint) {
        System.out.println("Player crafted blueprint: " + blueprint.getBlueprintName()); //prints "My summer house", for example
    }

    //Else it's a regular item
    else if (item != null) {
        System.out.println("Player crafted regular item: " + item.getName()); //prints "pickaxe", for example
    }
}

Quote from sapier

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)

Quote from sapier

on the way I discovered a further issue, how to add a blueprint item to the inventory? ... well without the other issue solved that'd be just a question for curiosity

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

Quote from sapier

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"