Draco18s

I certainly haven't been. It's a 1:1 input:output in terms of ItemStacks. Kind of like the furnace. Stack of A becomes a Stack of B, so I've just been storing it as a HashTable<ItemStack,ItemStack>.

You need to create a particle class that extends EntityFX. As far as I've been able to figure out myself, creating a "stream" of them is really just spawning a bunch of them at once (think of a particle as an entity: creating a line of particles would be similar to creating "a line of skeletons"). The hard part is making the textures work correctly. See line 59 and 140: https://github.com/Draco18s/Artifacts/blob/master/main/java/com/draco18s/artifacts/client/AntibuilderParticle.java

That's an oxymoronic statement if I ever heard one. If it crashes, its not flawless. From what I can tell, whatever you're doing is causing liquid updates. There's a huge number of cyclic calls to BlockDynamicLiquid#updateTick on that stack trace.

Good f*sking luck with that. Every mod is going to store their own machine's recipes in their own classes. For the mod I'm doing, that's one class (with several getters). For other mods, it might be many classes. For Thermal Expansion, download their API.

You don't have Java JDK installed.

Programming Sucks at a high level of abstraction enough. Having to think in single-byte instructions is maddening. Two freaking days to write 11 lines of code that insert 2 lines (in regular Java) into BlockCrops. #NeverAgain

That's not what @SideOnly is for.

Yeah, don't use bitwise AND unless you know what you're doing. Eclipse should throw an error...

Fill the volume with invisible technical blocks that do not allow replacement (and otherwise are treated as air).

Unfortunately, I cannot tell which line in your pasted code is TileFuelGenerator.java line 366.

It does look like that, but here's how it's used in EntityLivingBase.java: public void swingItem() { ItemStack stack = this.getHeldItem(); if (stack != null && stack.getItem() != null) { Item item = stack.getItem(); if (item.onEntitySwing(this, stack)) //<-- RIGHT HERE { return; } } if (!this.isSwingInProgress || this.swingProgressInt >= this.getArmSwingAnimationEnd() / 2 || this.swingProgressInt < 0) { this.swingProgressInt = -1; this.isSwingInProgress = true; if (this.worldObj instanceof WorldServer) { ((WorldServer)this.worldObj).getEntityTracker().func_151247_a(this, new S0BPacketAnimation(this, 0)); } } }

And of what type is the ArrayList?

Man, I fcuked up my own URL tags by including the second link! Haha.

Fixed that mangled GitGUI] GitGUI is pretty easy to work with, once you have it set up correctly. It has its flaws, but for pushing and pulling a repo to GitHub its very simple.

Going to drop this in here because it's relevant.

I think it will be more used than those skipped versions in the past, but yeah, there's going to be a A LOT of people--the lower skilled among us and those with less time--who will look at the sheer number of things that they'll have to relearn and say to themselves, "I think I'm happy with 1.7.10, I'll just add Gany's Surface for the 1.8 stuff."

Your TileEntity

's what everyone else says. And by "everyone" I mean the 12 year olds who claim 4 years of Java experience and can't figure out why casting an Entity that's an instanceof EntityWolf to EntityPlayer crashes.

That sounds like you're missing one of two things: 1) getDescriptionPacket and onDataPacket methods 2) if (worldObj != null) worldObj.markBlockForUpdate(xCoord, yCoord, zCoord); inside your setInventorySlotContents method.

It might Have Something to do With The capitalization Of your Texture files and Folders. Does the Case that you Used in your Code match, EXACTLY, the case Used in your file Structure? Windows doesn't give two shits if its a T or a t, but once it's archived into a JAR or ZIP file, it does.

Unfortunately that doesn't seem to be true for 1.7, I think you're right that it was possible in 1.6 but it's been eliminated, the renderer only ever performs pass 0 and 1, and it skips pass 1 if getRenderBlockPass() doesn't return >=1. Aw that's a bummer.

While this isn't going to solve your problem... SummonSphereShoes var2 double var3 double var5 double var7 Egads man, use intelligent variable names, please. This reeks of decompiled and copy-pasted code. this.rand.nextInt(3); /*...*/ getRNG().nextFloat(); Dafuk? Why didn't you use this.rand both times? It's a protected variable, there's no reason to use the public getter, much less using it in one place and not-using it in another inside the same method.

That: @Override public int getRenderBlockPass() { return renderPass; } Is not what that is for. That function is supposed to return which pass the block renders in, not what pass the rendering is on. Basically, Vanilla is asking your block what pass it needs to render in, you return a 0 (default value for an unassigned integer), which it then goes on to render a Pass 0 and a Pass 1 (your block cheating and getting both) and then finishes with having done two passes (leaving a 1 stored in renderPass, so the next time that getter will return 1, having changed nothing). If you need a third, make that function return 2. IIRC that will cause the Vanilla code to see that "at least one block" requires a third pass and will loop through an extra time.

Probably a mid-point step towards the API. I suspect there will be a revision farther down the line that will make it "simpler" again while retaining the benefits of the new system. But...it probably means I'll be skipping 1.8