IceMetalPunk

I've showed you how to get the player's position, get a chunk from a position, get the tile entity map from a chunk, and get the size of a map. That should be everything you need. Try out the code you think will work, and if it doesn't work, show us the code you've tried and we'll help you further from there.

You can get a map's size with Map#size() and a player's position with Entity#getPosition().

Perhaps these methods will point you in the right direction: World#getChunkFromBlockCoords(BlockPos pos) = Returns the chunk at the given position. Chunk#getTileEntityMap() = Returns a map of BlockPos to TileEntity; that is, it returns a Map<BlockPos, TileEntity> containing all the loaded tile entities in that chunk.

With RedPlusPlus released and done, I've started work on another mod. For it, I'll need to alter existing biomes, and I don't have much experience with modding Biomes, so I started the project by playing around with the relevant classes and just testing things. For the first test, I wanted all Swamps to generate with a layer of blocks just above all the water that has sky access (before trees, etc. are generated). I randomly picked magma blocks, and came up with this code (the class is registered in the RegistryEvent.Register<Biome> event, and overrides the default vanilla minecraft:swampland registry entry): public class BiomeMitaSwamp extends BiomeSwamp { public BiomeMitaSwamp(BiomeProperties properties) { super(properties); this.setRegistryName("minecraft", "swampland"); } @Override public void genTerrainBlocks(World worldIn, Random rand, ChunkPrimer chunkPrimerIn, int j, int i, double noiseVal) { super.genTerrainBlocks(worldIn, rand, chunkPrimerIn, j, i, noiseVal); int x = j & 15; int z = i & 15; for (int y = 255; y >= 0; --y) { boolean isWater = (chunkPrimerIn.getBlockState(x, y, z).getMaterial() == Material.WATER); boolean isAir = (chunkPrimerIn.getBlockState(x, y, z).getMaterial() == Material.AIR); boolean isUpAir = (chunkPrimerIn.getBlockState(x, y + 1, z).getMaterial() == Material.AIR); if (!isAir) { if (isUpAir && isWater) { chunkPrimerIn.setBlockState(x, y + 1, z, Blocks.MAGMA.getDefaultState()); } return; } } } } It almost works. The magma block layer does generate above water in swamps, but there are patches of water that don't have the layer above them. The patches have no blocks above them, are not rectangular, are not on chunk borders.... in short, I can't find any commonality among the patches, yet there are many of them amidst the magma blocks. What would cause this code not to generate a magma block above water, in a swampland, with no other blocks above it? I can't see the flaw here.

I didn't know that was a thing. Seems about as easy to use as the script anyway; but thanks for letting me know I have options EDIT Plus, that command can be simplified even further: grep -w './build/taskLogs/retroMapReplacedMain.log' -e "openCount" | awk -F: '{print $2}' (All it does is search the map replacement log for the field in question, then passes the matched lines to awk to split it up at the colon delimiters.)

RedPlusPlus RedPlusPlus (not to be confused with the different RedstonePlusPlus) is a mod that focuses on adding vanilla-style enhancements to your redstone work. It's an update of my older Red+ mod for 1.7.10, with the following focus: Update to 1.12! Even when Red+ was released, 1.7.10 was already becoming obsolete. Time to have a modern mod! Simplify! While Red+ aimed to have vanilla-style additions, it also added quite a few things that would seem very modded (block breakers, placers, quartz golems, etc.). With RedPlusPlus, I've added fewer features, but focused on making sure they fit the vanilla theme. Everything in this mod, except the easter eggs, are things I could see being added to a future vanilla Minecraft version -- and that's how it should be! Utility! Red+ had some features that were a bit useless, like glass buttons or golden doors. I've aimed to make sure every feature of RedPlusPlus has a utility, because redstone is all about functionality! Download: https://github.com/IceMetalPunk/RedPlusPlus/raw/master/build/redplusplus-1.0.jar Source: https://github.com/IceMetalPunk/RedPlusPlus With that said, here are the features of RedPlusPlus: New Blocks & Items: Feature Description To Unlock Recipe... Redstone Counter Right-click to cycle through numbers 0-15; emits a redstone signal equal to its displayed number. Obtain a comparator Analog Lamp Emits light with brightness equal to its highest redstone input. Obtain Nether quartz Redstone Wrench Right-click a directional block with this to rotate it so it faces where you clicked. If you click the front of a block, it will flip to face the opposite direction. Obtain redstone Golden Button Produces a 1-redstone-tick (2-game-tick) redstone output when pressed. Can be pressed repeatedly and quickly by holding right-click/Use Item button. Obtain a gold nugget Player Pressure Plate A pressure plate that can only be activated by players. Obtain a diamond Redstone Meter Right-click any block with this to get its indirect power level. Useful for debugging redstone devices. Obtain a Redstone Wrench Trapped Shulker Boxes Just like a shulker box, but emit redstone when opened like a trapped chest. Strength is equal to the number of players looking in the box; will power strongly through the block it's attached to, weakly in the other 5 directions. Obtain a purple shulker box and a comparator (not necessarily at the same time) Heavy and Light Smart Plates Act like heavy and light pressure plates, but count individual items in a stack rather than counting item stacks as a single entity Obtain a comparator Secret stuff... It's a secret! Two can be unlocked in secret ways; one you must craft on your own, without Recipe Book help Tweaks: Lava pushes mobs like water; great for Nether farm transport. Dispensers will plant crops/seeds/saplings if faced into a suitable planting block (dirt, farmland, soul sand, etc. depending on crop) Dispensers with wrenches will rotate the block they face around the axis they face. Dispensers will place gravity blocks in the world (sand, gravel, anvils, concrete powder, etc.) The secret things are secret because they don't quite fit with the mod's theme; two can be unlocked in survival Minecraft if you do things right, one can't, and none of them are in the Creative menu. The one that can't be unlocked can still be crafted (as long as your doLimitedCrafting gamerule isn't turned on), so if you can figure out the recipe, you've got something new Video Spotlight Coming Soon-ish! Download: https://github.com/IceMetalPunk/RedPlusPlus/raw/master/build/redplusplus-1.0.jar Source: https://github.com/IceMetalPunk/RedPlusPlus

