Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

TheA13X

Members
  • Content Count

    30
  • Joined

  • Last visited

Everything posted by TheA13X

  1. 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.
  2. 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).
  3. 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
  4. 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
  5. 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
  6. 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);
  7. 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
  8. Oh, sorry. I used the wrong jars. Starting the mod with the obfuscated versions worked.
  9. 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
  10. Great. I'll switch to that method, when making the mod for 1.10+
  11. 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
  12. 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"
  13. 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.
  14. 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)
  15. 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
  16. All right. I finally managed to look in the console output and I found THIS [16:10:53] [Client thread/ERROR] [FML]: Exception loading model for variant dendrology:leaves3#check_decay=true,decayable=false,variant=cedrum for blockstate "dendrology:leaves3[check_decay=true,decayable=false,variant=cedrum]" net.minecraftforge.client.model.ModelLoaderRegistry$LoaderException: Exception loading model dendrology:leaves3#check_decay=true,decayable=false,variant=cedrum with loader VariantLoader.INSTANCE, skipping at net.minecraftforge.client.model.ModelLoaderRegistry.getModel(ModelLoaderRegistry.ja
  17. Thank you for the help. I changed my code to: That's what I did: registering block and blockitem (on preinit) private static void registerLeavesBlock(Block block, String name) { block.setRegistryName(name);//value: UnlocalizedName<number> GameRegistry.register(block); GameRegistry.register(new ModLeavesItem(block).setRegistryName(block.getRegistryName())); Blocks.FIRE.setFireInfo(block, DEFAULT_LEAVES_FIRE_ENCOURAGEMENT, DEFAULT_LEAVES_FLAMMABILITY); } register block variants (using the Client Proxy and executed on init) public void registerBlockModel
  18. Look, I'm sorry. Guess I'll open an issue for EVERY major MC Version... I have a 1.8(.9) Mod and want to update it to 1.9(.4). Choonster's TestMod3 is a pretty good reference , but it doesn't work for me. Tell me what I've done wrong once again, please. That's what I did: registering block and blockitem (on preinit) private static void registerLeavesBlock(Block block, String name) { block.setRegistryName(name); //<-sets Registry name HERE to make it more dynamic //GameRegistry.register(block,block.getRegistryName()); //<- is
  19. All right. Found a solution. Learning by example is more interesting, than pure theory after all.
  20. You are right. I'd still rather make a mod for every MC release having a stable Forge version. Since I plan to "resurrect" more mods and there are people, who can't or don't want to play the newer versions (e.g. because of modpack compatibility), I need to know how mod in 1.8 as well
  21. No. As far as I know 1.8 is still supported. It's just that moderators normally don't try to persuade you to use newer versions, if the one you are working for is still supported.
  22. Just wanted to point out, that it is possible to set up a multi project workspace, just like in Eclipse. But you only need it, If one of your mods depends on another, or other reasons, why you want to load multiple mods at the same time. This saves you the building and copying your mods to the real minecraft folder. It works just like this one plus some fiddling around with the gradle files. I could make a tutorial for that. At least if you don't want to, seven.
  23. Yes it does. I'm talking about research, man. If I selled the mod, I would just need to know how to work with the newest version, since there are more people using it, but as a gamedev I want to learn how the different versions of forge/minecraft work. Not by looking at the deobfuscated code, the practical way. Alright, since this version is not supported anymore, I will ask the question in an unofficial forum, no problem. Thank you nevertheless.
  24. Sorry. You know how we germans are But seriously. I just want to know. Every knowledge can be useful, even how to mod outdated MC versions
  25. I'm updating an old Mod and I would like to update it to EVERY version. Already finished with 1.8. So 1.8.8 or 1.8.9 are next.
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.