Posts by red51

Quote from noci

red51 ist das Absicht das ich den Vector3f nicht Clonen kann?

Es gibt leider tatsächlich keine clone() Methode für Vector3f (oder auch andere API-Objekte). Was du da siehst ist die clone() Methode die von "Object" bereitgestellt wird, also direkt von Java (und die ist nicht public).

Klonen (über die clone()-Methode) ist in Java nicht gut umgesetzt, weshalb wir es generell in der API vermieden haben (keine unserer Klassen implementiert die clone() Methode). Es wird im Java-Umfeld allgemein eher abgeraten, clone() zu verwenden...

Die Vector3f Klasse bietet daher stattdessen eine copy() Methode an, die quasi genau das macht, was du suchst: Vector3f currentPoint = startPoint.copy();

Oder alternativ direkt einen neuen Vektor erzeugen und den alten als Parameter dem Konstruktur übergeben, wie du es in deinem Beispiel auch getan hast

Wenn du den Vektor für eine Addition oder Multiplikation o.ä. benötigst, dann kannst du auch die add(), mult() etc. Methoden ohne "Local"-Suffix benutzen - die erstellen immer einen neuen Vektor (während alle "Local" Methoden die bestehende Instanz verändern, ohne einen neuen Vektor zu erstellen). D.h. zB Vector3f result = startPoint.add(4f, 5f, 0f); gibt einen neuen Vektor zurück (und "startPoint" bleibt unverändert), während startPoint.addLocal(4f, 5f, 0f); direkt "startPoint" verändert und keinen neuen Vektor erstellt.

Quote from CursedXistence

Okay I owe you an apology. Looking at this preview picture compared to the other one it was the way the one wolf was standing that was making it look like the fur was flatter looking that what it actually is. I do sincerely apologize and hope my original comment didn't offend.

Oh, don't worry, I definitely did not consider your post offensive You still brought up a completely valid point (and we indeed have plans to improve fur rendering in the future, as mentioned above)

Quote from FoxTheHyena

Yes and I only see wolves. But it's fine, still excite to hear there's been development!

If the link to the Activity List doesn't work, here are the direct links to all updated cards instead

https://trello.com/c/VShc7WPV/174-animals

https://trello.com/c/H2oLJHLG/168-boats-and-ships

https://trello.com/c/RvWiETl5/182-ingame-map

https://trello.com/c/vI5vXetb/129-player-model

Quote from Ozorvals

A question about the dhows: What is the width and the air draft ? It's better to anticipate to build bridges at the good size.

The air draft is roughly 7-8 blocks. The total length is almost 9 blocks and the width (including sails) is around 7 blocks

But please bear in mind that this may still change a bit. Also, there will be bigger vessels in the future

Quote from Deirdre

Wir haben jetzt zwar Glastüren. aber als Eingangstür sind die eher für einen Shop geeignet, denn wer möchte in seinem Haus eine durchsichtige Eingangstür haben, durch die alles im Inneren zu dmsehen ist. Es gibt so schöne Türen da ist oben Glas und nicht die ganze Front verglast. Unsere Türen kann man nicht durchsichtig machen, leider. Ich muss ehrlich gestehen, dass diese Glastüren eher als Balkontüren denn als Eingangstür geeignet sind. Die vorhandenen Modelle sind leider nicht wirklich schick.

Bis auf die beiden Eingangstüren (die tatsächlich eher für einen Shop o.ä sind) waren die anderen Glastüren eher weniger als Haustüren gedacht, sondern eher als Innentüren oder ggf. tatsächlich auch Balkontüren o.ä. (oder mit etwas Fantasie evtl. auch für eine Duschkabine oder dergleichen).

Du kannst aber bzgl. Türen gerne jederzeit Vorschläge posten (idealerweise mit Bild)

Quote from Deirdre

Fragt sich nur wann?

Ich würde mich am liebsten sofort an bewegl. Strukturen ransetzen (weil das ein wirklich interessantes Thema wäre), ist aber leider nicht drin bevor wir nicht die Storepage aktualisiert haben

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)