Posts by red51

Quote from UndeadSolstice

Where do you install the plugin at?

since its a java file and not a .zip file, im not sure where to place it

Each plugin requires a separate subfolder in the plugins folder of the game. So in order to use this plugin, make sure to put the pluginlist-1.0.0.jar into a folder (which could be called PluginList, for example) inside the plugins folder, so it has this folder structure:

Rising World
|__ plugins
    |__ PluginList
        |__ pluginlist-1.0.0.jar

But please bear in mind that this plugin is for the Java version of the game (i.e. the current "default game"), so unfortunately it won't work with the new version of the game (the one that's currently in a beta branch and needs to be enabled manually)

Sowas würde grundsätzlich über die NpcDefinitions gesteuert werden (über die "behaviour" Variable). Das Überschreiben von Definitions im Allgemeinen über die API wird aber leider noch nicht mit dem nächsten Update kommen. Das ist aber definitiv noch geplant, doch da das einen gewissen Rattenschwanz hinter sich herzieht (Definitions müssen zwischen Server und Clients synchronisiert werden, Client-Definitions müssen beim Neuladen zurückgesetzt werden usw), kann ich leider noch nicht genau sagen, wann das kommt

Quote from angriff

So it appears I need to build a plugin to change a players permission group after playing a certain amount of time. The commands do not seem to be able to discern if the player has already changed from, for example, a Visitor to a dedicated General Player. The command after spawn would continually change the players group after some set time every time they join the server, correct?

Which command do you mean exactly?

Quote from yahwho

Hi red51 being able to set an npc to invisible in conjunction with this would allow for some very cool stuff to happen

Indeed, this sounds like a great idea! We will add a npc.setInvisible() method with the next update Do you still want the player to be able to interact with the npc, so only the rendering is turned off with the invisible setting?

Quote from noci

Man could be a private GameObject for example, player.attachTo(Bone.Head, gameObjectHut) Bind directly to the head

Oke, it's get the custom closes, then it is Superfluous

Yes, there will be an option to attach the object directly to the head This way you will be able to add custom hats or other headgear to a player (or npc).

Unfortunately we have no ETA for actual custom clothes yet, so this would be a proper workaround for now But there are many more use-cases, like attaching a particle effect or a light or a text to a player/npc (ofc this could also be solved via moveToLocalPosition(), but attachTo() is much smoother [perfectly synced with the target element] and much more performant).

After attaching an object to a target, setLocalPosition() and moveToLocalPosition() will still work (this will then set an offset between the object and the target).

This topic contains more information about the scheduler: Server Task Scheduler

When defining time intervals, it depends on the syntax: If you just write something like @10m, for example, the command will be executed every 10 minutes. If you write @+10m instead, the command will be executed once (10 minutes after the server start). If you type @15:00 instead, the command will be executed exactly at 3 pm server time etc.

The linked topic above contains more information about that (there you will also find an overview of all events)

To get an overview of all commands (like "/say"), you can take a look at this topic: Server Commands [New Version]

If you want to download the server for the new version, you can either find it in your Steam client under "Tools" (if you use the Steam version), or alternatively you can download it via SteamCMD. This topic contains more information about that (see "Download" section): Dedicated Server Setup [New Version]

Small addendum: The next update will also introduce a new attachTo() method for game objects (including volumes) - this can be used to attach a game object to an existing player or npc, so it will automatically follow the player/npc in a performance-friendly way with no jitter or delay (of course such a method also provides many more possibilities, like adding new headgear to a player or npc etc)

It's indeed necessary to get a Plant when working with vegetation/plants/trees etc (in conjunction with the World.getPlant() method) ObjectElement only represents furniture, fixtures, workbenches, doors, lamps etc, basically any kind of furniture and fixtures that can be placed by the player.

But probably it would be also a good idea if we add a getPlant() method directly to the vegetation events (and getObject()/getConstructionElement() to the object/construction events accordingly). We will do this with the next update^^

However, the PlayerHitVegetationEvent also got a setDamage() method in the meantime, so if you just want to change the amount of damage the player inflicts to the plant, you can simply use the setDamage() method

Quote from sapier

SetDamage method would be helpfull in PlayerHitTerrainEvent too

Yes, definitely, we will add this with the next update

Quote from noci

I think this type of control is very pleasant and you would make the Whole uniform.

Thanks for your feedback

Quote from noci

You can here at the Performance when you want to leave it to the player after Hiking I would do that So, I mean, look at all the the Volum Chlient-Sided move. Possibly also of other, well-Synconiesieren.

Maybe that makes little sense, but I thought of it: for example, something like magic (fog, to Hide) hangs on a Remote player drann.

Instead of a volume following a player, it's usually better to either use a global volume (and only attach it to the player(s) you want to be affected by the effects), or just use the player-specific post processing (via player.getPostProcessing() and player.setPostProcessing())

Volumes are invisible (only the post processing effects become visible as soon as you enter the volume), so if you really want a volume follow a target (e.g. if you want to enable a post processing effect if the player moves towards a moving target), it's usually sufficient to update the volume position every 500 ms, for example (e.g via the moveToLocalPosition() method).

