Describe the feature

I love this mod, but some things just are missing. However, I'd like to create my own framed blocks. Compiling the mod every time with changes isn't really what I want to do tho.

while I'm at it, does the 1.19 vversion include more blocks (I saw the cf page)? is there a possibility that you'll backport these (if they are any) to 1.18 at some time in the future?

Adding blocks via datapacks is impossible, that's simply not how the game works. While adding them via a custom data loading system would theoretically work, it's not compatible with the current architecture of this project and would require major reworks for little benefit.
Specifying the models in a resource pack is something I have tried to implement for my own benefit as it would reduce the amount of code needed for all the models but the code for that ended up being far too complicated, defeating the purpose of the whole endeavor to reduce the amount of code.

While I cannot stop you from adding new content yourself and building a custom version of the mod, I would prefer if you were to suggest these missing blocks here so that everyone can benefit. I also currently have a list of about 50 planned blocks, so it's very likely that at least some of the blocks you deem missing are already planned or being worked on.

As for which blocks are in which version: I currently actively support 1.18.2, 1.19.2 and 1.19.3 and all blocks will be added to all three versions. Keep in mind though that the CurseForge page is currently not up-to-date as the CF project description editor is a huge pain in the ass and I didn't have the patience to update it when I uploaded the last version. I'll update it at some point in the coming days.

I would prefer if you were to suggest these missing blocks here so that everyone can benefit.

to be honest, I can't name any except slab edges and pillars combined. they're more or less something I'd like to have on the fly, which is impractical to say the least.

Adding blocks via datapacks is impossible, that's simply not how the game works

I didn't mean directly adding them, but possibly a "category" (idk how they're called, these like functions, tags, ...) in which you'd define a model or similar and which part of the model counts as the same "region" (for the double blocks)

it's not compatible with the current architecture of this project and would require major reworks for little benefit.

I'm not a mod dev myself, I have no idea how hard this would be to make, but I'd imagine a block that is always loaded (because if I understood correctly, blocks can only be added at boot?), i.e. called "Custom Framed Block" or similar. Then there'd be a model or something with an id (basically like CustomModelData) or a string, with a way to input that into the block (possibly also using a reference item per model or something like that?). afaik blocks can change models?

Specifying the models in a resource pack is something I have tried to implement for my own benefit

okay never mind, apparently you have to have different block states for different models or something like that? I could imagine allocating [x] of these states and then having one per block variant? one thing I would be concerned about tho is the interactivity (doors, buttons, trapdoors, pressure plates, ...).

probably this whole comment only contains useless crap that either makes no sense or is useless anyways due to some restrictions :/

to be honest, I can't name any except slab edges and pillars combined. they're more or less something I'd like to have on the fly, which is impractical to say the least.

If you mean something like the three things in this screenshot, then that's already planned:

If not, then please elaborate, preferably with a little illustration.

I didn't mean directly adding them, but possibly a "category" (idk how they're called, these like functions, tags, ...) in which you'd define a model or similar and which part of the model counts as the same "region" (for the double blocks)

You are underestimating the amount of data and logic attached to these blocks, there is a lot more than just the model and which part of a double block belongs to which component. As a simple example: if you place two Framed Corner Pillars next to each other so that they touch and then apply glass to them, then the glass on the touching faces will not be visible in the same way it's not visible if you placed two glass blocks next to each other. This kind of logic is impossible to define in a JSON file and therefore must be implemented in code.

I'm not a mod dev myself, I have no idea how hard this would be to make, but I'd imagine a block that is always loaded (because if I understood correctly, blocks can only be added at boot?), i.e. called "Custom Framed Block" or similar. Then there'd be a model or something with an id (basically like CustomModelData) or a string, with a way to input that into the block (possibly also using a reference item per model or something like that?). afaik blocks can change models?

Blocks can only be registered when the game starts, correct. Different shapes and their orientations can only be efficiently distinguished by different block states and adding new ones at runtime is not possible as those are set in stone when the block is registered. Another problem you would run into is that not all shapes use the same properties for their orientation, some only have a horizontal direction, some add a top/bottom or left/right boolean to that, others use the full 6 directions and adding all those to the blockstate would cause a combinatorial explosion and slow the game to a screeching halt.

okay never mind, apparently you have to have different block states for different models or something like that? I could imagine allocating [x] of these states and then having one per block variant? one thing I would be concerned about tho is the interactivity (doors, buttons, trapdoors, pressure plates, ...).

Reserving blockstates for a potential use is not possible as all blockstates need defined values for all properties and all properties need to have a fixed set of possible values, so you can't set aside blockstate instances for some unknown and possibly unbounded property.