DavidM

People should post issues on the forum first, and open them on GitHub if the issue is approved on the forums. By doing so, the GitHub issues wouldn't be flooded with repeated reports/bugs that are not actually bugs/problems caused by user error.

I don’t see why a block of metal should be melted down into exactly one bucket of liquid. There is no reason why the two should be equal (besides perhaps a slight convenience in calculating resources, but will likely cause more troubles than benefits).

Please post the debug.log.

Check out ItemEntity. Instantiate it with an item stack, set its position and add it to the world.

Telling you to learn Java before modding is not rude; it is a prerequisite for modding, and you cannot mod Minecraft without knowing Java. This is not a Java forum; if you need help learning Java, try some of the other programming-specific forums out there (i.e. StackOverflow).

No. Yes and yes. Check out TileEntity and ITickableTileEntity.

Yes. No. You don't need to change the hitbox. Just subscribe to an attack event and change the way hitbox are calculated in an attack.

IIRC You don't have to create a custom dimension for that. I haven't played with biomes and world generation, so unfortunately I cannot help much.

If the server does not have common mods installed, then you cannot have them when connecting to the server. Hypixel is a vanilla server, and they will likely never change that, so you will have to remove the aforementioned mods if you want to play on Hypixel.

Since this would apply to all entities with all blocks, instead of working on the block I’d say subscribe to LivingUpdateEvent and check if the entity is on the ground, if it is then apply ice movement to it (refer to vanilla code regarding ice physics).

In my previous mod where I attempted the time stop, I didn't cancel the velocity completely. I set them to 0.05 of the original value. This allows projectiles like arrows to maintain its direction, but might not be suitable in your case. I'm not aware of any better ways, but if you would like to sacrifice the "total time stop" in favor of having correct rendering of arrows then it may be worth a try. Make an array (length N) of UUIDs containing all the N entities in the world. Make another array (length 3 * N) containing the velocity of entities in the same order as the entity array.

That is expected, as key binds are not triggered inside screens. You will need to check KeyboardKeyEvent#getKeyCode manually in the event.

You can pass in a lambda that takes no parameter and returns an instance of EffectInstance. Something like: .effect(() -> new EffectInstance(yourDesiredEffect, yourDesiredDuration, effectLevelOrSomething), yourProbability);

You cannot do that on the client side. That method should be called on the server side. You should do the ray tracing on the server side (there might be a slight difference in player's facing with the client though).

Modders shouldn't mess with capes as that is Mojang's property. The author of that mod is being a terrible person by doing so. Anyways it sounds like the mod is broken; remove it and report to its author.

IIRC key bindings are not fired when inside a Screen. You have to subscribe to GuiScreenEvent.KeyboardKeyEvent or its subclasses to handle key presses inside a Screen.

You can't. What are you trying to achieve? What is your mod going to do? It is likely that what you are trying to achieve does not require modifications to the vanilla files.

Do you know Java? If not then please learn Java (inheritance, overriding, etc) before making a mod. The solution was already given to you in your previous thread.

Override Block#onBlockActivated and open the GUI there. If your GUI has a server-side container counter-part, use NetworkHooks::openGui on the server side (by checking if World#isRemote is false).

Except the "sample code" is extremely inefficient, fails randomly and crashes immediately on a dedicated server.

Don't use MCreator. It produces broken code as well as clogs up the mod jar with unnecessary fuss. More reasons can be found here. If you want to mod please learn Java and do it properly.

Note that the method only has to be static if you are registering the event subscriber class with @EventBusSubscriber. It should be non-static if an instance of the event subscriber class is constructed and registered via the event bus' register method.

I'd say it is safe to not null check that, as firing a player tick event with a null player is definitely going to cause problems, and wouldn't be out of place to expect a NPE.

There won’t be any delay as you are rendering during the same frame. Rendering per frame is drastically different from executing a command in a command block.

That would send a packet for every entity in the world, which is rather inefficient considering that when the time stops, all the values in the velocity would be 0. I would suggest making a separate packet for time stopping and time continuing. Moreover, I would suggest to send a list of all affect entities in one packet. However, if you really want to update the velocity individually, change the velocity of the entity directly and call Entity#markVelocityChanged. This will make the game sync the entity's velocity on the next tick (therefore custom packets are not necessary) (this would send a packet for each marked entity, which would be inefficient on a large scale). I'll check the arrow problem out, but I think it might be caused by the arrow's still picking up downward velocity from gravity every tick. In one of my mod I implemented a similar time stopping concept, and circumvented similar problems by keep setting the velocity of affected entities to 0. The client logic is similar to: listEntity <- a list of entities affected by the time stop; onStopPacketReceive: add specified entities to the list; onContinuePacketReceive: remove entities from the list; onTickEvent: set the velocity of all entities in the list to 0;