You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In AOneBlock we have 4 different ways how to define block/entity in phases config file:
vanilla Minecraft block (GRASS_BLOCK)
vanilla Minecraft entity (SKELETON)
with custom block data (type: data data: minecraft:chest[waterlogged=true])
as itemsadder block (blablabla.blabla)
and also there is some sort of shortened version that I do not understand.
Also, people want to add some extra things like mystic mobs or any other plugin that has some custom entities/blocks.
First of all, there is only documented CustomBlockData, so people even do not know how to use items adder or the short version of custom data.
Secondly, it becomes messier and messier to add new things to it.
Having multiple different ways how to write/add blocks is confusing. I think it would be much clearer if we could have a single and strict way how to do it.
Describe the solution you'd like.
I would like if AOneBlock (and maybe other addons that generate/place blocks) generic block and entity definitions.
It would not be separated into 2 categories (entities/mobs) but have a single list.
This way we could add even more custom-type things, like commands, effects, or anything else.
Multi-line definitions in YAML look very ugly. I agree with that. Maybe we could move from YAML to JSON format for phases?
It would allow clearer ways to define blocks/entities.
Describe alternatives you've considered.
The alternative is simple, keep the current system and continue to increase different ways how to define blocks/entities.
Agreements
I have searched for and ensured there isn't already an open issue regarding this.
I have ensured the feature I'm requesting isn't already in the latest supported BentoBox build or Addons.
Other
An alternative solution would be to implement something similar to ItemParser in BentoBox code and allow BentoBox to generate blocks/entities with given parameters.
Unfortunately, it would require hooks to be directly inside the BentoBox core, unless we allow to have Hooks like it is with Addons (separate jar files).
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem?
In AOneBlock we have 4 different ways how to define block/entity in phases config file:
and also there is some sort of shortened version that I do not understand.
Also, people want to add some extra things like mystic mobs or any other plugin that has some custom entities/blocks.
First of all, there is only documented CustomBlockData, so people even do not know how to use items adder or the short version of custom data.
Secondly, it becomes messier and messier to add new things to it.
Having multiple different ways how to write/add blocks is confusing. I think it would be much clearer if we could have a single and strict way how to do it.
Describe the solution you'd like.
I would like if AOneBlock (and maybe other addons that generate/place blocks) generic block and entity definitions.
It would not be separated into 2 categories (entities/mobs) but have a single list.
Maybe it could be like this:
This way we could add even more custom-type things, like commands, effects, or anything else.
Multi-line definitions in YAML look very ugly. I agree with that. Maybe we could move from YAML to JSON format for phases?
It would allow clearer ways to define blocks/entities.
Describe alternatives you've considered.
The alternative is simple, keep the current system and continue to increase different ways how to define blocks/entities.
Agreements
Other
An alternative solution would be to implement something similar to ItemParser in BentoBox code and allow BentoBox to generate blocks/entities with given parameters.
Unfortunately, it would require hooks to be directly inside the BentoBox core, unless we allow to have Hooks like it is with Addons (separate jar files).
The text was updated successfully, but these errors were encountered: