Matryoshika

Use ForgeRegistries.BIOMES.getValue(value) to get a biome. The value is a ResourceLocation, which you can get from Biomes.FOREST.getRegistryName()

Hey, we all have our moments when we need to rubber duck debug. Sometimes the answer could be staring right at us and we don't notice until someone else points it out. It's a human Feature™

Have you tried ModItems.MESSAGE_SCROLL.get()? The method comment for RegistryObject::get is:

Sadly I do not, at least of the later stage when I switched from 2d flat-faced textures to an actual 3d block with actual holes I do however have the first rendition of my menger-sponges still. Lapis block -> Lapis Menger Sponge T1 ->...->T5 I eventually as said switched to actual 3d-models instead of using the void hole in the middle. The commented out part below the highlighted code in the link is what's shown above. Feel free to setup a local repo though and build your own jar of Σcho. Tried to but haven't used eclipse since that project (3 years ago now >.>) and I forgot how much I hate setting up projects in it. Requires botania & jei cause I had some integrations with them

Don't try to emulate the texture itself. Instead use IForgeBakedModel::getQuads which has a side argument. I used this back in 1.12 to make menger sponges out of any solid block. It's a bit outdated, so copy/paste probably won't work, but should point you in the right direction. BakedMengerOneModel.java#L47-77 Also please cache the models that your blocks have copied. It's much easier on the client to reuse the List<BakedQuad> that you've already gotten once, than to continuously ask for it. Cache However nowadays you should use ISelectiveResourceReloadListener instead The bytes sprinkled throughout the code is the tiers of the menger iterations. They can be safely ignored.

Pretty much every packet, Vanilla, Forge and quite the select few modded ones, like EIO teleportation, are fired from the client with modified data. Spawning in items mainly by using the CPacketCreativeInventoryAction although the mechanics for how the server is accepting it from the client is beyond me.

Preface: I will not name the mod I'm trying to identify on client-connection, bar possibly in PM to someone from the Forum Team. It shouldn't be known about I'm part of a server-network that has started to see several players using a "hacking mod" that allows them to manipulate packets. The mod in question goes cross-language between java and C++. Usually, for things like this, we just add the offending mod's modid to a blacklist plugin and that'll disallow the client from connecting to any of our servers. However, this mod in question, stupidly enough, allows the user to edit it's own modid, modname and version-id through a gui in the menu, to anything they user can think of. This is quite disconcerting. I know there's very little information given here, but is there anything bar modid/modname/version given out in any packet/handshake/event that can be used to identify a mod?

Whilst I cannot help out with the proper way to disable the blocks from rendering inside this area, and substituting your own animation, I can quite confidently state that it will not be as performance intensive as you think, if you keep OpenGL calls to a minimum. I've made some menger-sponge inspired compressed blocks (20^1, 20^2.... 20^6 block compression) and whilst I was dealing with pre-calculated models and bakedQuad-caching, T3 compression(20^3) or 8,000 miniature blocks rendered inside a single blockspace did cause some stutter, but not game-breaking. (Though it wasn't animated) Though 11^3 isn't a small number, that still only equates to 1,331 blocks. Yes, scaling all of this will have a higher performance drain than just basic rendering, but it shouldn't be impossible if you focus on performance.

He just linked you the source-code for the class that specifically holds all registries... perhaps you should use that class? ForgeRegistries.BLOCKS.getValue(key) to get a specific block, where key is the block's RegistryName, If you want to get all your mod's blocks at once, you would need to iterate over the registry first. (personally I'd use a lambda stream with a filter matching each blocks's RegistryName's getResourceDomain (mod-id), then save that in a collection somewhere) Whilst not using raw ID's is correct (they can be different on different servers!) NEVER use static instances. The whole RegistryEvent was made to remove this practice. Use the ObjectHolder annotation instead if you must have an associated field.

Wrong sub-forum to create this thread in. Modder support is for people actively coding with Forge. Support & Bug reports would be the correct location for this issue You've already made a thread there. No need to spam threads Tartheus is the mod trying to access client-side only code(particles in this case) whilst being server-side. Find their issue-tracker and report it there

Your if-statement is faulty. surface here will always be a non-air-block. You have to check if surface.up() is an air-block, not the one that is guaranteed not to be. Further-more, if you simplify your entire if-statement to if(A && B && C || D) then the logic is easier to see. if A, B and C are true, OR if D is true, then continue. Dirt-blocks will always pass this check, even if the air-block or surfaceWorld are false. You need to wrap C and D inside a parenthesis. if(A && B && (C || D)), to continue if either of those two are true, whilst still relying on the A and B checks.

This is how I usually create my worldgen features Implement IWorldGenerator in your worldgen class(es). This will give you access to a generate method which will be called during worldgen. Be sure to check what Dimension(id) and/or what WorldType is being used by the current world. Don't think you want to generate stuff in the Nether/End etc. The mentioned generate method will give you a chunkX & chunkZ parameters. Do not multiply by 16 to get blockcoords, but rather use bit-shifting (blockpos = chunkpos << 4). Whilst multiplication from chunkpos to blockpos will result in correct numbers, division (block->chunk) will result in incorrect values for negative coordinates, due to how integers are rounded. It is for the best to consistently use one method to calculate rather than mix-and-match based on the situation. Always try to generate your features inside of the currently generating chunk. Do not generate along the border. This can cause cascading chunk-generations, and cause lag. Add 8 to both your x & z block-coordinates to get the (almost) centre of the current chunk, then use a random value between -7 to 7 (min-max values) to truly get a random position within the chunk. As for y-coordinates, you can use World::getTopSolidOrLiquidBlock to get the top-most solid y-value. Be sure to check if it is not a fluid though! For your normal crops, you only need to check for Dirt or Grass blocks, switch them out for Farmland (be sure to place some water next to it) and then place the crop ontop of that Sugarcane is a bit trickier. You can have a look through the WorldGenReed class in your IDE to see how Vanilla spawns Sugarcane Lastly, you need to register your IWorldGenerator implementing class during init (FMLInitializationEvent) using GameRegistry.registerWorldGenerator(WorldGenerator, weight) where weight is an integer determining when they are run. Higher weights tend to run after generators with less weight.

You can not create any item after pre-initialization has finished. The code is built specifically to that effect. If you must, you can allow the end-user to create new items through JSON or any other means, but those items will not exist until Minecraft launches once more, and detects the new items during the registry-events. This however has it's drawbacks, especially with constant addition and possibly subtractions from the registries. It would be for the best if you created a base-alloy item, register that once, and then edit it's stat with NBT, similarily to how Tinkers' Construct creates it's tools. You can edit many, many different client-side stats of the alloys, such as name, icon/model etc, to distinguish them. They will still all use the same [modid]:[name] but again, as with Tinker tools, you can spawn them in with specific NBT data. If you sort out all your different possible stats (or just some of them) the different alloys can be added to your CreativeTab (and thus also automatically into JEI if installed) to make it simpler to spawn in.

This is most likely caused by the Entity's Frustum culling. Don't have access to a workspace right now, but there should be a boolean along the lines of ignoreFrustumCheck that you can set to true in your entity's class that has been inherited from the base Entity class.

You still have them ingame, just don't add them to creative tabs, or recipes, making the /give command the only way to get them.