[partially fixed] Why have you forsaken me, cave-air :(

[oddlama]

portals can't be built in strongholds because there's cAvE-aiR. Should be added to valid blocks in config. Same for void air.

Workaround: Fill the area with blocks and destroy them to get normal air.

[ryantheleach]

I've tried to tackle this, but beyond hacking it in, it gets out of hand fast in terms of refactoring.

E.g. you change the portal blocks to a material map, then you see all the 12345 blocks for boundaries, and realize that if you are going to the trouble for changing portal blocks to a material set, then maybe those should be a material set too, then that fundamentally changes how styles are stored.

Which then changes how those blocks are serialized, which affects backwards compatibility, and finally how the user ends up inputting styles...

compared to just special casing air, and leaving the configs alone XD.

I think the full change is worthy, but I'm not sure how to tackle styles.

[ryantheleach]

I havn't yet looked at block #tags but maybe they would be more appropriate (for everything except styles anyway, they are basically pre-built material sets)

[oddlama]

vane's configs have a version field for this purpose, and the expected version is specified in the main java file of the respective module. If you want to introduce a breaking change to a config that's no problem. Just increment the version number, replace the @Config... field with something else and all users will be forced to review changes on the next update.

I'm not entirely sure how you want to apply block tags to styles, as styles definitely need a specific block to which the portal's blocks are changed to.

If I'm not mistaken, specifying which blocks get classified as area, boundary, etc. should just be config related and not related to how users create styles. The config change although will definitely be tough. (New annotation class necessary, because java annotations are nicely designed so that you can't make them generic :( )

[ryantheleach]

I think I may have struggled to communicate where my head had gone. It's possible, but harder for someone new to your codebase was all.

Talking about #tags was making them available to be used in materialSets, since they are basically the same thing as a named materialSet.

I specifically said that they wouldn't be easily applicable to how styles are currently defined.

The changes I proposed would cause a large amount of refactoring to styles as it currently stands, needing to migrate to some form of Material Map, and possibly a wrapper around the materials to indicate origin etc, to make sure that 1:1 functionality of styles could be maintained.

[ryantheleach]

For reference, https://github.com/RTLBukkit/vane/commit/907d7cc23b032fdcb5eb256386376923076f18f6 (Do not pull, I'll be force pushing to rename the commit when I've worked out exactly what I want to do).

[oddlama]

Alright just let me know when it's ready