Jump to content


  • Posts

  • Joined

  • Last visited


  • Gender
  • Personal Text
    I am new!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Azaka7's Achievements

Tree Puncher

Tree Puncher (2/8)



  1. According to the minecraft wiki in snapshot 19w36a "Biome information now stores Y-coordinates, allowing biomes to be changed based on height. However, this is not yet implemented." It looks like horizontally divided biomes will eventually become a feature. As it stands, there might be a roundabout way of accessing the biome y coordinate with reflection, but that comes with a whole host of issues. Your best bet, until it's implemented completely, is going to be to use a sort of jigsaw structure generation.
  2. You can force the model to skip normal rendering by canceling the event with event.setCanceled(true). The plus side is you'll be able to do exactly what you want with the model. The down side is you'll have to write the entire rendering method, including rendering sleeping/sneaking conditions as well as nameplates.
  3. Azaka7


    Version 1.7.10 is no longer supported on these forums. Update to a newer version for support here. That being said, there are a number of tools for converting models to java for Minecraft 1.7. There are plenty of tutorials for 1.7 modeling. Using only cuboids will be your best bet. Unless the mod is developed for a recent version of Minecraft, you're going to have to stick to googling for more help.
  4. I don't know if there is a more correct way to do it, but here's how I do it: - Set up a 1.15.2 workspace with the mdk download and running the gradlew for your ide - Copy the contents of the src folder from your 1.14 project to the src folder for the 1.15.2 project. - Open the 1.15.2 project in the ide. There should be a bunch of errors. - Go through each and every error and look for a similar way to accomplish the same task in 1.15.2. The update from 1.14 to 1.15 is relatively simple compared to version changes where the entire code structure was rewritten (i.e. when number ids changed to namespaced ids, and when data packs were implemented over hard-coded recipes and loot).
  5. If you're using Eclipse, in package explorer (where your src/main/java and src/main/resources are) look for Project and External Dependedncies: The first one contains all of the main game code. This is where all the important stuff you should look through is. The second one is just launcher code, which you can pretty much ignore 99% of the time. The third one, "client-extra", is where you can find Minecraft's resources, like images, models, recipes, etc. It's a nice reference to have on hand. The weird names like "p_146231_1_" are just auto generated names from decompiling Minecraft's code. Forge does its best to rename them automatically, but not every variable can easily be accounted for. I think the community can help contribute to the translation in the Forge GitHub.
  6. I'm not aware of any event that allows you to change the weights of enchantments, although you can use the following method in your Item class to restrict the types of enchants that can be applied: public boolean canApplyAtEnchantingTable(ItemStack stack, Enchantment enchantment){} It is called every time an ItemStack of that Item is enchanted, so you could in theory add some randomization elements, though you might need to do some server-client syncing.
  7. I think you want the mod to be installed on the player's client, right? Even in Single Player, both a server side and client side run side-by-side. Like imacatlolol said, the client side doesn't access world information, even in single player. The method I pointed out will work in single player worlds by targeting the game's server side without having to be connected to a dedicated server.
  8. You can access it on the server side. Check if the World is an instance of ServerWorld. If it is, use ((ServerWorld)world).getServer().getFolderName(). If you don't check if the world is an instance of ServerWorld, then getServer() returns null on the client side.
  9. You can still access Explosion.getAffectedBlockPositions(). Even though the List is final, you can still make changes to it, because it's an ArrayList.
  10. Did you install the same version of Forge to the client as you used when making your mod? The error log is referencing Food.Builder.effect(Supplier,float). That method was changed in Forge build 1.15.2-31.1.5, which might be what's causing conflict if you're using different versions.
  11. Unfortunately, it DOESN'T work in the latest 1.15.2 mdk (forge-1.15.2-31.1.50-mdk). As it stands, the issue IS on the github at https://github.com/MinecraftForge/MinecraftForge/issues/6287 although it's labeled for 1.14.4. If you want me to create a new issue on the github for 1.15.2, I'd be happy to. I know you'll ask for a reproduction case. Do a clean install of the mdk, add the package "data.minecraft.recipes" in src/main/resources. In the package, create "diamond_chestplate.json" with the contents: { "type": "minecraft:crafting_shaped", "pattern": [ "X X", "XXX", "XXX" ], "key": { "X": { "tag": "forge:gems/diamond" } }, "result": { "item": "minecraft:air" } } The recipe does NOT override Forge's own diamond_chestplate.json. The override DOES work if you disable the datapack "mod:examplemod" in game (where forge re-enables it). Until the issue is resolved, I don't see why we shouldn't resort to "hacky things" while waiting on a fix, especially if they're straightforward and fix the problem at hand.
  12. I found what was wrong, and it WASN'T my mod. FML Ships with the "Forge" mod, which has its own data pack resources. Among these resources are crafting recipes that make vanilla recipes use item tags to work with other mods' items. It turns out that in some (not all) cases, the Forge recipes were overriding my mod's own files that would remove vanilla crafting of armors. My solution for now is to reload my mod's resources on world load. Here's my solution: @SubscribeEvent public void onServerStarting(FMLServerStartingEvent event) { LOGGER.info("Artimancy is unregistering it's own data pack so that Forge will reload it and override every other datapack."); MinecraftServer server = event.getServer(); server.getCommandManager().handleCommand(server.getCommandSource().withPermissionLevel(2), "datapack disable \"mod:artimancy\""); } After disabling my mod's data pack, Forge Mod Loader is so kind as to reload them over every other data pack (namely, the Forge data pack). Ideally, I shouldn't have to do this. Ideally, FML should prefer other mods' resources over Forge's resources, since Forge is the "default" mod that ships with FML.
  13. I'm using the latest Forge MDK for 1.15.2 and the HarvestDropsEvent event sill isn't being fired. Other types of BlockEvent are fired. I used Eclipse to search for references, and found that while there IS a method that posts the HarvestDropsEvent, that method is never called. Basically the event is never fired unless fired by a mod. I think this is a bug.
  14. So I found something. I don't have any clue how it makes any sense, other than the "warforge" ID seems to be cursed. I did a clean install of the mdk and started testing mod IDs on the example mod after putting some recipes in the right locations. Other than "warforge" and "example mod", I tested "mhmod", "mjmod", "rmod", and "exampleforge", all in the clean install. ALL of them were able to replace the vanilla recipes EXCEPT "warforge". I want to do more testing because so far I haven't seen a pattern. Edit: Another mod id that doesn't work is "watforge". However, the following do work: watercraft, warcraft, abcforge, catforge (don't judge), wipforge, airforge. I'm done. Just giving up on this and changing to a new mod ID. At this point I just don't understand.
  15. Thanks for the reply Lex. As I said in my post, it WAS working in 1.13. I understand there were changes, and I've solved them for the rest of my mod. My only problem is that after moving to 1.14.4, the recipes were no longer overriding the vanilla ones. I only started "throwing recipes all over the place" to see if the correct location had changed. Logically, the recipe should be in data/minecraft/recipes, but that doesn't seem to work. You're correct that normal data packs work if installed in the world folder. My problem is that it seems like Forge isn't stacking my mod's data pack on top of vanilla recipes without installing the mod in both the mods folder AND the world folder (something that shouldn't be necessary). I'll try to put together a reproduction case for the problem I'm having if I can't get it to work in the next week. That being said, I would love to see Forge implement a system where mod resources override Minecraft resources all the time, rather than just seeing which resource his first. (There was another issue with overriding a vanilla texture, which was fixed-ish be making my mod's resource pack visible and moving it over Minecraft's pack.)
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.