warjort

Another option would be to use an ItemTag that would contain the items that give reduced explosion chances. You would have the vanilla picks by default, but users could add other tools.

Older versions of minecraft used tool types, but this was all reworked. The new logic uses: If you look at the PickaxeItem/DiggerItem this checks the tier of the tool then checks if the block is in BlockTags.MINEABLE_WITH_PICKAXE So you could just use that method passing your block state. Alternatively If the tool is vanilla, or a modded pick that reuses vanilla code, you could do if (player.getItemInHand(InteractionHand.MAIN_HAND).getItem() instanceof PickaxeItem) but not all modded picks are PickaxeItems. And other non-picks might use the BlockTags.MINEABLE_WITH_PICKAXE, e.g. drills or hammers.

Errors in currently selected datapacks prevented the world from loading. What is the actual error in your run/logs/latest.log? Probably a parsing error or something not found.

Sorry, the code I posted is the getter. There isn't a setter, so you would have to use an access transformer to modify the private field.

RenderLevelLastEvent is just an event like you used EntityViewRenderEvent. The event is fired after all the other renderering has been done, use it to draw what you like. BlockEntityRenderer is used to manually render block entities, like drawing a chest opening and closing. I don't know how it could be used for this?

Each dimension type is meant to represent a new dimension.

It still exists it just moved. It is in DimensionSpecialEffects. I have never used it myself, but the navigation is something like. ClientLevel level = ...; DimensionSpecialEffects dse = DimensionSpecialEffects.forType(level.dimensionType()); dse.forceBrightLightmap();

this says you are not It thinks you want to run with a main class called forge-1.16.5-36.2.34.jar while you actually want to execute the jar.

Your command is wrong, you are missing the -jar option C:\forge>java -jar forge-1.16.5-36.2.34.jar

The vanilla pickaxe recipe uses a tag for planks (it accepts any wooden planks). This will make it difficult to change just for crimson planks, you can't just remove crimson planks from the planks tag because that would affect other recipes. You would probably be better off using a different shape for your recipe and leaving the vanilla recipe in place. This also means your pick won't be affected if some other mod changes or disables the vanilla pick recipe.

I don't know much about this, but I do know you can't use the fog for this. The fog is designed to limit the player's view distance, e.g. if they are in lava or water, but mainly so the game doesn't have to draw all the way to "infinity". This means all the fog rendering code is based on the distance to camera. It's an illusion, it's not based on something physically in the world at some position. Spit balling: I would guess you want something more like how clouds are drawn? But again these are partially an illusion. They are procedurally generated rather than being physically in the world, but they are kind of drawn at a location. You can use forge's RenderLevelLastEvent to draw over the world. Look at LevelRenderer.renderClouds() for how clouds are drawn.

Its location depends upon which java you installed. Open c:\Program Files in explorer (the windows program that lets you look at folders) and type java.exe in the search. This should find all the javas you have installed.

Is this a modded pickaxe you created? Post the code for your pickaxe, in particular isSuitableFor(BlockState)

Spotted it, your parameters are in different orders

I just downloaded and ran your mod and now I can see the real problem. You have recursive death for your WallSignBlock.getDescriptionId() The way this works in vanilla is that the StandingSignBlock and WallSignBlock both share the same SignItem. The SignItem is linked to the StandingSignBlock which holds the description. The WallSignBlock does this.asItem().getDescriptionId() which is supposed to do the redirect to the StandingSignBlock via the item. In your case this isn't working. There is something wrong with the way you are registering these blocks/items. Your SignItem seems to be linked to the Wall block when it should be linked to the Standing version? It is not obvious to me what you are doing wrong in your code though.

This looks like something has gone wrong with a download by curseforge. Forge was told to launch using those files but they don't seem to exist. Do they exist? Another possibility is they do exist, but you don't have the operating system privileges to open them or maybe they are broken. There is this error in one of your other logs about a failed download, but it claims to have corrected itself.

You need to post you debug.log, see the stick post at the top of the forum. I can't tell from what you posted what are errors and what are warnings. The one that is an error is for snownee: But that might be caused by the other problems if they are errors (like I said I can't tell). The problems say you have a conflicts between 2 different sets of mods (but these might just be warnings); youngsapi and repurposedstructures rubidium and iris I would suggest checking the mod's download and issues pages and using their discords to see if these are known problems.

