UberAffe

I am creating a model in code by generating BakedQuads, using this constructor public BakedQuad(int[] vertexDataIn, int tintIndexIn, EnumFacing faceIn, TextureAtlasSprite spriteIn, boolean applyDiffuseLighting, net.minecraft.client.renderer.vertex.VertexFormat format) what are tintIndexIn, and spriteIn used for?

That BakedQuad constructor is deprecated, this is the one that is recommended to be used now public BakedQuad(int[] vertexDataIn, int tintIndexIn, EnumFacing faceIn, TextureAtlasSprite spriteIn, boolean applyDiffuseLighting, net.minecraft.client.renderer.vertex.VertexFormat format)

you found a book for 1.7.2??? You can have an environment for every version and a playable exe for every version if you want. I would still recommend using 1.8.9 or 1.9 for your environment, for the most part the way the book tells you to do something will still work in the new versions, the biggest differences are in custom models and the syntax for registering (although that only changed a little bit).

You can work with multiple versions of minecraft without a problem, I was just checking that you are using the right environment.

Just making sure, you are using minecraft 1.7.2 is that the version you want to make a mod for?

I have a series of many small building blocks and any of the building blocks could be in any of 16x16x16 positions for a block, it is also possible to add more building blocks through an api, which unless I completely underestimated the json system I don't think it can handle this. What should I be looking at to try accomplishing this?

I register my items like this and it hasn't been a problem for me. GameRegistry.registerItem(MeleeCore.instance, Refs.MODID + "_" + MeleeCore.instance.GetName());

I don't think the example mod gets downloaded by default anymore. at least I haven't had it show up in my stuff for a long time. And using 1.8.9 shouldn't make a difference, that said I recommend moving to 1.9 and try convincing your friend to also. With 1.9 already out and not much of the community playing in 1.8.9 yet it is very likely that majority of people will just skip straight to 1.9

If you do exactly the steps i put you would need re-extract to the new folder and do the same steps again. This is the process I use: 1. set up git repository 2. clone to my modding folder (in the modding folder I have a forge folder with a sub folder for each forge version that I use modding/forge/<mc version>/<forge version>/extract 3. make a copy of the extract I need and put it in my cloned folder 4. in the cloned folder run "gradlew setupdecompworkspace eclipse" If you are working with someone else you would just clone a branch of their project instead of making new repository.

From what I can tell that is the setup if you want to make changes to forge itself not make a mod with forge.

The most basic setup is to do this: 1. download forge mdk version that you want 2. extract it to the folder that you want to contain the src of your mod 3. set up your system path variable to the java version you are using 4. open a command prompt inside of the folder that you extracted forge to 5. put this in CMD "gradlew setupdecompworkspace" 6. "gradlew <IDE>" eclipse/intellij

what ... regardless of your IDE the first step in getting your environment setup is running gradlew setupdecompworkspace (i guess aside from making a git repository but that isn't really part of the environment) what tutorial are you following?

I made a branch of my project that builds and has the bug happening for anyone that wants to take a look at it. Project Edit: The base command is /lidr and the default keybinding for creating one of my items is f.

You should only need a path variable for your jdk. You might just need to rerun setupdecompworkspace and intellij again. It won't hurt any code you have written.

I don't know the process for Intellij but there should be somewhere that you can configure the build path for your project and you will want to add that jar to you libraries.

I think it was possible to do before it just didn't have a guaranteed behavior because some vanilla systems aren't designed to accept larger stack sizes. I don't believe that would have changed so unless someone says otherwise, make it larger at your own risk.

I don't know enough about what libraries forge uses or what classes come from which libraries but I think that is from the guava-17.0.jar. Your best bet would be to change title of this to something like <minecraft version> file not found while building. You should probably also edit your original post to highlight your current problem. I have found that people here respond quickest to blunt questions as long as show that you have attempted something and they can see the results (error log, etc)

float range = ((float)item.partMap.GetHeight())/16.0f + 1.5f; Vec3d pVec = player.getPositionEyes(.5f); Vec3d tVec = pVec.add(player.getLookVec().scale(range)); LogHelper.info("Player is at " + pVec); LogHelper.info("Target is at " + tVec); RayTraceResult target = player.worldObj.rayTraceBlocks(pVec, tVec,false, true, false); LogHelper.info(target.typeOfHit); This is the call I am using and pVec/tVec have a value for each Coord, but the last line always has a null pointer exception. Even with hard coding the range to 10 it always gives null. Edit: Slight wrong, If I aim at an entity and there is nothing behind it but air I get NULL. If I aim at an entity and there is a block behind it I get Block . Which seems like it doesn't work for entities anymore.

This is the correct place and it looks like you might be missing a library since it is getting a file not found on an inherited class.

Ok ... new problem. With nothing in my hotbar the Bars render properly. when I have one of my items(with a custom model loader) the colors of the bars change. when my item is not selected the bars turn black. having a stack of 2 of any other item makes the Bars render correctly regardless of selected item. Edit: If I look around really fast it will occasionally show the correct colors for a moment.

I couldn't find any raycast methods in player.worldObj, I found three methods that were variations of rayTraceBlocks with different params. Although #findNearestEntityWithinAABB seems to be doing what I want.

I tried that one and a bunch of other but they all had the same problem. Well at least its just a few boxes and lines, that's not too bad to render multiple times.

Ok, so something must be wrong with ElementType or maybe its just a case of not being able to use ==, but I removed the if test and it works just fine now. Is there a downside to not checking the element type?

I have a some mana bars that get rendered on to the screen, the catch is that it only works when I have a stack of 2 feathers in my hotbar and I have no idea why or how that could possibly effect it. My CustomHud The Bar that gets rendered The log helper you see in the Bar renderer prints out the correct color values regardless of if the bar actually renders.

I know it has to happen somewhere but I was curious if it was already happening somewhere so that I wouldn't be writing duplicate (probably less efficient) code.