LexManos

NOT ALL BLOCKS NEED ITEMS! The old method is a LONG standing hangover from back in the day when we had to make sure both were the same ID in the constructor. Now, they are completely separate registries with no real link between the two. If you want an item, then opt in for a item.

Don't make coremods, what you're doing and how you're doing it is extremely bad.

I've finished the MCP update for 1.9.1 and 1.9.2. Once bspkrs/Searge decide to release that we'll be updating to 1.9.2 for Forge. However, the changes are MINIMAL, seriously look: 1.9.0 -> 1.9.1 1.9.1 -> 1.9.2 90% of the 'changes' are just constants being inlined by the compiler.

Actually no, his 'non-srg' detector is just dumb. There are a lot of 'Non-srg' methods in Forge's code base.

Reika seems to be doing something stupid, coremod and other crap. Our advise is to remove DragonAPI.

Magically, No. However we DO have mechanics in place for Mods to tell us what versions of MC they are compatible with and we skip over the ones that we know are not compatible. So yes, thanks for the blatantly obvious suggestion on something we already do. If a mod loads for the incorrect MC version that's the mods fault for explicitly going out of their way to REMOVE that information we encode in them for this purpose.

No we are not rewiring the world save format/networking/every 3rd party map editing/viewing software. Seriously You think we haven't said to ourselves "Wow it would be nice if we had these blatantly obviously restrictions lifted" We have. It's not gunna happen there are to many downsides.

That's not how rendering works we cant just wave a wand and say 'here you go GPU is now doing it!' 1.8/1.9 do LARGE strides to move the rendering away from the CPU, but that's the #1 thing modders are bitching about because it means they have to adapt. As it sits, we are not in the market of rewriting extensively large swafts of Minecraft. So no.If Mojang continues to change to better rendering we will encourage and make it easier on modders to move, but we don't dictate something this fundemental.

Auto mod downloading like this will not be supported or endorsed on this forums. There are fsr to many security issues to even contemplate this.

That the install log, and its a successful install... so.. give us the launcher log please.

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.