LexManos

Sepends on what exactly you mean by slowly. And keep in mind that optifine may have bad interactions with forges edits. In forge we thread passive chunk loading so chunks MAY be slightly slower (in some cases) but the rest of your game runs smoother. So... again, no idea what you're actually talking about as you're just saying vague anicdotal stuff. But everything should be working fine.

No

Then sneak click and have your item return true for 'doesSneakBypassBlock' or whatever the hook is named.

We have hooks in place to allow you to be any type of tool, inculding multiple types of tools. If you want to make sure you enchant all Axes, then ask the item what tool classes it is an if it contains "axe" enchant it: https://github.com/MinecraftForge/MinecraftForge/blob/1.9/patches/minecraft/net/minecraft/item/Item.java.patch#L504-L541

Umm seriously you guys need to stop guessing and learn how to do your own debugging. The issue is that ItemAxe has two arrays for damange and speed that are indexed by the tool material. Why they have this instead of using the normal values, i don't know. But simple solution DONT extend ItemAxe, instead extend ItemTool and set your values accordingly.

We are actually debating on removing onFirstUse as the new mechanics in place make it redundant and the common practice being SHIFT click being the same effect as onFirstUse. I'd like to see your argumetns for keeping it so that we can be better informed of how the community is using this hook and better decide if it's needed anymore of not. On the other side of that, Interact events are being re-worked as the entire interaction system changed in 1.9.

We are currently looking into the exact ways we want to hook into this new system. I've been SUPER busy the last 2 weeks. and will be until at least Tuesday. But people are looking into it. We're trying to figure out a way to uniquely identify sections of the loot tables so that they can be referenced. So ya, stay tuned.

You can import it it's a public class. anyways.. could be fixed with a simple PR to change those methods from protected to public. So that the class can be used outside of the BiomeGenBase class/SubClasses.

It should be possible, as long as your Context extends Forge's Context you should be fine. As this is the power of generics. We have examples in vanilla code.

Are you in creative mode?

Update.

Capability and Capability PROVIDERS are different things. ICapabilitySerializeable is a Serializable Capability Provider. I just knocked off the Provider part of it because thats a long fkin name. Take a look at this: https://github.com/MinecraftForge/MinecraftForge/blob/1.9/src/test/java/net/minecraftforge/test/NoBedSleepingTest.java The Default implementation and the storage provider are DEFAULT serializers. As a normal modder {Not the one writing the API} my implementation of saving/loading is just this: public NBTPrimitive serializeNBT() { return (NBTPrimitive)SLEEP_CAP.getStorage().writeNBT(SLEEP_CAP, inst, null); } @Override public void deserializeNBT(NBTPrimitive nbt) { SLEEP_CAP.getStorage().readNBT(SLEEP_CAP, inst, null, nbt); } I can do that for ANY capability. I dont need to care that IFuelHandler stores 100,000 NBT elements. Or Sleep stores one. I will get one NBT object from the storage handler and I know that it will load and save the state completely fine. Now here is a important part: The storage handler is ONLY garenteed to work for the DEFAULT implementation. SLEEP_CAP.getDefaultInstance() If I have a some custom handler that relies on 15 different things and needs to store them all in the NBT. Then I will have to write my own serializer. So ya remember ICapabilityProvider and INBTSerializeable are two different things. I made ICapabilitySerializeable PURELY as a convenience interface so that my patch files can be smaller. See My comment Get it now?

The annotation can go anywhere as long as it's static. And you need to have a default implementation of your capability. You don't need to USE that default implementation. You can do whatever you want. Caps can do everything that IEEPs can. If you design them correctly. The problem with your old design is it's the exact opposite of IEEP/Caps. You're having a central storage {atleast thats what it looks like from your snippits} of entity -> data. Instead of having the data IN the entity itself which is what caps/IEEP is supposed to do. Give more code, and explain what you've tried.

We do not support cauldron. It's a dead project.

Yes the behavior is bugged in 1.9, due to a change it's been fixed. I forgot to put a UP check in one if statement. Again, SOLID surfaces BLOCK CHESTS. This is simply how the world works. Vanilla being BUGGY and having a half-assed side-solid system IS A BUG. It does not make logical sense. We have fix this bug for ages, and in doing so it enables a lot of special mod features like microblocks/covers/special placements.

Fixed

FFS! Use this! https://github.com/MinecraftForge/MinecraftForge/commit/1a31ff9f065220ea169fbbdd383019c2b7f1f583 And the damn language files DONT USE THE LANGUAGE REGISTRY.

Clay Dolls is broken and is using a system that was deprecated 3 years ago, you should yell at them to stop being dumb and update. There is literally nothing we can don on our end for them using this old broken system.

1) We do not support cauldron. 2) You should update to 1.8.9.

Actually the JSON spec DID support comments for a little while but it was as a 'reader can read them but writer will never write them' They were removed after the guy got annoied. Anways, models are not loaded with this 'leniant' flag enabled so no comments. Sorry, JSON is annoying like that.

Vanilla updates and adapts to new things. A lot of the time taking Forge's designs and integrating them into what they need. ISmart* being one of the cases. We DO NOT 'bolt' things onto stuff to make it stay relevant. If we did that we'd just have people bitching at us to do it for 'just another version'x100 Recently Mojang has been working on the rendering stuff. So that has been effected a lot. It's just how things go. Don't complain about it enjoy the new features! @Draco: Quit it with the 'reasons im not touching 1.8' or you'll be getting a ban -.- we don't like whiners around here.

Humm I wonder if there was something you could give us that would tell us exactly what is going on and what the error is.... Perhaps something that catalogs everything that happens during loading... I think those things are called LOGS! But beyond that, you should update to 1.8, it's been over a year and a half. 1.9 is about to drop and when it does 1.7.10 will be OFFCIALLY EOLed on these forums.

Thanks for the report it's been reported on our issue tracker a well, I'll look into it when im back in town on monday.

xray is broken we dont support it, or any other coremods/hacks.

1) 1.7.10 support is not provided anymore, 1.8 has been out for a year+ and 1.9 is almost out. Update. 2) Forge does control ids and will not have conflicts unless you have a mod installed that is screwing around with the internals.