ChampionAsh5357

I feel like that's self-explanatory. Check to make sure you registered your block correctly.

Are you sure your constants are set correctly?

World#getHeight and IWorldReader#getBiome can help you with that. Here are also the six heightmap types and what they do: MOTION_BLOCKING: The highest block that blocks motion or contains a fluid. MOTION_BLOCKING_NO_LEAVES: The highest block that blocks motion or contains a fluid or is in the minecraft:leaves tag. OCEAN_FLOOR: The highest non-air block, solid block. OCEAN_FLOOR_WG: The highest block that is neither air nor contains a fluid, for worldgen. WORLD_SURFACE: The highest non-air block. WORLD_SURFACE_WG: The highest non-air block, for worldgen.

Can you show one of your shaped crafting json files? My only two guesses with low information is that your type is not "minecraft:crafting_shaped" or you need to refresh your file tree inside your ide. I'm assuming those dots represent folders as well in your path.

My guess is that you're updating this to 1.13+. The ore is registered using metadata. There is no such thing as 'metadata' in that sense after 1.13. So, you have to create a separate block for each ore.

As yes sorry. However, technically everything but explosions can be handled by the entity place item event and custom generation assuming you decide to create a new block for lava. Explosions can then be handled by cancelling the initial and then spawning another with everything but the fire flag checked false. That might have a greater reduction in lag if there still is a noticeable amount.

That would make sense as calling that method results in a cyclical process. The issue with this method is that you're calling the event and injecting your method before the previous one is even done. Visually, it executes: First Block Placement -> Event at neighbor check -> Second Block Placement -> Event at neighbor check (potential for infinite loop) -> Finish Second Block Placement -> Finish First Block Placement. As for the flag, since it is only executed on the server, you must have the two least significant bits enabled. Another one that may help reduce lag is that if you are okay with no neighbors being affected is to add 16. If you want a list of flags: 1 will cause a block update. 2 will send the change to clients. 4 will prevent the block from being re-rendered. 8 will force any re-renders to run on the main thread instead 16 will prevent neighbor reactions (e.g. fences connecting, observers pulsing). 32 will prevent neighbor reactions from spawning drops. 64 will signify the block is being moved. I would recommend 1, 2, and 16 = 19. 16 shouldn't be checked however if you want an unlit torch to have a different value on redstone or use it for observer input. Technically this is not a good way to execute code since you're basically injecting a method within itself, but it's the only event I can think of that does the job in all scenarios. My confusion is that why do you need to check for all possible scenarios in your custom dimension? Entities are the only thing that can place torches, and structures can just redone to have unlit torches in them. It seems strange to me why you need it for every possible instance.

The closest you can get to whenever a block is changed is BlockEvent#NeighborNotifyEvent. One thing of note is that this is executed solely on the logical server.

Thank you very much. This idea I got from the ForgeRegistries class itself. There is an comment for a javadoc that states such a thing.

Hello, My understanding of ObjectHolder and DefferedRegister is quite limited in scope. So, I am wondering what are the main advantages and drawbacks of using either to understand their implementation better. From what I've gathered, ObjectHolder uses a type of dependency injection to hold the value of a field. On the other hand, DeferredRegister uses RegistryObject created by suppliers. Most people use ForgeRegistries when using DefferedRegister even though it should go through GameRegistry instead. ForgeRegistries should be used for query and iterations usually instead of appending to the registry. Is this just a giant thing of preference or is there some difference, maybe some sort of coupling? Thank you.

It's in the forge message system for the website? Or am I understanding your question wrong again?

IAllergies allergies = player.getCapability(AllergiesProvider.ALLERGIES_CAP).orElseThrow(() -> new RuntimeException("This capability does not exist")); There's a button called TeleType and it looks like tt.

The first method needs a defaulted instance, the second method needs a defaulted instance passed through a Supplier, and the third method uses a supplier of an exception. Suppliers can be easily made using: () -> value As for how to look for code, in Eclipse I just ctrl + left click and it opens the source for me. If it doesn't exist, I look for a javadoc on the internet.

Apologies, I just glanced at the code. LazyOptional#getValue is private. You need to use either orElse, orElseGet, orElseThrow to get the desired result. And yes, something like that would work. Either one will work since you already check if its present. Just make sure you put a valid instance as the parameter. I usually prefer LazyOptional#orElseThrow because I don't want to a null default if it fails.

