Requests for the new API

A new update is now available, introducing seasons and more!
  • Good day, I want to request several things to the plugin API that will make developing some plugins easier:


    1. Ability to control some post effects for players - fog color, fog intensity and ambient light. This will make possible custom underground and underwater rendering, probably some custom effects on specific biomes and so on.


    2. Ability to attach same LOD parameters to assets as the game uses with same distances. This should make plugin graphics configurable together with game graphics and will make LOD configuration easier.


    3. Custom definitions. I think that it was planned earlier (and probably for final API version), so I just included it here. This will be a really powerful feature that will finally make custom things possible.


    4. Different world generation events to change and modify ho chunks are generated and populated

  • 1. Ability to control some post effects for players - fog color, fog intensity and ambient light. This will make possible custom underground and underwater rendering, probably some custom effects on specific biomes and so on.

    It's our intention to expose that to the API, but we're still not 100% sure how the game should handle that specifically (because these values may change depending on the player position and the weather).


    Maybe it's sufficient if the API just gets an option to override that? I.e. setting the fog intensity through the API prevents the game from changing that value anymore...

    Probably it's indeed necessary to have this setting per player (instead of a global World method) ^^


    2. Ability to attach same LOD parameters to assets as the game uses with same distances. This should make plugin graphics configurable together with game graphics and will make LOD configuration easier.

    Not sure how such an API should look like... maybe the game could cull these elements automatically (depending on the view distance settings), but the API may get a method to override the view distance (maybe set a relative factor)?


    3. Custom definitions. I think that it was planned earlier (and probably for final API version), so I just included it here. This will be a really powerful feature that will finally make custom things possible.

    Yes, that's definitely planned :) The idea is that you could change any field in a definition class, then call "synchronize()" to sync the changes with the server and the clients. This may look like this:


    Java: Note: This doesn't work yet!
    //Make a workbench weak
    Objects.ObjectDefinition def = Definitions.getObjectDefinition("workbench");
    def.strength = 1;
    def.synchronize();


    Basically any field from our internal definitions are exposed to the API, so you could change anything that way.


    But this isn't implemented yet. The methods are already in place, but they don't work atm.. but it's on our to-do list ;)


    4. Different world generation events to change and modify ho chunks are generated and populated

    This is also planned ;) We're still not 100% sure if it's better to have events (when a chunk or world part is generated) or a way to implement and register a custom world generator module (where you could just override methods like "getTerrain()" or "getChunk()") :thinking:

  • It's our intention to expose that to the API, but we're still not 100% sure how the game should handle that specifically (because these values may change depending on the player position and the weather).

    Probably it is possible to have some sort of delay for these changes, and after some time values will smoothly become game controlled again if the plugin will not update them again.

    Or it can be possible to get default values calculated by the game and operate them on plugin side


    Not sure how such an API should look like...

    Probably it can be a custom function that will look for LOD component in GameObject and if it found one will change it or put into internal list to control later (for example when setting are changed). If the function will be not called the LOD will stay same as in prefab, and when called it will be synchronized with the game


    Yes, that's definitely planned :)

    That's good, so we will be able to override built-in definitions, but what about completely custom? Like new types of wether or objects?


    We're still not 100% sure if it's better to have events (when a chunk or world part is generated) or a way to implement and register a custom world generator module (where you could just override methods like "getTerrain()" or "getChunk()")

    Looks like events will be more compatible with each other, while custom module should be a bit faster. If the system will have events then different plugins can apply their own changes to world separately: for example one plugin can alter cave generation and another one can change ocean. If this will be done in modules they should be somehow connected with each other and "know" about changes done by other plugins, otherwise there will be only one plugin that can change world in the pack

  • Probably it is possible to have some sort of delay for these changes, and after some time values will smoothly become game controlled again if the plugin will not update them again.

    Or it can be possible to get default values calculated by the game and operate them on plugin side

    Getting the default values is a bit tricky, because that's solely calculated client-side atm... so reading these values from the client require a callback, which is a bit cumbersome to use but also has some overhead (especially when reading this frequently)...


    Having some delay for the changes is probably better, but that also requires the plugin to override the values frequently (resulting in some overhead again due to the sync packets that need to be sent to the client)...


    Not sure if it's maybe sufficient to have a way to set a relative value instead. E.g. a color the fog gets multiplied with. So if the player goes into a cave (which makes the fog darker automatically), that would also affect the color set by the plugin. In addition to the "multiply" mode, we could also add an "additive" or "overwrite" mode to add or overwrite the color (maybe with a "weighting" parameter to control how much it should overwrite the game values) :thinking:


    Or alternatively we may use a concept similar to Unitys HDRP volumes: We may add a similar object to the API where you could overwrite fog data, lighting, colors etc, then you could set a weighting for this volume and a priority. Such a volume could be either local (defined by an Area), or global (then the priority and weighting controls how much your settings should overwrite the default values of the game) ^^


    Probably it can be a custom function that will look for LOD component in GameObject and if it found one will change it or put into internal list to control later (for example when setting are changed). If the function will be not called the LOD will stay same as in prefab, and when called it will be synchronized with the game

    Oh, basically you could add an LOD component already, it should at least work with the LOD bias graphics setting. But unlike vanilla elements, it does not get culled if out of view bounds...


    Maybe we could add a setting where you could determine if the game object should be always visible or bound to the view distance (or detail view distance) ;)


    That's good, so we will be able to override built-in definitions, but what about completely custom? Like new types of wether or objects?

    You will also be able to create new definitions that way :) However, for custom items, there is some additional information required (to handle animations etc properly).


    Looks like events will be more compatible with each other, while custom module should be a bit faster. If the system will have events then different plugins can apply their own changes to world separately: for example one plugin can alter cave generation and another one can change ocean. If this will be done in modules they should be somehow connected with each other and "know" about changes done by other plugins, otherwise there will be only one plugin that can change world in the pack

    Custom world gen modules would be indeed faster, but may be also a bit trickier to use (especially if there are multiple plugins which register their world gen modules). In case of events, that wouldn't be a big issue at all, because if multiple plugins listen for that event, they will automatically see changes done by other plugins (depending on the execution order of plugins).


    We have to think about that. Actually we have already done some preparations for a "GenerateWorldPartEvent" some time ago (basically it's in the API, but it's not exposed and not fully functional yet). It's called everytime a new "world part" (which is basically a world section with a size of 512x512 blocks, i.e. 16x16 chunks) is generated. A plugin could use this event to load custom heightmaps, for example, or overwrite terrain materials or plants etc ^^

  • 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 :silenced:

Participate now!

Don’t have an account yet? Create a new account now and be part of our community!