Draco18s

It's a logged bug that's existed since...basically forever. I'd get you a link, but the bug tracker is undergoing maintenance.

https://docs.minecraftforge.net/en/1.19.x/concepts/events/#creating-an-event-handler

Maybe set the Notify_Client flag? (which is 2, so you want to pass 3 here) Also, rather than using ints, use the proper enum object.

https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/client/ProspectorParticle.java#L46 Mind, that's old code and there's almost certainly a vanilla class wrapper method that does the same thing. Note that this will cause the particle to always draw on top of blocks, even opaque ones. So you might want to clarify a bit. Right right. I know water does what you want, but its been a while since I looked at the fluid render code (as in, I fixed the issue you're having on Forge fluids back on like 1.6.4 or 1.7.10)

You need the faces to be double sided. I'm not sure how this is done with the json format, however.

Yeah, because the real gradient (that you want) isn't truly linear across the diagonal.* It's close though. The only way to get it to be smoother is to...break things into smaller triangles so you have more control points. But it also gets more complicated to set that up, as you have to compute the location and vertex color value yourself. *This is actually a color-space problem with respect to how our brain interprets color.

The problem is that 3d graphics are all built with triangles, so you can't get a hue-tinted diagonal line when the end points are black and white. You need to construct the quad in such a way that the diagonal edge uses the other two corners (you should be able to do this simply by moving your first vert to be last, or vice versa).

Holy cow, that is not how you should handle that. It's your OWN item, you can override the OnUse code in a custom item class instead of using events. Its for a block? Use a custom BlockItem.

Normals only have two possible directions and can generally be determined by the order in which the vertices are specified. https://en.wikipedia.org/wiki/Normal_(geometry) Minecraft's code is all a convenience wrapper around standard LWJGL calls, which is itself a Java wrapper around raw OpenGL instructions. UV coordinates are for textures.

Things-that-are-not-lines require more than 2 vertices.

https://www.curseforge.com/minecraft/mc-mods/upside-down-stranger-things-mod

https://www.eclipse.org/community/eclipse_newsletter/2017/june/article1.php

By the way, why do you have this? It does nothing useful.

You never set your block's render type, just the item.

Eg, ItemStack.EMPTY ...

Yes, but like I said, it's been a while since I looked at the relevant code.

Forge has used official Mojang names since about 1.17 (I think late in the 1.16 cycle it switched). However, 1.8.x is no longer supported. Regardless, Mojang was not publishing a deobfuscation map back then, so only MCP names exist.

Minecraft builtin recipes don't work this way. One option I can think of is to create an "uncooked jerky" item that only exists to be on the campfire and find a way for your beef strip item to place four of them into the campfire when used, rather than placing itself. You'll have to see how the campfire accepts items and find a way to inject a different item than the one you're holding (and then do it four times, rather than once). That uncooked item is then the one that gets cooked (and the only way to obtain it normally would be to pick it up off the campfire before it's done cooking / break the campfire). Of course this takes up all four cooking slots. Alternatively you could have an intermediary "cooked beef strip" item that when picked up or dropped turns itself into four beef jerky (there's hooks for both of these actions, I'm pretty sure--OnEntityUpdate is the one for it being dropped on the ground though its Mojang name might be different, not sure about picking it up, but there should be some kind of Item method or Forge event that would work). Or you treat the act of eating as durability loss rather than item consumption (but this effectively lowers max stack size to 4).

👍 Haven't traced all the calls lately, as I haven't been doing any active modding. I believe that is a separate context entry.

TLDR, in order to generate loot from a loot table you need to pass in all of the relevant context for that kind of loot table, because "I just need cow loot" requires knowing if the cow was on fire. And if the player was holding a sword with the looting enchantment. Etc etc etc. So you need to specify where the loot is being dropped, who cause it to drop, what is being dropped, and so on. All of that it put into the loot context builder. Look for existing usages of LootContextParamSets (Oh and be sure to pass the result through ForgeHooks.modifyLoot)

Use separate blocks. Welcome to The Flattening.

Not sure, I haven't dug into the minecart code that much. The only problem I see is that this: Math.pow(targetVelocity, 2) - Math.pow(entryVelocity, 2) Is guaranteed to return a negative value, which when multiplied against entity motion would cause the entity to reverse direction.