Draco18s

ItemStacks are not entities. Entities can be dead, ItemStacks are nullified. Dropped items are EntityItem entities that contain an ItemStack.

That can't be your entire build file. The default one Forge ships looks like this: buildscript { repositories { mavenCentral() maven { name = "forge" url = "http://files.minecraftforge.net/maven" } maven { name = "sonatype" url = "https://oss.sonatype.org/content/repositories/snapshots/" } } dependencies { classpath 'net.minecraftforge.gradle:ForgeGradle:1.2-SNAPSHOT' } } apply plugin: 'forge' version = "1.0" group= "com.yourname.modid" // http://maven.apache.org/guides/mini/guide-naming-conventions.html archivesBaseName = "modid" minecraft { version = "1.7.10-10.13.2.1352-1.7.10" runDir = "eclipse" } dependencies { // you may put jars on which you depend on in ./libs // or you may define them like so.. //compile "some.group:artifact:version:classifier" //compile "some.group:artifact:version" // real examples //compile 'com.mod-buildcraft:buildcraft:6.0.8:dev' // adds buildcraft to the dev env //compile 'com.googlecode.efficient-java-matrix-library:ejml:0.24' // adds ejml to the dev env // for more info... // http://www.gradle.org/docs/current/userguide/artifact_dependencies_tutorial.html // http://www.gradle.org/docs/current/userguide/dependency_management.html } processResources { // this will ensure that this task is redone when the versions change. inputs.property "version", project.version inputs.property "mcversion", project.minecraft.version // replace stuff in mcmod.info, nothing else from(sourceSets.main.resources.srcDirs) { include 'mcmod.info' // replace version and mcversion expand 'version':project.version, 'mcversion':project.minecraft.version } // copy everything else, thats not the mcmod.info from(sourceSets.main.resources.srcDirs) { exclude 'mcmod.info' } } The important bit here, is from(sourceSets.main.resources.srcDirs) { exclude 'mcmod.info' } You can exclude more things there, if you need to. Say from(sourceSets.main.resources.srcDirs) { exclude 'mcmod.info','enviromine/**','cofh/**' }

@Override public boolean hasContainerItem(ItemStack itemstack) { return false; } Dude. False? Really?

1) Extend ItemTool 2) Have it override hasContainerItem and getContainerItem . These will cause it to be left in the crafting grid and take damage (getContainerItem should return the same stack given, but with 1 point more damage).

I'd first try setting the applifier negative. For invisibility and night vision, there is no mechanical effect, but if that stops the particles, that would be the best solution. Failing that, the data watcher, as if you're invisible you should be.....invisible.

Um.

entityItem.getItem()? It's an entity that contains an item stack which references an item. It's not that hard.

I'm seeing a little information that "for some potions (like invisibility) giving a negative amplifier negates the particles." There's also a command to hide them. Hmm, found someone who figured out that if you set the player's datawater's 8th object to 0, that removes particles as well: http://www.curse.com/bukkit-plugins/minecraft/removepotionparticles (Source is linked in the description)

entityItem, of type ItemStack , will never equal Items.bread, of type Item .

diesieben said that CoHFCore is designed so that it's API shipped with any mod that uses it. You said that if you "look at buildcraft, you'll find the CoHFCore API inside the buildcraft jar" which is quite literally what diesieben said.

Uh.

/** * This event is fired once the texture map has loaded all textures and * stitched them together. All Icons should have there locations defined * by the time this is fired. */ Try using TextureStitchEvent.Pre

His mods don't actually depend on each other, I didn't think. Either way, yeah, his setup is a mess IMO. And yes, you could probably do that. Me, I just need the RoC api to work, and the Extractor API (which I requested and he built because I wanted to handle things differently) doesn't even work yet. I ended up basically compiling up my mod calling his API in the supposedly intended manner, and saying "Here. This calls your API. Figure out why it's crashing when I do." Ironically, the extractor requires a block input and the ore I'm trying to supply is an item, so I had to package the ore up as a block, http://vignette1.wikia.nocookie.net/reasonable-realism/images/1/10/Grid_Hard_Ore.png/revision/latest?cb=20150419190850[/img], and just give it the right ore dict name ("oreIron" etc). I can't oreDict the actual ore that way, because it's worth an amount of ore dependent on its metadata, not "1 ingot" and the Extractor API runs off oreDict names, not item stacks. (That graphic doesn't read well on white, and I can't change the background color of the post behind it...make it a link, there, ha, make the browser do my work for me. Basically, I didn't know what to make a "stack of 9" look like as a block, so I made it a storage cube with the item graphic drawn inside as crossed squares, like the example in the multiple pass blocks tutorial).

int x1 = chunkX + rand.nextInt(16)+8; int z1 = chunkZ + rand.nextInt(16)+8; Bad code monkey, no cookie. You just told it you don't want to generate in this chunk but rather that chunk over there. A chunk is only 16 blocks wide, why the hell are you adding 8? That said, here's your problem: place = false; if(place){ //setBlock() }

This is true.

Note: Chunk load/unload is threaded. Be sure to use a thread-safe HashTable ( ConcurrentHashMap I know exists, so there's likely a ConcurrentHashTable as well).

CoFHCore, I believe, is also more than a library. That is: it makes changes to Vanilla. Say...by disabling wither skull drops.

NBT is key->value. Don't know, or don't use, the key? You don't get the value.

It's a fucking item. Call its constructor the same place and the same time as you call the constructors for all your other items. And its parameter types are clearly listed, especially if you follow the super constructor and actually LOOK at ItemArmor. ArmorMaterial, armorType (what slot it goes in), and renderID. Hint: You will need to define a new ArmorMaterial.

Those events have a getData() method which returns, unsurprisingly, the chunk's NBT data.

int l3 = i3 * 16 + i2; int i4 = k3 * 16 + k2; j1 = j1 * 3 + 0x3c6ef35f; int j4 = j1 >> 2; int k4 = j4 & 0xf; int l4 = j4 >> 8 & 0xf; int i5 = k4 + l3; int j5 = l4 + i4; Hold on. Is that a pseudo-random number generator? Why? Why for the love of god did you write your own RNG and then supply it with inputs that were already random?

Might want to start doing that. Eclipse has a nice feature called "open type hierarchy."

ChunkDataEvent.Save ChunkDataEvent.Load

No, I did not. I assume I run this in the command prompt inside my mod folder? Uh huh. Like it says in the readme. (though you'll want setupDecompWorkspace, rather than the readme's setupDevWorkspace)