Draco18s

You need to first know Java and type inheritance.

Make sure that you've overridden getActualState to get the fullness level from the TE

If you're on the server thread (remember: single player still has a logical server), I think it should be fine.

mappings = "stable_20" Maybe?

It is crashing, its just that it doesn't take down the whole game. There's something causing a null reference exception.

I'm not sure what's going on there. Are there any log messages?

Sorry, it doesn't extend EntityMob. I didn't actually look at your class. In that case, you'll have to duplicate the Task class and modify the declaration so that you don't need EntityMob (you will still need a superclass, probably EntityLivingBase).

Does your mob implement IRangedAttackMob? If not, why not?

Put your mob class in where AbstractSkeleton is. Add the task to your mob's AI task list.

This is how vanilla skeletons do it: private final EntityAIAttackRangedBow<AbstractSkeleton> aiArrowAttack = new EntityAIAttackRangedBow<AbstractSkeleton>(this, 1.0D, 20, 15.0F);

Correct. But as blocks are baked (the triangles don't need to be recomputed every frame) they can be streamed to the GPU much faster.

You can't do this:

Minecraft is a client side class. Turtle code is server side. http://mcforge.readthedocs.io/en/latest/concepts/sides/

Of pain, suffering, and insanity. Do not look into the void. For the void looks back.

Mhm. I gathered.

Just because it's a tutorial doesn't mean it's "right" or "best." In fact, most Minecraft modding tutorials are written by people who don't actually know what they're doing, but they managed to cobble something together that appears to work, so they did a video about it...as evidenced by comments like this one: 1) See prior comments 2) Mod IDs can be pretty long. Not super long, but certainly long enough for "technium" (it's eight characters, if that was too long we'd have run out of possible mod IDs already!) Edit: the limit is 64 characters. 3) What D7 said.

No, you're getting an object that is an instance of a class that implements an interface.

Lets look at an example. Here we have the getCapability method of a TileEntity (e.g. a chest): https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L140-L158 It appear to be returning an object named inputSlot or outputSlotWrapper, sometimes together, sometimes not. We won't worry about the distinction for the moment. Lets look at these two objects. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L41-L43 And by two, I mean three, as one is a wrapper around the third. In any case, they are ItemStackHandlers, which is a capability that is used to handle inventory: it holds (contains) ItemStacks. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L48-L50 The wrapper is done so that no items can be inserted into that inventory slot, but can be extracted. The original needs to allow insertion by the machine itself, but not exposed externally at any time for any reason. Well, ok, but what is an ItemStackHandler? And how does it relate to this line? https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L142 Well, ItemStackHandler is a class that implements IItemHandler and that line is a reference to the capability: Capability<IItemHandler> ITEM_HANDLER_CAPABILITY, supplied by Forge. Hey, look, both have something about the interface IItemHandler! So what is this thing? IItemHandler is an interface that describes the functions of the capability, what methods it has, so that external code doesn't need to know what things like SiftableItemsHandler or OutputItemStackHandler are specifically. Both (eventually) inherit from IItemHandler and any code that gets passed these objects can still hold onto them and perform the necessary functions without crashing. The interface is a contract that the classes must adhere to.

Its not. It would not make any sense for it to be.

Also: IHasModel is stupid. All items need models. ALL ITEMS. ModelRegistryEvent is client side only. This will crash the dedicated server. This can be done externally (i.e. not inside the class) just fine: Technium.proxy.registerItemRender(item, 0, "inventory"); If your item classes look like this, you don't need them at all. The fuck? You used the IProxy interface (good) method and a common proxy (bad)?

You can only do that during the TextureStitchEvent which is not a dynamic solution.

Off the top of my head, no. It has been a while since I poked at it and don't remember a whole lot.

The one with your event handlers. Whatever calls this:

Hmm

That too.