Quote from Tyrolianer

red51 gibst es bezüglich den dungeons eig eine Umfrage?

Eine direkte Umfrage war an sich nicht vorgesehen, aber ggf. die Community an der Gestaltung der Dungeons teilhaben zu lassen. Die Pläne stehen weiterhin (wahrscheinlich warten wir aber das nächste Update noch ab)

Quote from Tyrolianer

Und würde mich noch interessieren ob die Werkbänke noch kommen die es auch in der Java Version gab. 😀

Kommt ein wenig auf die Werkbank an: Mit dem nächsten Update gibt es zumindest den Webstuhl (wie in der Java Version), welcher dann Bedingung für die Herstellung der Kleidungsstücke wird. Sonst gab es in der Java Version lediglich noch die Blockbank und Sägebank... da müssten wir mal schauen, wie sinnvoll das tatsächlich wäre (da Rezepte jetzt ja nicht mehr direkt an eine Werkbank gebunden sind, sondern die Werkbank nur noch in der Nähe stehen muss)

Quote from Opa Zeron

Gibt es jetzt schon einen Termin für das nächste Update?

Es ist ja schon ein paar Tage her, dass es beschrieben wurde.

Sollten nicht auch ein paar Bilder in der "Roadmap" erscheinen?

Einen konkreten Termin kann ich leider noch nicht nennen Eigentlich sollten nur Karten ins nächste Update, aber es hat sich dann doch noch ne ganze Menge mehr hineingemogelt... u.a. wird es aber neben der Karte eine weibliche Spielerfigur geben, Terrain-Materialien für Blöcke, viele QoL Änderungen, Banditen und mehr.

Für die Trello Roadmap fehlten uns leider noch ein paar nette Screenshots... werden wir aber kommende Woche updaten

Yes, you will also be able to override the fog that way But unfortunately this doesn't provide any access to the day/night cycle, for example, or access to the sun/moon light... although you will be able to change the overall screen brightness/exposure.

Some effects we could add easily would be:

Contrast/Saturation/Hue
Color filter
Film grain (noise)
Chromatic aberration (color fringing)
Distortion effect
Blur
Exposure
White balance
Vignette effect
Highlights/Midtones/DarkTones

In addition to a global post processing setting (which can be retrieved via player.getPostProcessing()), we could maybe also add a local "volume" object (derived from "GameObject") where these effects would be visible. This way you could have many different post processing volumes in your world with individual settings. When the player enters a volume, the post processing effects will be interpolated automatically.

I think we will also change the API a bit: Instead of having separate methods (e.g. "setContrast()", "resetContrast()" etc, as mentioned in my previous post), it's probably better if we use the same syntax as for UI styles where you edit the individual fields directly (and call a method to update/sync the post processing changes once you're ready, so the game doesn't automatically sync every tiny change that is performed). The syntax would then look like this:

//Get global player post processing object
PostProcessing pp = player.getPostProcessing();
//ALTERNATIVELY: PostProcessing pp = new PostProcessing();

//Override contrast, blur and saturation
pp.contrast.set(100);
pp.blur.set(10);
pp.saturation.set(-50);

//Apply the changes for the player
player.setPostProcessing(pp);

...

//At a later stage, reset values again if desired
pp.contrast.reset();
pp.blur.reset();
pp.saturation.reset();
player.setPostProcessing(pp);

For local (or global) volumes, the API could then look like this:

//Create volume game object
PostProcessingVolume volume = new PostProcessingVolume();

//Assign collider (effects are then only visible inside this collider)
volume.setCollider(new BoxCollider(10f, 10f, 10f));

//Set a position for the volume
volume.setLocalPosition(player.getPosition());

//Update post processing effects
volume.profile.contrast.set(100);
volume.profile.blur.set(10);
volume.profile.saturation.set(-50);

//Add to player (this automatically syncs pending profile changes)
player.addGameObject(volume);

...

//To perform changes at a later stage, remember to call update
volume.profile.contrast.set(0);
volume.updateProfile();

Thanks for letting me know! Unfortunately the block position calculation in the API is indeed wrong... apparently the calculation was already wrong back then in the old Plugin API for the Java version (and we just copied the Utils class from the old API) The weird thing is, the native game implementation (and even the implementation the Java version was using) is correct, so it looks like this error was solely introduced in the Plugin API for the Java version back then (and ported to the new API accordingly).

Anyway, we will fix this with the next update

int bx = (int) x - (chunkPositionX * CHUNK_SIZE_X);
return x < 0 ? bx - 1 : bx;

Das wäre auf jeden Fall sinnvoll. Werden wir mit dem nächsten Update einbauen

Ehrlich gesagt habe ich das leider bisher noch nicht probiert... ich weiß nicht, wie gut das mit der API wirklich funktioniert. Stellenweise könnte das möglicherweise Probleme bringen, da das Spiel nicht darauf ausgelegt ist, dass die Ausführung innerhalb der API angehalten wird

