DavidM

In modern versions of Minecraft, project setup is done by importing the gradle workspace into your IDE instead of pointing the project workspace to the eclipse folder.

Custom clients are not supported on this forum, and are not encouraged in general (yes, clients such as BLC and Lunar are looked down upon in the modding community due to violation of Mojang's wishes and account security threats). If you want to modify the game, use a mod instead (although keep in mind that "anti-cheat" clients and fundamentally flawed and will not work).

Commands are no longer client-sided. Alternatively, you could subscribe to ClientChatEvent and directly interpret the player's input there.

Haven't tested this, but have you tried using reflection to change the Item#maxStackSize field?

That should be fine. I thought you meant that the DeferredRegistry isn't working for the IRegistries

It is preferred that blocks, items and entities are registered via DeferredRegistry. Can you post your code regarding the DeferredRegistry that you said didn't work?

Check out RenderingRegistry and its methods. (Basically call RenderingRegistry::registerEntityRenderingHandler during FMLClientSetupEvent) This sounds concerning. How are you registering everything then?

Those are problems with the specific shader, not shaders in general. If you want to add reflections and waves, then using a shader is by far the best way to go. What specific changes are you trying to implement? It would be much easier to help if we know what you are trying to do specifically.

I just told you. and

1. That method triggers on both the client and the server side. You will need to check the side with World#isRemote. 2. Your overriding method does not have the correct signatures (please learn Java before attempting to write a mod).

Have you registered the item form of the blocks?

Please post the entire log.

Hi. You need to add the velocity to the entity, not negate its current velocity (that doesn't make mathematical sense). FACING is a DirectionProperty, which is a blockstate property. It does not contain a value by itself, but rather act as a key to a value stored in the blockstate.

That's a really cool idea.

In that case, I'm afraid you are far from updating the mod. All the "launching of IntelliJ" is going to do is load the Gradle file, which is only used to setup the workspace (and other misc stuff such as building the mod). It won't give an error as long as you have a valid build.gradle. After that, you will still have to actually update the code. I would expect a mod like Witchery to have about 80000+ lines of code, and the majority of those need to be rewritten due to the large update. I would suggest to learn more about Minecraft modding first before tackling on a large project like this.

You should learn to use Git, which is the encouraged method of uploading your code to GitHub. Also, what do you mean by ? There is a lot of changes from 1.7.10 to newer versions. If all you did was to fix the compile time errors, then the mod will not work at all. IMO it would be less work to write the mod from scratch rather than porting across such a huge version gap.

Minecraft mods are fully fledged Java programs. That means they are capable of doing almost ANYTHING on your computer. They can insert themselves as a background program and spy on your every move; they can key log your keyboard in the background to retrieve credential informations of your account; they can corrupt every single file on your device. However, being capable of these things doesn't mean it will happen. As long as you didn't get your mod from some dodgy site, you should be fine. A mod is a file on your computer; it won't delete itself unless its author intends to do so (which is weird, and never happens unless the mod is intentionally being weird, in which case you should think twice before installing it).

Personally, I would say that in this case it would be appropriate to add a hook for the eating event if there isn't already one, as editing food behaviors seems like quite a common feature. You can submit a PR to the Forge repo on GitHub with an adequate solution.

Hmm. Since the fire is created before the bolt is added to the world, you could try subscribing to EntityJoinWorldEvent, check if the entity is lightning bolt, and check for fire blocks around the position of the bolt and set them to air. This will extinguish fire in the proximity (3-5 blocks in diameter) that are not created by the lightning, but that is the closest I can think of.

You can create a custom implementation of LightningBoltEntity, which does not spawn fire in its constructor, and spawn that instead.

Creating excessive base classes is a bad practice against the structure of OOP. Since each class can only inherit one base class, creating base classes just to write less code will prevent deriving classes to extend other classes that are actually useful. For example, with your current setup, if you want to make a sword that glints, you will have to choose between extending SwordItem and ItemEnchantedGlint. This will result in having to mimic the behavior of the unextended class, which would be redundant code (and bad design). For more information, look up "Composition over Inheritance".

Yes. Although you would need to replace the player's crafting inventory with a custom one, as well as attach a Capability that stores the data of the current craft to the player.

Yes, except don't create a special base class for it. It's just an override; do it in the actual item's class.

You cannot do that. Minecraft's chunk format enforces the range of [0, 15] light level. Forcefully changing this will cause world corruptions and a lot of incompatibility with other mods. However, if the darkness effect is only visual, then you could create a custom shader to achieve it. I think I misunderstood. Are you trying to render a single/few blocks that way? Or do you want the whole world to be rendered that way?

With entity speed (or how much it moved during last tick) and interpolation. Interpolation is multiplying the difference in distance in that tick by the partial ticks of that frame, and add that to the previous position to achieve smooth movement.