Draco18s

You need to attach capabilities to things you don't control. Like the player. Use the EntityJoinedWorldEvent for that.

Look at how the chorus fruit handles cooldowns.

Yes. It should be LazyOptional<T>. Note that <T> here is still the type of the capability, so you'll get back a LazyOptional<IItemHandler>. Which you can then call ifPresent() on and pass in a lambda that gets executed if the capability is indeed present (non-null) or you can do something like OrElse(null) and null check (prefer using ifPresent) or use OrElseThrow().

Yes. getCapability is pretty much the only thing that interface provides.

I wouldn't use Minecraft at any stage of learning anything.

Then it isn't your textures that are messed up, but your blockstate or model files. Double check what is actually in those and verify the resource names against the file system. i.e. you're wrong and I'm right because: As far as the game is concerned, your textures are not correctly assigned.

And I'm 100% sure it isn't.

Well, you set it to null and made it final. It can't be anything else (unless you apply the @ObjectHolder annotation or use reflection).

Minecraft won't help you at all. All rendering is piped through several helper classes that then interact with OpenGL through another layer of indirection (LWJL) and some direct manipulation.

Json is text. Java is text. Text is text. Images are not text. (And I just checked my dev environment, its in UTF-8)

Changing your text encoding format should do nothing to texture files.

They would have the ability to access the slot but they would not be able to insert because the handler exposed simply returns the entire stack unmodified as the "overflow" from any attempted insertion. It would act as if the slot was full.

Yes. The wrapper is just a handler that accepts another handler as its constructor and forwards all interactions to the wrapped handler, except for insertion (which it denies). https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/api/internal/inventory/OutputItemStackHandler.java Note that setStackInSlot and getStackInSlot forwards to the hidden inventory (and in theory this could be used to insert items) because of external realities and using them in that way have Undefined Behavior. The problem I found with trying to do something like this was that I could not actually modify things internally. Because remember, extraction is modification. Also, any external access would be able to perform the same cast and modify anyway, your intended restriction be damned (remember, you're trying to make type safety--a compile time check--prevent a runtime situation).

And this is Forge's problem....how?

Have two "versions" of your handler. One is just a regular ItemStackHandler, which is used internally by your machine, and a non-modifiable version that you expose via getCapability. eg: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/entity/SifterTileEntity.java#L43 For guis, you'd also need an extract-only Slot class: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderores/inventory/SifterContainer.java#L29

I'm not sure that this can be fixed. The client has authoratative control over their inventory when in creative mode (that's literally how it works, the client says "yeah, this slot is X now"). As such moving an item from one slot to another has the effect of destroying and recreating the stack (pickup: "this slot is now air", place: "this slot is now a backpack"). Unless the client knew about the capability (and its data), then the capability gets reset (and even then, the client would have to know to send that cap data to the server).

Yep. That's a SRG name.

That's literally a loot table. Vanilla loot tables handle the first two already, the third is similar to the second. (Or you can wait for this PR, which would simplify things)

...the state of the block at that position...

world.getBlockState(pos) https://minecraft.gamepedia.com/Block_states

I misread. Anyway, if you look at the class you'd see this: public T create(C settings) { return (T)(this.factory.apply(settings); } Notice the name of the function. "Create" as in "get me a new one."

https://gist.github.com/williewillus/353c872bcf1a6ace9921189f6100d09a

Because this line: currentInventory = e.player.inventory.mainInventory; Creates a copy of a pointer to a list, it does not clone the list (changing one inherently changes the other).

No one here has worked with 1.7.10 in so long we don't know the answers any more. So, no.

Ok, so, not only is 1.12 no longer supported, you aren't even registering things right. As it hasn't really changed (until a new thing in 1.15), I'm happy to give you this link. https://mcforge.readthedocs.io/en/1.12.x/concepts/registries/#registering-things But no further support will be offered to versions below 1.14