DavidM

Please post your code, preferably as a GitHub repo.

I thought OP needed RayTracing. If I recall correctly RayTracing is client only?

Entity summoning are controlled on the server side, thus summoning lightning bolts on the client will not work. Send a packet to the server when the sword is right clicked with; write a handler for that packet that summons the lightning.

ItemStack will never be null. ItemStack from an EntityItem will never be empty, as the ones that are are removed from the world.

I suppose you are trying to render the health bar at exactly where the mobs are at on the original Minecraft screen, in which case you would need to offset the local position by the camera's rotation. I don't know if there is a GLM in Java or not, but if there is not, you can use the following method. To transform a 3D pos to 2D includes the following states: 3D original (global) entity position 3D relative (to camera) entity position 3D relative (to camera) entity position after camera rotation 2D screen coords To elaborate the concept better, I will assume the center of the window is (0, 0). Left side is negative x, right side is positive x, etc. This is not the case of a JFrame though, and you will have to do some manual translation of the screen coords by adding half the screen width to x, and half the screen height to y. First, subtract every axis (x, y, z) of the entity's global position by the camera's global position (the position in the Minecraft world). This will give a relative position from the camera to the entity. Next, apply the camera's rotation to the relative position. Assuming the Z-axis is the one sticking out from the camera on the local coordinates (I am not sure if this is the case of Minecraft; change this to X if necessary), multiply z by cos(camera.yaw), and multiply x by sin(camera.yaw). This takes care of the yaw (horizontal) rotation of the camera. The same applies to the pitch (vertical) rotation of the camera; simply multiply z (again) by cos(camera.pitch) and multiply y by sin(camera.pitch). You are basically done now if you want orthogonal view. Throw away the z and use the x and y as screen coords. However, I assume that you want perspective view, so you need to make x = x / z * FOV and y = y / z * FOV, where FOV is the field of view value you need to experiment with (start with something near 2). Now just throw away the z (or the x, depending on which axis is the one sticking out the camera in Minecraft when the camera has no rotation) and use x, y as the screen coords. Remember to do the manual translation of the screen coords by adding half the screen width to x, and half the screen height to y.

This is normal. There should not be a jar.

It is not possible as far as I am aware of.

The in-between phrase is the game’s attempt to interpolate the entity’s movement to create a smooth movement seen by the player.

You could try using as this should be the easiest way I see.

An instance of LivingEntity. Note that in 1.14 there is a third parameter that takes in a Consumer<? extends LivingEntity>. If you need help on creating a consumer, you can read about lambdas and consumers in Java here.

EntityJoinWorldEvent is fired when an Entity is added to the world, during which Entity#isDead cannot be true. AFAIK there is no way to do this with an event. Neither Entity#onUpdate nor ItemEntity#onUpdate fires an event every tick. The only way I see is to replace the vanilla ItemEntity with your own version and override Entity#attackEntityFrom and check whether the DamageSource is from lava. That would not work, as dropped items are created by directly instantiating an instance of the vanilla ItemEntity.

You did not provide your log. We need the log to help you.

Why do you need to create an entity though? How is your spell casted? Also please post your crash log.

This is because your invChk class has syntax errors. Looking at your code, I suppose you attempted to create a constructor and put the checking of the inventory in there; however, you created a method instead of a constructor, and you never called that method. To learn about constructors in Java, read https://www.w3schools.com/java/java_constructors.asp.

Try updating CodeChicken Lib (or use the version its dependents specify).

NetherEx only requires LibraryEx. No other dependencies should be needed. It is probably a dependency from another mod. Please read the installation guide of your mods to learn about their dependencies.

Not really. There is Java, and Forge (and Minecraft itself) is built upon it. Java is the same inside and outside Forge. You might have the processing power to do so, but it is very unnecessary. All you have to do is to mark that method static instead of initializing the object, which will accomplish the exact same thing, but both faster and less memory-consuming. Besides, most users probably don't want their game to use processing power to run pointless operations. Anyways, this is what you have to do: Create a event subscriber for ClientTickEvent (which you already have) Create a new function to iterate through the player's inventory (which you kind of have) or just do it inside the event subscriber Create a way of informing the user of the full inventory (which you already have)

Umm not really. I would say the second one is easier since you are making a client side mod that only checks the client player. This should be irrelevant to your current problem though, as your method is not called from the event subscriber. Do you know Java? If not, please learn Java before making a mod.

Don’t create a new object each tick, as this is very expensive. Create a function that takes in a player and checks the inventory of the given player instead. I am pretty sure your invChk class is not valid Java though.

Post your new code. An event subscriber must take in exactly on parameter: the event. Also does your invChk class compile?

Use reflection to change EntityPlayer::REACH_DISTANCE to your desired value. EDIT: Oops just realized this thread is almost a year old. Sorry.

What class is responsible for the stitching?

I recall that Minecraft (used to?) have a texture map with all the block and item textures on it. I believe this is done to circumvent the need of constantly binding to other textures when rendering different blocks. However, this was done in the premise that all textures have the same dimension (16x16). I am wondering how textures in modded Minecraft, when blocks with textures other than 16x16 pixels are added to the game, are handled. Does the game still stitch all the textures together? Or does the game simply bind to a different texture each time a different block is rendered instead of having a large stitched texture map?

You need to check whether the DamageSource is from a player by checking whether DamageSource#damageType is equal to “player”, not create a new field for player. Do you know Java though? If not, please learn it before making a mod.

Override Entity#attackEntityFrom and call World#createExplosion (to create the explosion) if the DamageSource is from a player. Return true in this case as players are able to damage your entity. If the DamageSource is from an explosion, return false.