Wenn du aber die JVM im Debug-Modus starten möchtest (also mit zusätzlichen Optionen starten willst), dann kannst du die zusätzlichen Optionen in der config.properties Datei im Singleplayer (bzw. server.properties Datei bei einem Server) setzen: Füge diese einfach bei Plugins_VMOptions hinzu (bei mehreren Optionen kannst du diese via Semikolon trennen).

Quote from paulevs

Hi, are there any news related to this?

Unfortunately not much happened in this area There is a GenerateWorldPartEvent in the API, but it's currently private (so unfortunately it's not accessible). In theory it enables you to modify plants and the terrain. While changing the plant data already works pretty well, changing the terrain is still a bit tricky. Internally the game stores data of the neighbour world parts in the terrain data (similar to how it worked in the Java version). This was done to speed up world generation (by avoiding unnecessary world part generation and lookup), but it makes things tricky if you want to provide a custom heightmap. We wanted to change that, but it requires some rework...

When it comes to syncing definitions, there is definitely more demand for this. While the game is already capable of serializing and deserializing the definition data (which is necessary to sync it between client and server), I'm afraid this will not be supported before the Java version was finally replaced by the new version

Quote from yahwho

I'm assuming we would be able to do post processing on the rendered scene and *then* add UI elements that are not effected by the PP?

Actually the post processing only affects the rendered scene UI elements are never affected by that (in fact Unitys UI Toolkit doesn't even have any support for post processing or custom shaders)

There might be some confusion regarding the PlayerGameObjectHitEvent: it's only triggered if a player hits a GameObject, i.e. a custom element spawned via the API. Unfortunately this doesn't apply to built-in game elemnts like plants or objects. To get the hit events for them, you can check out the events in the net.risingworld.api.events.player.world package: https://javadoc.rising-world.n…orld/package-summary.html

When it comes to static world elements, the game distinguishes between vegetation (plants, trees, but for technical reasons also naturally spawned boulders, tree trunks etc), objects (furniture, doors, workbenches) and construction elements (blocks, windows etc).

For example, the PlayerHitVegetationEvent is triggered when the player hits a plant or a tree with a tool or weapon, the PlayerHitObjectEvent is triggered when the player hits an object element (e.g. furniture, workbenches, doors etc), the PlayerHitConstructionEvent is triggered when the player hits a construction element (e.g. a block) and the PlayerHitTerrainEvent is triggered when the player hits the ground/terrain

When it comes to interactions (i.e. the player presses the interaction key [F] while looking at an element), you can only listen for Npcs (PlayerNpcInteractionEvent), objects (PlayerObjectInteractionEvent) and players (PlayerPlayerInteractionEvent) for now.

Picking up elements is handled a bit different: There is a PlayerPickupItemEvent (called when the player picks up an item lying on the ground, e.g. a pickaxe, weapon, food, resources etc, basically everything that goes to the inventory). But if the player picks up a static world element (e.g. a plant) or dismantles furniture or blocks, there are some additional events which are called: PlayerRemoveVegetationEvent (when the player harvests or picks up a plant), PlayerRemoveObjectEvent (when the player deconstructs an object, either with the sledgehammer or by holding F) and PlayerRemoveConstructionEvent (when the player deconstructs a block with the sledgehammer)

It would be indeed a nice thing if the API had access to this... but probably it's better if we provide general access to various post processing effects (so you can also manipulate other screen-space effects, like color, contrast, hue etc). To keep things structured, it's probably a good idea if we move all post-processing related effects to a separate subclass (e.g. a "PostProcessing" object that can be retrieved from the player). The API could then look like this:

//OUTDATED SYNTAX!
//Get post processing object from player
PostProcessing pp = player.getPostProcessing();

//Set blur intensity (this makes the blur effect visible automatically)
pp.setBlur(10);  // <- blur-range of 10 px

//Once you no longer need the effect (and want the game to regain control over it), call reset
pp.resetBlur();

These settings would then override the particular game effect. For example, if you call setBlur(0);, that would override the game blur to 0 (so the blur wouldn't even be visible if you hit ESC). If you don't need the blur anymore (and want the game to take control over it again), you could call resetBlur();.

I think we could get this ready for the next update But if you have any suggestions about it (or if you need access to any other effects), please let me know

Wir halten uns mit dem Update der Steam Page tatsächlich noch solange zurück, bis die neue Version für möglichst alle oder zumindest viele Spieler als guter Ersatz für die Java Version betrachtet werden kann. Weitestgehend ist das jetzt eigentlich schon der Fall - ich denke es gibt nur sehr wenige Spieler, die momentan noch die Java Version bevorzugen. Das Problem ist aber, dass ein paar Features noch fehlen. Dazu gehören auch eher weniger bedeutsame Features wie zB das Journal: für jemanden, der das Spiel bereits kennt, ist das zwar nicht so relevant, doch ein neuer Spieler kann durch die neue Version schnell mal überfordert werden, sodass ein Journal schon sehr hilfreich wäre. Auch hier und da ist noch etwas Feinschliff nötig.

Das nächste Update wird die Lücke aber weitgehend schließen, sodass mit dem Update danach höchstwahrscheinlich endlich die Java Version ersetzt wird