Alexiy

I fixed this using MDK

I'm trying to update my mod from 1.20.1 to 1.20.6. I've setup the workspace, but when I run game, following happens: [14:33:52] [Render thread/FATAL] [ne.mi.fm.ModLoader/LOADING]: File C:\Users\alexi\Minecraft\satako\build\resources\main constructed 0 mods: [], but had 1 mods specified: [satako] [14:33:52] [Render thread/FATAL] [ne.mi.fm.ModLoader/LOADING]: The following classes are missing, but are reported in the mods.toml: [satako] [14:33:52] [Render thread/FATAL] [ne.mi.fm.ModLoader/LOADING]: The following mods are missing, but have classes in the jar: [] [14:33:52] [Render thread/FATAL] [ne.mi.fm.ModLoader/CORE]: Failed to initialize mod containers net.minecraftforge.fml.ModLoadingException: The Mod File C:\Users\alexi\Minecraft\satako\build\resources\main has mods that were not found

They changed to 'xRot' and 'yRot', but private, so use 'getXRot()' and 'getYRot()'.

I'm currently working around this issue by using DCEVM as an alternative; so far it works fine except you can't swap changes in non-public methods.

Hot swap in Idea doesn't work with forge 1.14 at all for me, and it is very frustrating. Could someone explain why? ? P.S. Doesn't work in Eclipse as well... Good job, devs, you successfully made my life harder.

"java drivers" haha

Can't say much without seeing the dinosaur entity code as well... But already can tell that dinosaur.setAttackTarget() part should be in the shouldExecute() function, and the for loop must be broken upon finding the target.

In the 'render' method, you call "super.render()" and nothing else. That means that only the superclass model will be rendered. You need to get rid of the 'super' call and render your model's parts: Head.renderWithRotation(scale); Body.renderWithRotation(scale); and so on. 'scale' is the 'f5' parameter. But that's not all. Before going further, I'll ask - is this model intended for players only?

If this is a vanilla bug, then using vanilla AI tasks is worthless. While writing my mod I also have found several bugs in minecraft pathfinding code. This made me write own implementations of NodeProcessor, PathNavigateGround and PathFinder. I can't help you with this, though, because their code is really difficult to understand. You'll have to experiment with mentioned classes.

This is not possible in current render engine. There exists a coremod that makes it possible, but you know what they say about them - don't use coremods. Maybe future minecraft versions will have a more capable engine.

Minecraft does that by registering IBlockColors in net.minecraft.client.renderer.color.BlockColors. But that alone isn't enough - your block model must have a "tintindex" for relevant faces, for example look at assets/minecraft/models/block/leaves.json.

Yes, you have extend BlockDoor and ItemDoor classes to create your implementations. Also you will have to create assets for it - blockstate and models for each variant. I will give more information when I'm back home. But you can look at vanilla door blockstates and models for reference.

Store the fire delay in stack's NBT and decrement its value in "onUpdate()" method. Check whether it is zero in "onItemRightclick()' method; if it is zero, fire the bullet and reset the delay value, otherwise decrement it.

You can set block's light by "Block#.setLightLevel()", the acceptable value is from 0.0 to 1.0 which corresponds to 0 - 15 light level.

I'd like to do a thing when a player finishes eating, and this event seems the right one to use. Its only flaw that if the player consumes an item with size 1, the event's stack becomes empty, thus providing no context. Is there a workaround for this? I only came up with checking the duration of "LivingEntityUseItemEvent.Tick", but it's no use if the player stops using item just before tick 1.

Of course it doesn't, because this event is only fired on client, so you can get the client player "Minecraft.getMinecraft().player" as usual.

Do you call it on both sides? I think it is required to add effect on both client and server.

Yes there is, "InputEvent.KeyInputEvent".

Erm, a correction - by registering the class I didn't mean the actual class, but an instance of it only.

Have you registered this class to Forge event bus?

Clarify, do you want your messages in the console to look like this: [15:15:22] [main/INFO] [Fine Technology]: A message from mod logger or something else?

You don't need to create a capability, you need to create IItemHandler(s) and provide them depending on the EnumFacing passed in. For example, if you are making a furnace-like tile entity, you can create 3 handlers: one for inputting items from top, one for inputting fuel from horizontal sides, and one for extracting results from bottom. So like this stub: public class TileExample extends TileEntity { IItemHandler fuelInput; //To implement IItemHandler smeltableInput; IItemHandler resultOutput; @Override public boolean hasCapability(Capability<?> capability, @Nullable EnumFacing facing) { if(capability== CapabilityItemHandler.ITEM_HANDLER_CAPABILITY && facing!=null) return true; return super.hasCapability(capability, facing); } @Nullable @Override public <T> T getCapability(Capability<T> capability, @Nullable EnumFacing facing) { if(capability==CapabilityItemHandler.ITEM_HANDLER_CAPABILITY && facing!=null) { if(facing==EnumFacing.UP) return (T) fuelInput; else if(facing==EnumFacing.DOWN) return (T) resultOutput; else return (T) smeltableInput; } return super.getCapability(capability, facing); } }

IInventory is a really over-complicated interface. You should use item capability instead.

I have an instance of a block with 2 UIs. The way I handle it: First UI opens on clicking the block, as usual; there is a button that opens the second UI; When this button is pressed, a packet is sent to the server which opens the second UI; it has a button that opens the first UI; And so I can switch between these UIs back and forth. You might try using vanilla packet system for sending GUI ids: net.minecraft.world.World#addBlockEvent and net.minecraft.tileentity.TileEntity#receiveClientEvent. The first method sends the packet, the second method recieves it.

One of the dumbest ways might be checking if there are entities in front of the attacker, and deal damage to these entities, while spawning fire particles. The tricky thing might be making the particles flow in the correct direction, because you will have to use trigonometry for that.