I was just about ready to release my new mod, and then I built it and tested it fully...and it crashes. Why? Because part of my code uses the ReflectionHelper to get a private field's value from a vanilla tile entity class, but I only know the deobfuscated name, and so in the build version (when everything is obfuscated again), that field doesn't exist. How do I find the obfuscated field names to access with the ReflectionHelper? I've looked in MCP's conf/fields.csv file, but the field I'm looking for is not listed there. The field, by the way, is TileEntityShulkerBox#openCount. In the development environment, accessing that field with the ReflectionHelper works; but without the obfuscated identifier, it completely crashes in the production environment. Please help? It's so close to release ;~; EDIT Well, instead of panicking, I should have Googled for five more minutes before I posted this... I found it For anyone reading, I found this nice Bash script that finds all the rename map entries for a given field name (when run from your modding directory): grep -rnw './' -e "openCount" | awk -F: '/RENAME MAP/ {print $4}' (Obviously, you can change the "openCount" to the field name you're looking for.) It outputs every matching field, its obfuscated version, and the class it's found it, which is all very useful. In this case, TileEntityShulkerBox#openCount is mapped from a field named field_190598_h, so I added that to the parameter list for my ReflectionHelper's call, and boom, everything works now (After looking into it a little more, a faster script is this: grep -w './build/taskLogs/retroMapReplacedMain.log' -e "openCount" | awk -F: '/RENAME MAP/ {print $2}' ; that is assuming the map replacement log is in the path for every version of Forge, though, which might not be a valid assumption.)

Honestly, I've never had much luck with substitution aliases, either. According to sources, it was finally fixed in 1.10.2, but I have no experience with that. The 1.12 registry overriding is much easier, but of course that's not available for 1.10.2. Hopefully someone else with more experience can help you figure out how to use substitution aliases (but the general idea is the same: it replaces all references of one block, such as the vanilla one, with your own class instead).

Depending on what version you're using, I'd use either a substitution alias or the newer method of simply overriding the block registry entries to replace the vanilla block with your own class. It should extend the vanilla block class, but then change the code in the random tick method to check the weather and do something accordingly. Note: I haven't tried the method of overriding vanilla blocks yet, and I know it's fairly new to Forge for 1.12, so there may be bugs, but try it out first and see if it works.

Well, yay! Updating solved the issue; looks like it was an early Forge bug after all! Time to switch everything over to JSON files and then I can release my mod Thank you, Leviathan, for your help!

Ah. I'll update and see if that helps (I'm currently using version 1.12-14.21.0.2349). Thanks for letting me know.

I've been searching and pulling my hair out over this with no luck . Can anyone help figure this out? It's the only thing standing in the way of releasing my mod at this point. Let's say I end up going back to using the GameRegistry#addShapedRecipe variants instead of json files; other than having the recipes always unlocked, are there any other drawbacks to it? Because I might just end up doing that unless there's a problem with it I'm missing.

AFAIK, there's no event that fires when the world is first *created. But once you generate a location, you already know the location has been generated, so the very existence of a non-null location should tell you "I've already done this, don't do it again." In other words, as long as you save the location to the world data and only generate a new one if the existing one is null, you can do this from anywhere, it doesn't have to be only when the world loads. This page of the Forge docs may come in handy with this: https://mcforge.readthedocs.io/en/latest/datastorage/worldsaveddata/ But keep in mind that the structure can't be built in unloaded chunks, so you're better off *actually generating* the structure in a World Generator rather than when the world loads. So you can just have everything in the world generator and generate the location there when none exists.

