Azaka7

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.

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.

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.

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).

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.

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.

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.

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.

You can still access Explosion.getAffectedBlockPositions(). Even though the List is final, you can still make changes to it, because it's an ArrayList.

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.

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.

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.

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.

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.

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.)

So I made a post in Modder Support asking for a way to replace vanilla crafting recipes in 1.14.4. No solutions have been posted, nor have I found a way. Right now, it seems that if a mod wished to replace a vanilla crafting recipe, it would need to include a separate data pack to be installed in world file. I'm requesting that forge reads mods' data/minecraft/recipes (or maybe all of data/minecraft/*) and replaces vanilla data files with those provided by mods. If this should be a bug report, I'll post there, but the EAQ said that section is for players, not modders, so I'm here. From the post in Modder Support:

Thanks. I did that and Lex gave it the "Forum" label, so I guess it's stuck here for now.

The recipe is already named the same as the iron chestplate recipe (that is, iron_chestplate.json) in data.minecraft.recipes, and it isn't overriding the vanilla recipe. I tried changing the pattern, but it didn't work. When I moved one of my normal crafting recipes to data.minecraft.recipes, it still registered as a new recipe, so it's not like the game is ignoring the location. I'm thinking it might somehow be a problem with forge itself.

I'm using the 28.0.45 mdk, the rest of my mod is working fine. I'm just looking for a way to remove vanilla recipes. The recipe is in iron_chestplate.json { "type": "minecraft:crafting_shaped", "pattern": [ "X X", "XXX", "XXX" ], "key": { "X": { "item": "minecraft:iron_ingot" } }, "result": { "item": "minecraft:iron_ingot", "count": 8 } } I have more un-recipes, but I figured I'd get just this one working first. Ideally, the output would be air, or nothing. It was working in 25.0.100 (for 1.13.2), but after updating it doesn't. (I had a custom serializer to toggle the recipes from the config file, but now a simple override doesn't seem to work.) I've tried in the following locations within src/main/resources: assets.minecraft.recipes assets.warforge.recipes data.minecraft.recipes data.warforge.recipes None of them seemed to work. In all cases, the recipe crafted a chestplate, which I'm trying to disable. While in the data.warforge.recipes folder, I tried using to command to enable the recipe in-game, but the vanilla recipe still won over. What am I missing? Is there a way to override vanilla recipes without a separate data pack to install? EDIT: I got recipe overrides to work by putting the recipes in data.[modid].recipes with the following solution of sorts: 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.

I know this was a while ago, but @Electric, did you find a solution? I'm having a similar problem.

http://www.minecraftforum.net/forums/mapping-and-modding/minecraft-mods/modification-development/2131995-custom-biomes-in-overworld Bada bing, bada boom!

Try adding GL11.glFogi(GL11.GL_FOG_MODE, GL11.GL_EXP); after you change the event.density. I'm not sure why, but it works for me.

Note: I've already written and submitted a PR for this. I would like an event that allows modders to check alter the contents of a brewing stand before the actual brewing takes place. The brewing event that already exists only takes place after vanilla brewing and the ingredient is removed. This event would basically allow for the adding of custom brewing recipes and alter existing recipes. Here's an example mod: This example mod would allow players to brew Jumping potions with Jump Boost (Amplitude 4 and Duration 1000) by brewing a piston into up to 3 awkward potions. The only problem I've encountered is that non-vanilla ingredients aren't normally allowed in the ingredient slot, so they have to be given a fake potion effect string (I applied the blaze powder string to the piston in this case). What this mod is doing is checking the slots for appropriate contents, then replacing the potions and reducing the ingredient stack is brewing occurs. Potion effects added by mods could be used in the brewed potion ItemStacks instead of a vanilla one, allowing mods to add brewing recipes for their own potion effects. I know this all can be achieved by reflection, but if any two mods take up the same brewing recipe identification (same bits used for metadata) they will be incompatible. This event will allow for near complete compatibility between mods adding brewing recipes using this event.

Before a version of Forge for 1.7.2 (can't recall the exact version), it was extremely difficult to add new biomes to generation. Now, it's much simpler. To add your biome to default generation, you can add your biome to a list in the BiomeManager class corresponding to your biome's climate type. For example: BiomeManager.coolBiomes.add(new BiomeManager.BiomeEntry(greatLake,10)); You can replace "coolBiomes" with any of the following: desertBiomes, warmBiomes, coolBiomes, icyBiomes "greatLake" is replaced with an instance of your biome. "10" represents the "weight" of your biome, how often it will occur relative to other biomes in the same list. You can add Ocean biomes using BiomeManager.oceanBiomes.add(shallowOcean); where "shallowOcean" is whatever biome you want to add, but these ocean biomes will not actually generate unless added to a different list as well.

I have a good idea on how to add new biomes without a new world type, but I haven't figured everything out yet. To add your biome to world generation without making a new world type, use the InitBiomeGens event. First, if you haven't made an event handler class for you mod, do so (just a plain class file). Register it in you main class using MinecraftForge.TERRAIN_GEN_BUS.register(new MyEventHandler()); replacing MyEventHandler with whatever you decided to name your event handler. You must register the handler with the terrain gen bus. Then, in your event handler class, use this anotated method: @SubscribeEvent public void registrerBiomes(InitBiomeGens event){ GenLayer layer1 = event.newBiomeGens[0]; GenLayer layer2 = event.newBiomeGens[1]; /* Your genlayer-altering code goes here! */ GenLayer event.newBiomeGens[0] = layer1; GenLayer event.newBiomeGens[1] = layer2; } You can rename the method to whatever you want, but the annotation and argument need to stay the same. You don't necessarily need the layer1 and layer2, but they're just convenient so you don't have to keep referring to the array. To alter the GenLayer, create your own GenLayerMod class (named whatever you want) that extends GenLayer and has a constructor similar to this: public GenLayerMod(long par1, GenLayer par2) { super(par1); this.parent = par2; // TODO Auto-generated constructor stub } You have it alter the world using the public int[] getInts(int par1, int par2, int par3, int par4){} method. To have your new gen layer class take control of world generation, use layer1 = new GenLayerMod(40L,layer1); layer2 = new GenLayerMod(40L,layer2); in the event method. Change the 40L to whatever default randomization seed you feel necessary. The getInts method will take over and that's where you'll get to play with the world generation. This is where I'm stuck. I've looked at vanilla genlayers, and they seem to control the biomes one square block at a time (x and z coords). I recommend using the GenLayerDeepOcean to start out with learning how to identify blocks, but Minecraft's vanilla code has it lucky. All vanilla biomes generate before the world is magnified, so each biome really only needs to generate in the area of a few blocks, then it's all expanded. What's left for us modders is an already magnified world with only the ability to control biomes 1 block at a time. I haven't come up with a good way to go about generating full-scale biomes yet. I really hope Forge eventually adds an easier way to generate biomes. So, overall, adding a new world type is probably the easiest way to generate new biomes.