Draco18s

You never actually use this.

Assuming that you're using DeferredRegister, you have to do ItemInit.LIGHTNING_BOLT.get()

Yes. If your block is not meant to exist in the inventory, then don't create an item for it.

That button only copies the block in creative, and in creative people can just pull the block out of the creative inventory anyway. Fire only "works" because it doesn't actually have a collision volume, so the raytrace that occurs on middle-mouse sees the block behind the fire (same for water). On the other hand, if your block can't even exist as an item (that is, you don't register a BlockItem for it), then it can never end up in an inventory at all, problem solved.

Power is handled by the Block class, which you haven't shown us.

That's because redstone doesn't use tile entities. It's all handled by blockstates. There's no way to achieve what you want as far as I know.

Probably because the line is so perfectly in line with the view direction that it has no visible area. Like looking edge-on to a piece of paper. And this will always be true when drawing a line from the center of the camera to the point under the center of the camera.

Vec3d start = new Vec3d(0.1F, 0, 0); Vec3d end = start.add(0, 0, distance); See how you have a distance variable? See how the same value in your start Vec3d is 0? I told you to make the line not start at a distance of 0.

The player's eye and the camera are the same thing... You want it offset in front of the player's view, don't position it at 0 distance.

You are probably overlooking the spot where he removes all camera transformations before calling that function. For example, here, where I have to subtract off the block position before drawing a line between two blocks: https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/hazards/client/HazardsClientEventHandler.java#L191 (I don't have to deal with the player pos and rot because that's taken care of for me by vanilla for that event, but it does include a block offset) RenderWorldLastEvent is going to be the last thing before the camera actually renders, which means it already includes player position and rotation and all further offsets are from that.

Basically the problem is that the player's rotation values are already taken care of, because that's how rendering works, so by adding in the player's rotation values, you're doubling up. Which is why it looks like the line moves twice as fast as it should.

But Minecraft is written in Java, so knowing Java helps you solve your own problems with Minecraft's source.

You're going to need to contact the author of the mod that is supplying those blocks to add their blocks to the tag. Until then, you'd have to do that yourself.

that's a name, a Type, and a name. So you skipped over the first parameter's Type, which is important.

No, post your code in a convenient format on Github. https://docs.github.com/en/get-started/quickstart/create-a-repo#commit-your-first-change

Or you could just have used git the way git is meant to be used.

Recipes are datapack objects, you can just replace them with tag versions and supply your own tag.

entity.addEffect

It's a technique called Generics. Just as a List<string> and List<integer> take strings and integers respectively, a HashMap (or Dictionary) maps a key to a value. For example if you wanted to create a table of products and their prices, you might use a HashMap<string,float> mapping the string-name of the product to the float-value of the product. (A multimap is mostly just syntactic sugar for HashMap<K,List<V>> and the fact that it maps one key to multiple values is all you need to know) So yes, the Type of the key value is important.

Yes, because it is a method that belongs in an Item class. Here it exists as some random method that you never reference.

What are the names and types of the parameters?

Mind, I don't know what the Mojang mapping name is, but you're looking for this: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/industry/client/gui/FilterGuiContainer.java#L47

Your code is faulty. @Nonnull @Override public <T> LazyOptional<T> getCapability(@Nonnull Capability<T> cap, @Nullable Direction side) { return implementation.cast(); } Me, accessing a restaurant's website: "Hello, yes sir, I would like to see your menu." You, the restaurant owner: "HERE'S MY FRIDGE" The whole point of the cap parameter is so that you know which capability is being asked for. If you aren't being asked for your capability, don't return YOUR capability.

Events, mostly.

Yes I know how that works. The problem was that you used the language in an ambiguous way such as to convey a lack of distinction between overriding the behavior of the existing vanilla doors vs. overriding the behavior by class extension for new doors. The restriction, as stated by diesieben07, was in direct response to "I got this error." That error only applies to the situation of replacing vanilla blocks with your own to modify the behavior of the vanilla blocks. If you had read further down, you'd have found this: Which precisely details the type of state extension you are interested in performing with the comment "this works."