TheA13X

No. No they are not. I Debugged Forge's building process line by line, so I know that the all registry events are fired after the FMLPreInitializationEvent. Also if the Registry Events were fired before the lists are populated, there would be no exception in the first place.

Hi there! I'm currently updating one of my mods to 1.12 (and 1.12.2). While doing that I ran into this exception: Here's what I found out so far: The exception is caused, because the Lambda Functions, given to the Search Tree as an argument, returned null: //Citing Minecraft.java /*618*/SearchTree<ItemStack> searchtree = new SearchTree<ItemStack>( /* */(p_193988_0_) -> /*619*/{ /*620*/ return (List)p_193988_0_.getTooltip((EntityPlayer)null, ITooltipFlag.TooltipFlags.NORMAL).stream().map(TextFormatting::getTextWithoutFormattingCodes).

So there's an abstract function called getWoodtype which returns a BlockPlanks.EnumType and I wanted to return the enum type of my Mod's Planks, but that's completely unnecessary. I extended the class and it works now (apart from a visual glich due to the transparency, but that's another story) Thanks

Yes I can. Sure it's a matter of trust since it could break if someone calls the function outside of a client-only class, but I'm the only author, so it won't happen. It's in the part of the class I left out and replaced it with I don't even know anymore. Let me check this

You misunderstood me. They do NOT Decay, but I want them to. Also I just noticed I forgot to paste the properties in there. It's fixed now. I just updated 1.7.10 code from another author. I thought about recoding it completely to make it more uncomplicated, but this can wait. Also registerBlockModelsis called from the client proxy. It's just positioned in the block class to allow different behaviour for every single block. It's just clearer that way. Like the comments say I cloned MCs BlockLeaves Class and cut out the old functions, since they are t

Wow that was fast. Thanks man ^^ Well, first we have the Superclass: public abstract class LeavesBlock extends Block implements net.minecraftforge.common.IShearable { public static final int CAPACITY = 4; private static final int METADATA_MASK = CAPACITY - 1; int[] surroundings; private final ImmutableList<DefinesLeaves> subBlocks; protected LeavesBlock(Collection<? extends DefinesLeaves> subBlocks) { super(Material.LEAVES); checkArgument(!subBlocks.isEmpty()); checkArgument(subBlocks.size() <= CAPACITY);

Hello world. I'm making a Tree Mod and it turns out, that my leaves won't decay. When a tree get generated, all leaves are set with the standard block state (aka with decayable and check_decay set to true). After the generation most leaves have check_dekay set to false. Since this is also the case with vanilla leaves I guess that's normal though. When chopping down a tree (minecraft style) the leaves won't decay and after restarting the game the leaves have both decayable and check_decay set to false Things that may be important to notice, is that my L

Oh, sorry. I used the wrong jars. Starting the mod with the obfuscated versions worked.

Hello world. Another error I don't understand, but may be easy to solve if knowing how forge works. When starting the mod on forge 2228 in IDE everything is fine, but if its loaded in the client I get There was a severe problem during mod loading that has caused the game to fail net.minecraftforge.fml.common.LoaderExceptionModCrash: Caught exception from Ancient Trees (dendrology) Caused by: java.lang.NoSuchFieldError: CHESTS_VILLAGE_BLACKSMITH CHESTS_VILLAGE_BLACKSMITH is a static field from the LootTableList, which definitely does exist. Code wher

Great. I'll switch to that method, when making the mod for 1.10+

Oops. I'm sorry for making you so much work. At least the outdated build.gradle and the obsolete ProvidesPotionEffect implementation could be avoided if I had a Git client I can handle. Thank you for the tips though. My code is pretty chaotic regarding the location of proxied functions, but I works. I never had a crash because of some non-server code. Well that's interesting. I'll keep it in mind. See, I implemented the Item spawning on both the common and the client proxy. The common one just returns the Item, the client side adds a translation first. Maybe it isn't ought

I know. That's what I normally do, I just had to do it this way, because the client told me that "everything is up to date"

Oh yeah. Didn't notice, sorry. I fixed it now (for 1.9) Not in the git repository. I have a multi-project-workspace in IntelliJ, so the settings file is in the superdirectory. I'll add the KoreSample repository as a submodule after I figured out how, but you'll have to create the settings.gradle yourself. I just didn't know it's possible back then.

IntelliJ's output directory is project/build/classes I have a git repository for the mod LOOK Wait. it hasn't updated to 1.9... Now it has. (1.9 branch) You'll also need it's dependency. Found here (1.9 branch)

Are you sure? It's a FileNotFoundException which usually contains the path used for an I/O operation which is usually the real path. Anyways. The assets folder is in src/main/resources like it should. It's also included in to the root folder of the mod's jar file. I've run the mod only over the IDE though and while the assets folder does exists in build/resources/main the IDE's output folder is build/classes/main. But it should work anyway right? I mean the assets is copied to the build folder. Also I have a custom LanguageMapper who reads the lang files on pre-init and if the asse