A Null Pointer Exception means you're treating a variable like an object, but it actually holds null (or "nothing") in it, so it doesn't have the methods you're trying to use. This error tells you the problem is in your ItemHammer.java file on line 35. So check there and see what variables you're trying to access, and then you can start thinking about why they might not have an actual object like you're expecting. Hint: Look at how many different constructors RayTraceResult has, and look at which one you're using. (Also, take V0idW1k3r's advice in general; but for the NPE, look at the constructors.)

That is good to know! Thank you.

The RegistryEvents were added after my last modding project (from 1.7.10) -- is there a list somewhere of which classes have a full registry and fire Register<T> events? Or does an event fire for every class that implements IForgeRegistryEntry, including IRecipes?

So you want to replace only *some* Jungle Hills with your biome, but not all? That's the opposite of what you said ("every biome of a certain type"). I'd suggest you use the same method, but before you overwrite the Jungle Hills registry entry, you grab it and store it with Biome.getBiomeForId(int id) (for Jungle Hills, the registerBiomes method shows an ID of 22, for reference). Then replace the registry entry with your own, passing the captured Jungle Hills biome to the constructor for storage. Then, in your own Biome class, you can call the default Biome's methods whenever you want (for instance, call the default 90% of the time, but skip that and call your own the other 10%).

I don't know if this is the best way, but there is a Biome Registry (Biome#REGISTRY) which maps all the resource locations to biome classes. You could, I suppose, replace the class associated with the resource location of your choosing with your own biome class. The registry is public, so you should be able to just call, for instance, Biome.REGSITRY.register(plainsID, new ResourceLocation("minecraft", "plains"), new MyNewPlainsBiome()) or something similar. The plainsID is the ID of the plains biome (1), but depending on which biome you're replacing, you'll need to change that to the proper ID (they can all be found in the Biome#registerBiomes method). That should work (though I'm not 100% sure, so test it out). Never mind; there's a much better way to do this. Just call Biome.registerBiome(ID_TO_OVERWRITE, "biome_name", new YourBiome()), with the arguments changed to the appropriate values (ID_TO_OVERWRITE being the IDs from Biome#registerBiomes, same with the name, and then an instance of your actual biome class).

Wait, no... it still doesn't work even if I unlock the recipe in the PlayerLoggedIn event. And when I think about it, that can't be the problem: even if I unlock all recipes with the /recipe give @a * command, and it says all recipes are successfully unlocked, it still doesn't show up in the recipe book, even though it can be crafted manually just fine. The advancements only control when the recipes are unlocked, so that can't be the issue. So am I missing some step here?

Ohhhh, wait, that's right. They're only added through advancements, not by default, aren't they? That's a bit annoying, as it means I need to now figure out what states should unlock each of my recipes...or I could just leave it unlocked by default (I'm fairly sure I remember seeing an EntityPlayer method for that), though that then seems weird to have some advanced blocks/item recipes unlocked before the most basic recipes... Hm, this recipe book is cool, but it's adding more logistics for modders to worry about I'll see what I can do about it, and either I'll figure it all out and mark this topic solved, or I'll come back asking for more help. Thanks.

Aha! A little bit of fiddling later, and it all works now! Thank you! Now if I could only figure out why I can't get .json-style recipes to show in the recipe book, my mod will be ready for release!

You can find the full log here: https://www.dropbox.com/s/tplz3325pvw6xk6/fml-client-latest.log?dl=0 (The errors begin on line 393.) But as far as I can tell, it doesn't give much more information than a "missing variant" for each of the colors; yet unless I'm missing something, I've defined all those color variants in my block state file.

You know, I've been working with my subclass for so long I forgot there even was a FACING property to think about >_< . Unfortunately, that didn't seem to fix the issue. I changed the state mapper code to this: ModelLoader.setCustomStateMapper(this, new StateMapperBase() { @Override protected ModelResourceLocation getModelResourceLocation(IBlockState state) { return new ModelResourceLocation(RedPlusPlus.MODID + ":trapped_shulker_box", BlockTrappedShulkerBox.this.getColor().getName()); } }); And I'm still getting the same errors, although now it's for every FACING state of each color:

Ugh. So I went the route I mentioned, creating a block state with a "color" property so that each block instance would have its proper color state set, and then using the Forge blockstate format to override the particle definition. I got no errors, but the particles are still not showing up (they're black-and-purple). I'll see about trying to map them with the state mapper instead, and hopefully that will go better. EDIT Well, that didn't work >_< I'm now getting the following errors for each color of Shulker box: I've pushed my latest changes to the repo linked above; I'm assuming I've misunderstood the extended BlockState format and done something wrong there, but while I look for that, any guidance would be appreciated.

Ooh, fancy; I didn't realize Forge had its own extension to the blockstates format. I'll play around with it a bit and see if I can get something working well. Thanks! EDIT Wait, darn. I'm not using block states for these; they're each a separate block instance, the same way Minecraft vanilla handles them. If I made them the same instance of the block and used block states, wouldn't that mess up the tile entity rendering? Or should I be using multiple block instances, each with a block state anyway for the sake of the particle definitions? You know, I was so close to being finished with this, and now I'm just confused over tiny particles