Cyborgmas

Could you remove Dynmap ? If the crash happens again give the logs and crashreport again.

https://github.com/Beardlessbrady/FortKnox-Mod/blob/f81dc23108b2b3b1ed99fb6815702ba3e93841aa/src/main/java/com/beardlessbrady/fortknox/ModFortKnox.java#L28 you want to use @ CapabilityInject here otherwise its always null also, you are casting to a lazyoptional here... https://github.com/Beardlessbrady/FortKnox-Mod/blob/f81dc23108b2b3b1ed99fb6815702ba3e93841aa/src/main/java/com/beardlessbrady/fortknox/capabilities/protection/ProtectionProvider.java#L38 which is just plain wrong. i recommend looking at forge's different cap implementations (energy, fluid handler, item handler)

1.12 is not supported, if you are receiving this error on a supported version (1.16 for instance) post that log instead

So yeah you are def able to replace jigsaw pieces with my PR, ill try and remember to change that to be a bit more modded friendly i guess. The point was to use it on vanilla though. A interesting thing that could potentially work with is what @cheaterpaul suggested, create your own custom JigsawPiece. Not sure at all how it works, but sounds interesting. It would count for only 1 depth and potentially when placing you could modify some stuff ? I would say its worth looking into.

you can just create the singleton piece and use a structure block to copy them, a bit tedious but better than changing how vanilla generates structures. For your problem of absolute height, a dirty solution could be to have multiple structures generate but with different Y levels each and then associate the correct pattern to each. Instead of having say MyStructure generate between x and y, have MyStructure_50 generate at y = 50, then figure out the max/min length your piece can be and voila. its going to be a bit less random for sure (and more tedious), but your structure does sound a bit weird. Not sure how complex your structure is, but if this is too much you could look into making a normal structure, without any jigsaws.

Instead of making your piece multiply itself, why not just make a pool of plenty of long pieces? like youd have one 10 piece long, one 15 long, one 42 long or whatever

Instead of making your piece multiply itself, why not just make a pool of plenty of long pieces? like youd have one 10 piece long, one 15 long, one 42 long or whatever

This is not a change from 1.16, it has been changed in 1.15 as well. DeferredRegister is a forge class if it became private it was intended, check the class to see what else is there

I have a simple item texture right now that works perfectly fine. I would like to however do an animation behind the current texture but only if certain conditions are met. Meaning this item could either have the current static texture or have an animated one (and you can have both versions in your inventory as well). I tried looking at ISTER since the shield and trident use it but I assume that is because they have a more complicated 3d model and not just a simple sprite (when in hand). From what I looked at in other mods github repo I need to define multiple layers to my item in the model json but could not find any sort of conditional object. What I would like (and assumed existed for items) would be some sort of blockstate mechanism, where i could define my cases like variants and have different models for each and then different textures.

Would need someone else to confirm but with their size definition it seems that Forge intends this event only for changing biome size. Using deferredWorkQueue will ensure that other mods will have properly done their stuff before the features are added. I don't know the details but it's basically a let forge handle it case.

Yeah so my idea does include to limit the possible configs. Since you can't register blocks from a config file, you have to register a specific amount. This also means you must have an addon per mod that add ores. It will indeed limit a lot the possible configs for a direct user. However, you could try and integrate an api for modpack creators that could then more precisely define and configure the details of your ores. I have been managing a mod with a lot of config options for the last 2 & 1/2 months and I feel that having easy configs is much better than having tons of config for direct users. In that mindset, limiting the possibilities of your config could improve user experience: having a config that is just changing 5 numbers and boom gold is super dense, coal less, iron and diamond medium and then they can play. (Reread what you said and not sure I understand what you mean by the density variant isn't the only thing you wanted? Also for the density levels, my bad thought that you were drawing multiple blocks per ore blocks...) Of course this is your mod not mine so if you really want mass configurability it doesn't seem to be possible purely using forge's config system. They also will not add any support for something like this since the "policy" is to always register everything, meaning it shouldn't depend on configs.

So even if it is generating I think that is still the wrong way to do it. I showed you my code on how to use deferredworkqueue. It can cause trouble if you load it immediately. If you take a look at the BiomeSize event, it tells you it is for modifying the biome size, so not at all what you need. For the offset my best guess is that they limit the distance between ground level and the ore? Not sure tbh...

A github repo would be nice. Also what do you mean not working. Is it crashing? if so provide the log. Is it not generating?

forgot a lot of rendering stuff had changed in 1.15, not sure if it applies to particles. Not at my setup right now so can't help more

Take a look at any Particle in vanilla