ChampionAsh5357

Well you know the position of the waypoint and the current position of the player. You also know the current rotation and yaw of the player as well. You can also figure out when to check for if the area is loaded. Take that as you will.

Apologies, not trying to lecture you. I just assume that the person I'm talking to only knows enough information in Java and not anything else. Only reason I mention it is that it's how any game calculates physics. If I remember correctly, the entity's motion in the x and z every tick is multiplied by 0.91 and the slipperiness of the block underneath if the entity is on the ground. For the y direction, it's motion should be the y motion minus the effect of gravity (by default 0.08) and multiplied by 0.98f.

In addition, you could store the supplier in a Lazy. What they essentially do is use the supplier once to grab the item and then keep the first accessed result. This makes the result deterministic and unchangeable (which is pretty much what you're going for).

1. It's specifically used for the creative block pick button. It's a substitute from having no item given since an item form of the block doesn't exist. It's just handy to return the things you plant. Although technically each plantable item is the BlockItem of the crop. 2. I'm confused what you mean by this. A crop block is only for ticking the current age. Anything that makes the block it's actual self is handled by the loot table or the item placement.

Vanilla and forge does not create any. As for an open source mod that does, there are plenty. However, I have not looked into them enough to give my approval of their practices and code. For that reason, I do not want to give you any links in case I promote such bad practices or outdated methods.

Not completely. Read through the documentation again. The IStorage class is just a helper for the capability itself. The actual serialization is handled by the provider you attach the capability to. Everything else I believe is roughly correct. ItemStackHandler iirc.

They are basically temporary data holders that can be written to the specific object when saving the game. Their implementation seems separate, but that's mainly because they are a hook into the actual system that manages the NBT. So you would create a capability and attach it to the object class through AttachCapabilitiesEvent. Exposing a capability is making it noticeable to the object it's attached to. You're yelling out to someone saying "hey, I exist now" and grabbing that instance. Well, I should say almost that. The use of LazyOptionals basically say "hey, I might exist", and then you compare the cap being checked to your own to say that you exist. Yes, the IInventory class is deprecated for any use within Forge. It should be setup using capabilities such as IItemHandler. The only time where you should reference IInventory is maybe for recipes; however, those can be wrapped around.

That's physics once again. You should really look over Newton's Laws of Motion to understand that. As for Minecraft's specific case, I've never looked into it. Again physics. It even gives you the calculations. A player has a velocity of 3.92 blocks per every in-game tick. Their acceleration is 0.08 blocks per every in-game tick squared. This forum is not really a physics course. You should probably look up actual velocity, distance, and acceleration formulas, plug the values in, and adjust to get the values you want.

So here's my understanding (assuming all positions are loaded): updatePostPlacement - Connections of a block with adjacent block called for all directions given a face. neighborChanged - Connections of a block with the adjacent block called for all directions (doesn't rely on a specific face). onNeighborChange - Connections of a tile entity with the adjacent block for all directions (doesn't rely on a specific face). observedNeighborChange - Probably a misaligned patch when ported but was originally used for observer updates. So the difference is mainly that updatePostPlacement are used for changing the state of a block in most cases. neighborChanged is for changing the block state that doesn't rely on a specific situation based on the specific block face. Then onNeighborChange is the tile entity version of neighborChanged.

There's a difference between velocity and distance. First, you normalize the look vector. This means that the vector will be anywhere from 0-1. Also, when you multiply it by 5, you are moving 5x more in the direction you were looking. Also, the motion upward will be 4. This is the velocity of the object (which is the distance per unit of time). So, based on the time unit used by Minecraft, in the first time unit, the user will move 5x the normalized look vector and 4 upwards. Their motion will continue in that direction for a parabolic curve of some kind depending on the motion calculated. So, basically, just do physics.

Capabilities that can be serialized might help. Do note the docs are severly out of date on this and I haven't bothered to update my PR that fixes it.

...if that was true then you should be able to find the error log. Please post the stacktrace and what steps you took to get to where you are now.

You do know how to register something correct?

Your capability instance.

Don't set the textures in the blockstate file. Just use the model itself. If you never used the model system before, you can apply multiple textures to a model, just a single texture per face.

There is no such thing as a row within inventories by default. All that matters is the size. This can be obtained simply with an IItemHandler capability on a TileEntity. As for the actual display, that's handled through Containers with Slots and ContainerScreens on the client. Two of these three can be added via a registry, one of them needs to be added using a static method in the client setup event, and it can be accessed through Block#onBlockActivated using NetworkHooks::openGui on the server. Please note that the above is referring to the logical client and server. As for references, screens and containers are almost the same as vanilla. The only difference is in the TileEntity itself since IInventory should not be used. You can look at this updated patch of the docs to understand how to implement a capability. Come back when you have some code written out so that we may point you in the right direction with the necessary tools.

This has been removed in 1.15, so the version you are using is not supported. Please update to at least LTS 1.15.2 to receive support.

What version is this for?

There probably won't be many or any actually. Either way, if you are generating a file from nbt, you should look into the vanilla source and use that as a baseline. Since you are not doing anything that might require the JigsawManager, using something like an igloo is a good start for learning how to use the Template system. Just remember, a feature of each structure should be present in all biomes while the actual structure itself should only be present in the biomes you would like it to spawn in. You will need to register your features/structure using their respective forge registry before use in the JSON file itself. If you are using vanilla structures/features or just modifying the config file, you can do that purely within JSON itself.

If you refresh the gradle dependencies, it should import the classes. It not would indicate that the build.gradle file is erroring or something when pulling the information itself is. What is the stacktrace when running the gradle?

Ah, I'm sorry. I'm quite tired and misread for some reason. So yes, you would need a packet setup. As the javadoc says, 'The server is not aware of when the client right clicks empty space with an empty hand, you will need to tell the server yourself.' However, I'm assuming this handles only the case when there is no item in the hand while the armor is on. You would also need to hook into RightClickItem to cover all use cases. However, that one is called on the server. So you can create a separate method to call the packet instance and the other event instance from.

Then you would use PlayerInteractEvent$EntityInteract or PlayerInteractEvent$EntityInteractSpecific then to get when the user right clicks an entity. From there, you can cancel the event as needed and check the armor slots for what you are looking for.

I'm not saying you have to brute-force your way through MCs source. My argument is that their first response is to look for someone else's answer instead of trying to solve it themselves. If you're not willing to suffer and put in the effort to try and solve the problem, then you're not going to do well as a programmer. It conditions you to rely on someone else rather than adapt your knowledge to solve the problem. There is nothing wrong about using an existing model, I do it all the time. However, that's only once I've gotten to the point where I've spent hours reading through documentation and testing to see if I can create a valid and correct solution to the problem. It allows me to learn about the current library I am using and how to better improve my own knowledge to complete it.

This cannot apply to all living entities. You would probably need to use an event, either PlayerInteractEvent$EntityInteract or PlayerInteractEvent$EntityInteractSpecific, to handle the logic instead.