Do not cast from LazyOptional<IAllergies> to IAllergies. LazyOptional is quite similar to Optional found in standard java. If you want to do it your way, you should first check if the value is present in the optional (LazyOptional#isPresent) and then get the value (LazyOptional#getValue). You can also use (LazyOptional#ifPresent) instead.

Get the color of the fluid from either the FluidAttributes if you want it to be its default color or from the biome itself if you want the color to change depending on the biome. What you see are the default textures of water and lava. Lava is only ever one color and not affected by anything so having the texture only be what it is fine. Water changes color depending on the biome so it's represented as a gray texture file so it can be color mapped within the game using an overlay.

First, biome has an addSpawn method which you should use. Second, WorldEntitySpawner#func_226701_a_ should answer why your entity spawns in houses. Basic answer is that it has to do with the light level. Finally, look at DefaultBiomeFeatures if you want to figure that out.

If you're talking about the functionality of an inversion, I recommend looking over logic gates (specifically NOT). If you're talking about how the block actually determines whether the redstone torch should be on or not, you should look over RedstoneTorchBlock#shouldBeOff.

One of the easiest things to do when something is not working is to see has Minecraft done this anywhere. And the answer to this question can literally be pulled up by pressing F3 and looking at the debug menu. Minecraft can see the light from the client and the server. Here's a snippet from DebugOverlayGui, do with it what you need to solve this problem. if (this.mc.world != null) { if (this.mc.world.isBlockLoaded(blockpos)) { Chunk chunk = this.func_212916_i(); if (chunk.isEmpty()) { list.add("Waiting for chunk..."); } else { int i = this.mc.world.getChunkProvider().getLightManager().func_227470_b_(blockpos, 0); int j = this.mc.world.func_226658_a_(LightType.SKY, blockpos); int k = this.mc.world.func_226658_a_(LightType.BLOCK, blockpos); list.add("Client Light: " + i + " (" + j + " sky, " + k + " block)"); Chunk chunk1 = this.func_212919_h(); if (chunk1 != null) { WorldLightManager worldlightmanager = world.getChunkProvider().getLightManager(); list.add("Server Light: (" + worldlightmanager.getLightEngine(LightType.SKY).getLightFor(blockpos) + " sky, " + worldlightmanager.getLightEngine(LightType.BLOCK).getLightFor(blockpos) + " block)"); } else { list.add("Server Light: (?? sky, ?? block)"); } ... } ... } ... }

So I tried just setting the value of the ItemRenderer to an extended version using reflection and it stopped the ModelManager from getting the splashList from the bakery resulting in a bunch of missing textures (unsurprisingly). I tried setting this during the ModelBakeEvent which fixed this issue but opened up a realm of new problems. Since I didn't change the ItemRenderer right when Minecraft was initializing, a bunch of variables set still had the regular ItemRenderer attached to it. I overwrote all of those variables using reflection as well. I know this is not a good idea but I was testing a case. The issue with the idea is that it creates a new instance each time the models are reloaded. Which means that if you refresh the models (e.g. F3 + T) all data currently being used will be reset. So, the game simply crashes whenever those buttons are pressed. I still want to find a way of doing this without having to create a PR for a hook into ItemRenderer#getItemModelWithOverrides. Maybe there is another way to hook into all the itemstacks at once and update their current model.

You cannot spawn an entity on the client. If you want to execute a spawn, you have to send a packet to the server from the client and have that packet spawn the entity.

That's probably because you didn't align anything relative to the head. When you add something as a child model, everything becomes relative to the that specific renderer and not the entire model. So you have reorient everything in terms of the specific renderer.

Thanks, however, I did already look at this and try a version. I probably would've done it this way if I was only doing this for a single item. The issue is that if I were doing the one item method, there would be no way to make the item act like the actual item to the same effect as the original since ItemStack#getItem when called in each method for let's say food would say: hey look, this CustomItem does not have a Food attached to it or something like that. This has to be able to change for all items. If I wanted to use this method above, I would need to override every single item that comes into the game and add that line of code which would be more or less the same issue when trying to override the ItemRenderer method. Also, if I were to do that, the ItemOverrideList#getModelWithOverrides seems to only be called if the item has custom properties which only applies to a few items within the game. I might be missing something, so I'll look into it more. But, I doubt it will work without overriding everything.

Don't assume that because you set EntityRenderer#getEntityTexture that your texture will automatically be binded for you. You still need to bind your texture to the IVertexBuilder, Model, or however you are rendering the entity.

This issue has to do with the fact of see through text vs normal text rendering. Normal text rendering prioritizes all 'special' models behind the text to unload since the text is technically a solid object. See through text prioritizes the normal text to render behind any 'special' models making them appear to cut off the text. You have the correct implementation of using a see through rendered text with a normal rendered text, there is just one tiny error. To render the background of the text, you have to set the color equal to a value higher than 0. 1056964608 on the second renderString renders the background of the text as normal instead of making it transparent. So, you appear with the rendering bug. The way to fix it is just to change it to: fontRenderer.renderString(text, offset, 0F, 553648127, false, matrix4f, impl, true, 1056964608, 15728640); fontRenderer.renderString(text, offset, 0F, -1, false, matrix4f, impl, false, 0, 15728640); This should solve your issue.