Actually it is with the entity's eye position.

Are you sure the pos is correct? Forge has a ExplosionEvent.Detonate that will pass a list of potential entity targets. Does your player appear in that list? You might also check some of the other data in the Explosion object passed on that event. However: There's also a piece of code in the Explosion class that looks like it checks the entity's distance to the explosion, if it is zero they are excluded from damage! It looks like this is done to avoid a divide by zero issue? If you are using the player's position for the explosion you might be getting caught by this? Try moving the explosion position upwards by half a block.

I don't think you explained this very well. Its seems like you are saying some descriptor ids (which ones?) are blank in the resulting language file. You don't show the resulting file. You are generating the language file in that ATWLanguageProvider. Your log snippets doesn't show any blanks. Are these the ones that are blank in the file, they are all vanilla names? Are they blank because your code is being passed wrong data, it is not being passed data or something else?

Sounds to me like you are writing an xray? 🙂 You can use forge's RenderLevelLast event to draw anything over the top the world rendering. I'll leave it as an exercise how you draw the glowing block outline in perspective.

I know very little about banner patterns but wouldn't this just be something like? @Mod("examplemod") public class ExampleMod { private static final DeferredRegister<BannerPattern> BANNERS = DeferredRegister.create(Registry.BANNER_PATTERN_REGISTRY, "examplemod"); public ExampleMod() { IEventBus bus = FMLJavaModLoadingContext.get().getModEventBus(); bus.addListener(this::setup); BANNERS.register(bus); } private void setup(final FMLCommonSetupEvent event) { BANNERS.register("mybanner", () -> new BannerPattern("myb")); } } Registry is the vanilla registry, its not deprecated, there is no special forge version.

I think you probably also wants the gems as texture2? The overlaying texture should be drawn after the main texture.

That wiki post from earlier says: " texture: Specifies the texture in form of the texture variable prepended with a #." So you can't directly reference the texture inside an element, you need to use texture variables. Something like - you will need to change them all, I only changed the first one. { "parent": "minecraft:block/block", "textures": { "particle": "kanohicraft:block/lightstone_block_deepslate", "texture1": "kanohicraft:block/lightstone_block_deepslate_gems", "texture2": "kanohicraft:block/lightstone_block_deepslate" }, "elements": [ { "from": [ 0, 0, 0 ], "to": [ 16, 16, 16 ], "faces": { "down": { "texture": "#texture1", "cullface": "down" }, "up": { "texture": "kanohicraft:block/lightstone_block_deepslate_gems", "cullface": "up" }, "north": { "texture": "kanohicraft:block/lightstone_block_deepslate_gems", "cullface": "north" }, "south": { "texture": "kanohicraft:block/lightstone_block_deepslate_gems", "cullface": "south" }, "west": { "texture": "kanohicraft:block/lightstone_block_deepslate_gems", "cullface": "west" }, "east": { "texture": "kanohicraft:block/lightstone_block_deepslate_gems", "cullface": "east" } } }, { "from": [ 0, 0, 0 ], "to": [ 16, 16, 16], "faces": { "down": { "texture": "#texture2", "cullface": "down" }, "up": { "texture": "kanohicraft:block/lightstone_block_deepslate", "cullface": "up" }, "north": { "texture": "kanohicraft:block/lightstone_block_deepslate", "cullface": "north" }, "south": { "texture": "kanohicraft:block/lightstone_block_deepslate", "cullface": "south" }, "west": { "texture": "kanohicraft:block/lightstone_block_deepslate", "cullface": "west" }, "east": { "texture": "kanohicraft:block/lightstone_block_deepslate", "cullface": "east" } } } ] }

Don't you have your config as a singleton in your mod for use at runtime? You could just make your ICondition implementation reference a map like you say, except it would be a map of strings to "getters" for your config. Something like: public class MyMod { public static YourConfig configSingleton; public static final Map<String, BooleanSupplier> conditions = new HashMap<>(); static { conditions.put("option1", configSingleton::isOption1); conditions.put("option2", () -> somethingMoreComplicated()); } } Maybe I am misunderstanding the problem?