Animefan8888

MinecraftForge.EVENT_BUS.post

There are so many problems with your code I don't really know where to start. Two of them are your use of IHasModel, and the fact that you are initializing your Item, Block fields statically. Remove IHasModel completely. Use your list of Items/Blocks to register the models in the event. Initialize your Item/Block fields in the registry event. Remove ItemBase and BlockBase(if you have that). There is already a base item/block class. They are called Item and Block. The Idea of a CommonProxy is already handled via the main mod class. The correct way to use the Proxy system is to have an interface(a lot of the time called IProxy) and two classes that implement it ServerProxy and ClientProxy. Also I don't think you own the domain rnh.com so you should switch your package naming convention.

This is true my bad. Try stepping through your read and write methods in the debugger.

Ohhh. You need to use the RenderPlayerEvent and hide the arms in the Pre sub event and render them with your own rotation in the Post sub event.

Have you taken a look at the vanilla model files? All of the tools are handled. Take a look at assets.minecraft.models.item.handheld.json

Which part are you having problems with. Creating the entity that sent the packet? Use EntityType#create(Minecraft.getInstance().world) You don't know how to spawn the Entity? Minecraft.getInstance().world.addEntity What is it that you are having difficulty with?

Show what you have tried.

Don't use that function.. By handle method here I meant the processPacket method.

Thank you for posting your code. This part right here is your problem. File file = new File("muted-players.json"); try { file.setWritable(true); file.createNewFile(); } catch (IOException exception) { Log.info("Error creating file 'muted-players.json'!"); } You create an new file even if the file already exists. You need to check if the file exists before you create it.

Because the vanilla one doesn't work for modded entities unless they are living. The packet takes specific information like the entities Unique ID and position and velocity and spawns the same entity on the client with all of that data. If you don't override createSpawnPacket then the client won't know that that entity exists.

You don't have the same mods on your client that you do on the server.

Well if you put all of your files on github like I expected. You don't have a texture file at assets/modid/textures/blocks/juice_press_block

All of that stuff doesn't exist anymore. A full rewrite made it much better. Watch this video it explains the main mod class and the mods.toml file that you must now have. You could also look at the example mod file to see this if you still have it.

Change this to ActionResult.SUCCESS

It's not easy to get either.Chunks are stored in the ChunkProvider which in 1.14 there is the Abstract one(useless to us) and the Server and Client one. We need the server one. By the way you can get the chunk provider from World#getChunkProvider. Then you access the public ChunkManager field and have to use reflection to get "field_219251_e" is what it is called in my version of forge. That is essentially the "list" of Chunks that are currently loaded in the world. Or if you want to have your own that's a bit easier to interact with use the ChunkEvent.Load/Unload events and track a list of loaded chunks. Don't know why I included the first one when this second one sounds so easy.

Use PlayerEntity#areEyesInFluid(FluidTags.WATER)

You could just have a static field stored in your main class that is your modid.If that's what you mean.

OK let me spell it out a bit more. Create a NonNullList<ItemStack> that will represent your inventory in your TileEntity. Next create two IItemHandler instances in your TileEntity. Create the ItemStackHandlers by using the constructor that takes in a NonNullList<ItemStack>.This ensures that the IItemHandlers are operating on the same ItemStacks that are in the TileEntity. Make your one initialization of the ItemStackHandlers anonymous like so new ItemStackHandler([NonNullList goes here.]) { }; Now in this anonymous class make it so the insertItem and extractItem methods so it can't interact with the slots you want. Hint: Use if statement(s) on the slot number.(Make sure to listen to the JavaDoc above those methods). Next create a LazyOptional with LazyOptional.of(() -> [ANONYMOUS CLASS IITEMHANDLER HERE]). And store it in the TileEntity class. This is what you will return in the getCapability method. Now if you made the other IItemHandler(The one that isn't an anonymous class instance) private create a getter method in your TileEntity. This is the one that will be used inside the Container. While the one you returned in the getCapability method will be used for interactions(Hoppers. Pipes, Conduits, etc).

Then remove it entirely. Why would SurfaceBuilderConfig need to implement itself?

Put a "?" there instead.

Ok now.

Not that I found, and I spent a few hours doing this myself. The event only fires once. There is no reason to fire it again as I explained. I recommend a custom Capability for it, but you could just store the value in its NBT via ItemStack#getTag

Why not take a look at the vanilla blocks that interact with redstone the way you want it to?

This exactly. You could call the event, but all it would do is register all the IBlockColors again. It has nothing to do with recoloring the block itself. It just registers a handler for blocks. It would need to be there, but it would also need to have some code. Here is the documentation.

No that won't do anything. The Block has a model which is built into a mesh which is rendered. The mesh is not updated until a block in the world changes. Hence it doesn't update dynamically. You need to add a dummy BooleanProperty to your BlockState. And switch between those when the color is changed.