Draco18s

It's the camera near-clip plane. I am not sure where it's defined.

Mod entity ids are sandboxed to your mod. Start at 0 and go up for each mob you have.

You have this: this.gatePosition = new BlockPos(pathpoint.xCoord, pathpoint.yCoord + 1, pathpoint.zCoord); You could add: this.gatePosition = new BlockPos(pathpoint.xCoord, pathpoint.yCoord + 0, pathpoint.zCoord); as a separate check.

35 blocks isn't going to make that much difference to the giant 191 block tall mountains. Oh no, 156 block tall mountains! They're still 93 blocks taller than the vanilla extreme hills, which, to be frank, already feel huge when you're looking at them.

That said, making 14 identical (except for color) blocks is easy. You just need a generic Block class that takes in the color parameter as part of its constructor and use a loop.

You miscounted slightly, diesieben07. current: 3 blocks * 16 meta = 48 current states (ignores facing) desired: 3 blocks * 5 facing * 16 colors = 240 states Either: 15 blocks with 16 states (different block for each facing; awkward) or 16 blocks with 15 states (different block for color/type; weird) or 48 blocks (different block for each color AND type, using meta for facing; numerous).

LotR doesn't have an API (apparently the author hates people making submods, what). So here's what I recommend: 1) Deobfusate his mod using Gradle (there's a way to make Gradle make a runtime jar work in dev, I forget how exactly as I've never done it) 2) Explore the source to figure out how his recipes work 3) Add your own And yes, it's legal to do this. You aren't distributing any of his work, you're merely writing code to interact with his. And that's fine. The author can grumble about it, but he can't actually do anything to stop it.

Techne is kiiiind of a terrible at making sure things are rotated correctly. Doing TESR stuff I find it always exports the code upside down (right pain in the arse to correct, too). But I haven't found a modeler that works "better." MC Animator is great for doing animations....except for the whole "the code will absolutely crash the game at some point" problem because its animation system is not thread safe.

You need a custom block render class, an ISimpleBlockRenderingHandler should be sufficient. The issue will be passing the DynamicTexture object (those are a thing, use that instead of a 2D array of color values) into the system that actually renders stuff. I've use a DynamicTexture for GUIs, but not blocks (and even that was a long time ago).

1.7 is not so hugely different from 1.6. Most of the old tutorials still apply. If I had to recommend a version other than 1.8.9 / 1.9, then 1.7.10 is the one I'd recommend. It's very well documented, the code is better MCP'd, still popular. That said, it's because it had a long lifecycle, as it took the Forge team a long time to get a grip on the changes in 1.8 and make sure that all the features modders would want would still be possible. Once that was done (hence the 1.8.9 recommendation) 1.9 was out and there was a much faster migration from the 1.8 work.

No, they just need to all be the same length. (AFAIK, "C","C"," ", 'C' should be fine, as the third one is a single space, bit it would make this 1x2 recipe uncraftable without a crafting table, which would be confusing.)

Likely the EntityLivingBase class. Possibly EntityPlayer. Find it in the Items list (that is, Items.elytra , really any reference to this variable is sufficient), right click on it and go to "References" and then "Find in Workspace." Assuming that Vanilla does some kind of getArmorInSlot(x).getItem() == Items.elytra then you'll be able to locate the code you're interested. Note: it may also use an InstanceOf check, in which case, do the same thing on the ItemElytra class.

Vanilla recipes do not care about stack size. Option A: use 3 1-size stacks. Option B: write your own IRecipe implementation.

Jesus H Chris on a Stick. Use a freaking for loop. for(int _x = -3; _x <= 3; _x++) { for(int _z = -3; _z <= 3; _z++) { if(Math.abs(_x) + Math.abs(_z) <= 3) { Block block = world.getBlock(x+_x, y, z+_z); //check and replace. } } } As for detecting source / not source: its all in the metadata. (Also, update to 1.9)

That's not reflection, that's coremod. Do not ever use Access Transformers.

Sometimes "Referenced Libraries" shows up as a folder (with forgeSrc, launchwrapper, etc) inside it, other times they just end up in a giant list. I literally have no idea why as I had two computers that had installed the same version of the MDK and one ended up with the folder and the other didn't.

ModelBakery.registerItemVariants(Item.getItemFromBlock(BarrelsBlocks.barrelWhite), resLoc); GameRegistry.register(new BarrelsItemBlock(barrelWhite).setRegistryName(barrelWhite.getRegistryName())); How do you expect Item.getItemFromBlock() to return anything other than null before you've told the Item registry what the ItemBlock is?

What mod?

Highlight canOpenDoors Right click References Find in Workspace

Ah, yes, my apologies, I misunderstood what your problem was. From my own fiddlings, you're pretty much stuck. There is probably a rendering event for the screen overlay, but I dunno about anything else.

Smartass I did, too, but I like to (at least try) to teach people the troubleshooting process. Oh sure, I'd have done the same. You just got to it before I opened the thread.

Technically speaking, 3 was fixed by: That's why I said "these were the reasons behind the decision in 1.7.10." 1.7.10 did not have a concept of layers. I understand that those issues have been addressed. Same goes for the particles. Thank you for explaining why dynamic blocks are a bad idea. I was completely unaware of those problems because you do a terrible job of advertising "doing it this way leads to a better experience, not doing it breaks fucking everything." Instead people try their best to figure out how to get the effect they want, get something half-working and you come along and go "don't do that." Interestingly, said system doesn't actually work as of the most recent information I've seen. Questionable as to whether or not it works in 1.7.10 perfectly as well. That is: no one has been able to figure out how to get it to work, even hoped you (or anyone, really) would come along and post a working example, and it's lingered without a reply.

https://github.com/KyneSilverhide/XPEssence/blob/master/src/main/java/kyne/xpessence/fluids/ModFluids.java#L25 Make your own material.

You misunderstand my use-case. I'm replacing stone. All of it. Every single block the world as it is generated. And I don't want to merely create falling entities, I am trying to provide a custom level of physics support. Each block needs to determine whether or not it has support and not just from below. Hence a custom block class is required. Which includes 4 variants, each with their own rules for falling and unique texture. BlockChangeEvent is insufficient. However there are multiple kinds of stone. Vanilla (gray) stone, basalt, granite, marble, diorite... That's why I asked. I'm interested in learning the better way. The reason I went with code-generated textures was three fold: (Note: this was done prior to 1.8 being supported by Forge, these were the reasons at the time) 1) providing pre-packaged textures does not allow for popular resource packs without explicit support (if a pack changes the texture of vanilla stone, my mod would be unable to utilize it). 2) using a custom model utilizing two render passes resulted in problems with rendering (falling entities and particles would only render the overlay texture, etc.) 3) manually combining an overlay with the base texture was time consuming (I did it with my ores and I regret it; 11 supported ores with 16 metadata texture variants: 176 hand-created textures with no resource pack support). All you have said is "they are bad, don't do them" and I am trying to understand why. I am trying to learn, so please be informative.

[me=Draco18s]saw thread title. Immediately knew this was the case.[/me]