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

For particles there are 4 things: Particle ParticleType IParticleData IParticleFactory Having BasicParticleType covers the ParticleType and IParticleData Next you need a class that extends Particle (or TexturedParticle or SpriteTexturedParticle), in it you implement what you need (motion, texture, rendering). You finally need a class (I nest it in my Particle class) that extends IParticleFactory, it'll have a makeParticle function (i think that is the name) that will take as a parameter your registered ParticleType and return an instance of the particle you created above. For a simple particle BasicParticleType is fine, about 90% or more of vanilla particle use it. For more complex particles, you need a proper ParticleType and IParticleData, you can look at how vanilla does it in its redstone particle.

Okay so thought your block was much more generic, I think there's a way to make it work then. Only certain blocks can be modified: ores. For each ore you generate different textures (haven't looked at how you do it specifically) but those textures are in a fix amount right? If you were to have 5 compacting levels per ore, you could pre generate each of the 5 blocks per ore. Those blocks would have an identical loot table with which you could add a function like density. The value for density would be taken from the config file (mimic a fortune modifier maybe?). That way all blocks are already generated before config kicks in. Not sure if this is what you want, as they wouldn't be blockstates. You would also need to check if another mod is loaded before generating your own ores that depend on other mods. If you want even more config possibilities you could have 10 compact blocks per ore and have some not be included in ore gen depending on configs. If you think that creating all those blocks would be a waste/not the best way, think about chisel that creates about 10 blocks per block and you only do that on ores, so won't be that much.

oh right i was on 1.14. Only thing I can offer you right now is your method names 1st one is withConfiguration 2nd one is configure

Ah yes it is outdated, and do tell people when you are copy pasting documentation. And yes data packs allow you to completely override vanilla loot table. Here is the info on the wiki: https://minecraft.gamepedia.com/Data_pack In a dev environment you place your json in resources/data/minecraft/loot_tables

Seems outdated to me (could be wrong), try doing this: https://github.com/SilentChaos512/ScalingHealth/blob/1.14/src/main/java/net/silentchaos512/scalinghealth/world/SHWorldFeatures.java#L22 You need to use deferredWorkQueue for ore gen as in https://github.com/SilentChaos512/ScalingHealth/blob/1.14/src/main/java/net/silentchaos512/scalinghealth/SideProxy.java#L47

You do that with data packs which you can read about on the official minecraft wiki. Also are your really on 1.15 ? EntityLiving is 1.12...

Could you explain a bit more what you mean by properties? Like the actually code defined Block#Properties? Also, if any of those blocks are tile entities your block will as well need to be a tile entity (pretty sure). How would your config system define the blocks ? Are you trying to make it so that anyone could mix together any number of blocks any number of times? (Have 1 wood-brick block and at the same time a gold-wool block? Also what purpose will your mod serve? Is it for modpack creators or for direct users?

Pretty sure this is 1.12 ... which is no longer supported so please update to a newer version (1.14 or 1.15)

well same difference. You should be able to know to what extent they can serve. It's a basic in a lot of OOP

Please update to 1.14 or 1.15 this version is not supported. (and there is no reason to be on this version as well)