Draco18s

THAT is a definition I can work with. I'll probably still refer to the value in object.value as a field or property interchangeably, though, as it comes down to an implementation detail inside the class that isn't relevant when talking about "that thing that is named 'value' and is part of the definition of the thing named 'object' " How often does this come up when not dealing with ASM or [thing I don't have a word for, that is what Forge does, patching? (de)obfuscation?]? It's a question that I cannot even attempt to analyze because the only Java work I've ever done has been for Minecraft via Forge. That is, outside of Forge and Forge-like software, how often is binary compatibility an issue?

Its not that difficult to do, if you open the JAR file as a zip and find the MANIFEST.MF file (inside the META-INF folder) and open it in a text editor, if it has the FMLCorePlugin value set, then it's a coremod (more accurately: if it is not set, it cannot be a coremod, if it is, you would have to examine the indicated class in JD-GUI to look for the annotations* that declare the class for being loaded for the class transformation events--ie. coremodding--but the only reason that it would be set would be if the developer went out of their way to set it because they need to perform those operations). *Deliberately vague.

This is mostly a question directed at @diesieben07. One of these days I'll figure out why a Field and a Property aren't the same thing. I certainly recognize the difference between these as a declaration: public float value1; public float value2 { get; set; } The problem is that from outside the class (i.e. seeing only someObject.value1 and someObject.value2, both of which can be read and written), they behave / appear to behave the same way (ignoring the fact that value2 can be made read-only or write-only). In trying to look up the difference, I got these three descriptions (thanks Stack Overflow): (Eesh, how vague.) Which...doesn't help (underscoring added for emphasis). The only seeming distinction is the fields are (usually?) protected* and properties are (always?) public. Wait, if fields are protected, why mention that "unless specified, they aren't static"? Is a static field still protected!? *protected here meaning to refer to either protected or private.

No. Christ. getIntArray returns a value that you then proceed to do FUCK ALL with. You want to read a value out of the NBT? STORE IT SOMEWHERE. It does not magically get saved into your LearnedSpells property.

That's easy. Compare and contrast: https://github.com/MamboDancer/minecraftmod/blob/master/src/main/resources/assets/ttb/recipes/pickaxe_terrifying.json#L16 https://github.com/MamboDancer/minecraftmod/blob/master/src/main/resources/assets/ttb/recipes/theterrifyingblock.json#L13 What is different? (Hint: count the amount of white space)

@Override public void deserializeNBT(NBTTagCompound nbt) { nbt.getIntArray("LearnedSpells"); } Oooh, a value! *throws it in the garbage.*

nbt.setIntArray("LearnedSpells", Ints.toArray(knownSpells)); // :O SUCH MAGIC

You don't need it at all. You never did. I don't know why my last comment made you think "oh, this should be a property" and not "oh, I need to not do this thing he told me not to do."

You need to register an event handler for PlayerTickEvent, check the player's equipment (you get the player through the event object) and if they have boots, get the enchantment power for your enchantment from the boot stack (there's an EnchantmentHelper function for this) and if its > 0, allow flight.

new ItemMonsterPlacer() is the Item, isn't it? You should be putting an ItemStack in there, I would have thought.

Vanilla might've provided it, but vanilla also disregards it in a lot of places too, opting for a blank string.

No resource domain -> minecraft* *Provided by Forge

Vanilla isn't a mod, so it doesn't have a mod ID. Mods should have a : though.

Unfortunately, not for this. If you try to set the player sleeping, they'll unsleep the next time the update code runs, popping them out of the sleeping state in a way that you (as a modder) can't cancel. You can replace EntityPlayer with a new subclass, but you are correct that it could break things (e.g. conflict with other mods that also replace EntityPlayer, like Galacticraft). There is no way around this, beyond the previously mentioned alternatives.

Your Durmstrium ladder does not implement IHasModel, so you never register a model for it. (And this is why I hate the IHasModel method of supplying models. There are so much better ways. Hint: fucking everything needs a model registered... except when it doesn't)

You have two three options: 1) Find a way to replace the object that the code is in with your own version of that class. Doing this ranges from medium difficult to almost impossible, depending on the object in question. 2) Core mods, which are heavily discouraged. Do not do this, do not ask for help doing this. If you do not know how to do this no one will tell you. 3) Make a pull request to Forge to insert some kind of event or other modification that will allow a mod to hook into the behavior and override the vanilla mechanic. Then wait six to eight weeks for your PR to get approved.

Generally...you don't

Mathematically this is an inverse. And I believe there's already a "secret setting" shader that does this (there is, ctrl-f, invert). But if not...you could write one.

You would need to find a way to remove that check.

Why are you performing the conversion on line 1? What is the point of this? Whatever it does, the result is immediately overwritten by line 2. return nbbt; You have a typo. diesieben07 may have more input as well. There's something I'm scratching my head over, but can't articulate what I think you're doing wrong.

Right click -> references -> find in project

Define "negative color."

On ILearnedSpells (your capability) should not extend INBTSerializable : https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/capability/RawMechanicalPowerHandler.java#L8 On LearnedSpellsStorage::readNBT checks if nbt is an NBTTagIntArray and if so casts it to NBTTagCompound : You should read the NBT by reversing whatever writeNBT does: read out an NBTTagIntArray.

Are you making a mod? No? You're in the wrong place. http://www.minecraftforge.net/forum/forum/18-support-bug-reports/

That's handled by ItemSword as well as some bits elsewhere in the code that check for instances of ItemSword