MuffinMonster

Have you tried looking up source for the bat? It does fly around and "land" on blocks upside down, maybe you can find something useful there.

Why don't you use a tileentity and use the metadata to change the appearance of the block? Also, a tileentity allows you to modify the block data in the onUpdate(or something similar) method which gets called regularly on the entity. If you need to fix the code you got you'd probably want a return statement where you turn the block into the "on state", the way you have it now it just turns into the block into the off state immediately after it has turned it into the On state.

As I have seen the ItemRenderer only draws items in first-person mode. Isn't this the case?

As noted in the last thread the positioning and rotation of a bow in hand (Note: Third-person view) there are only 2 places that handles the translation of the bow, ItemRenderer and RenderPlayer. There is the ItemRenderer class but as the comments note those methods render the item in First-person mode, and the misplaced bow is seen in third-person(Aka. The bow in First-person view is already rendered correctly). To be specific, this is the method I need to change: (It begins at line 345 in RenderPlayer) else if (itemstack1.getItem() == Items.bow) { f2 = 0.625F; GL11.glTranslatef(0.0F, 0.125F, 0.3125F); GL11.glRotatef(-20.0F, 0.0F, 1.0F, 0.0F); GL11.glScalef(f2, -f2, f2); GL11.glRotatef(-100.0F, 1.0F, 0.0F, 0.0F); GL11.glRotatef(45.0F, 0.0F, 1.0F, 0.0F); } This check, itemstack1.getItem() == Items.bow is not compatible with my custom bows, which means those translations and rotations never happen on my held bows. That's what need to be changed.

Well, to start of with my knowledge of what RenderPlayer does is pretty much null(I think it's about rendering the third-person character) but I need to be able to change one method inside that class. Now I do know how to override and change the method but getting forge to actually call my changed method instead of the default one is where the problem is located. The method is renderEquippedItems() If you didn't know this is kind of a followup on my last thread on bows. Any help is appreciated.

Ah, well, If you ask me I'd rather use the new Object[]{} instead of just adding everything as parameters just because of nicer formatting using the brackets. Anyways, good to know, thanks!

What would you put in there? Just for the sake of learning

We need more than that to go on. The only thing I can tell from that is that you're trying to add null to the registry, maybe you're doing "GameRegistry.registerItem(null,someStringName);" ?

Do you have a @Mod tag in your main mod file? I have a similar working setup as following: @Mod(modid = Constants.MODID, name = Constants.NAME, version = Constants.VERSION) Also, is your mod in a different java project? Because I see that you got a Minecraft project AND a "LivelyAnimals" project that your files are located in. Try moving the java files into the Minecraft project under "src/main/java" and the mcmod.info to "src/main/resources" (As noted by Iarsgerrits)

Thanks!, I'll have to look into how you'd do that then.

I'd say that you could try to run "gradlew eclipse" again to see if that helps or even "gradlew setupDecompWorkspace" if the first doesn't work. These shouldn't modify your mod files.

Afaik the way you register eventHandlers is by using MinecraftForge.EVENT_BUS.register(new EventHandlerClassHere() ); in the preInit or preLoad method. EDIT: Also you should be using @SideOnly(Side.CLIENT) When you're working on the clientside.

If you didn't see the difference in the code SanAndreasP posted and yours it's here: spawner1.func_145881_a().new WeightedRandomChestMinecart(nbt, entityName) This creates a new WeightedRandomChestMinecart object with the specified parameters

Well, yea. That's what I'd do, however I do not have even the slightest knowledge how the world generation works in Minecraft but that's how I'd do it. Another thing to note is that you might want to check the max-height there. Afaik the terrain in minecraft can sometimes reach about 240 blocks up (technically I think it may go all the way to 256 but it's not likely) but that means that if your tree is 11 blocks high and you create it at a height of 245 your tree will try to grow outside of the world. This is just a side-note and is doubtfully the cause of your crash but it's noteworthy. Also, just to clarify, does your minecraft run without the generation code? Caused by: java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path This seems rather strange to me, though it could be a sideeffect of some other faulty code.

Is it just me or would your code for the tree Y position have some nasty sideeffects? int randPosY=random.nextInt(250); //Max Y coordinate afaik, random.nextInt would give a random height from 0 to 250 in this case, and the tree should be on the ground level, not randomly flying or appearing underground which would be the case here.

So does that mean that I'd have to create my own itemrenderer for the bow only?

Well, in this case it might not be a too noticable change in performance, it all depends on the size of the texture(and compression level). As the size as mentioned is about 2k x 2k it's pretty big, and reducing the size to about 15x16 would save some memory. And then there are more than one way of using those parts, either stich them together when loading(which kinda removes the benefit here) or just using a couple more drawcalls to draw each piece onto the screen at runtime. And for texturepacks, the size for each piece doesn't have to be fixed, it can be flexible which means that texturepack creators have as much freedom as with one picture(though this might prolong the process of saving the image when you have to cut it apart) This is mainly used for webpage design where each kB saved is better, in this case it really doesn't do much else than saving some MB of RAM(again, depending on original picture size) and squeeze a couple of drawcalls out of the GPU.

Uhm, one last thing here. I noted that the position and rotation of the bow in the hand is way off now. I tried with setting the setFull3D() function but it's still not correctly placed. Is there a way I can change the position and rotation of the bow while pullin it?

The thing is that I do not know if it's hardcoded or not because I cannot find where the code for it lies. Anyway, this issue isn't noticed if you use the bow normally so I'm just going to leave that as is for now. At least I got the Fov to change thanks to you!

One performance improvement would be to cut the big image into smaller parts and just repeat/stretch those parts. You could cut out one corner and a one pixel thin line of the frame. Out of those you could draw (stretch and rotate) the whole frame with a much smaller memory footprint for such a simple thing as a frame.

As noted before it's not the texture that is the issue, it is synchronized based on the pulltime so no problem there. A bow kinda has 3 different animations: - Fov change - Texture change - Bow position change(move and then shake) The Fov and texture is working properly, its the moving and shaking of the bow that's the issue(The time when the bow start to shake is hardcoded to the default bow pulltime). I'm not sure if this requires some extra classes or some deep minecraft source digging to find the root of the shaking or what.

One workaround would be just recoloring a snowball(with no gravity applied to it) and use that as the "beam".

Yea, it does work, somewhat(The animation enum is set to bow by default at the base ItemBow class so no further code needed). The animation first slowly moves the bow closer to the player and at full tension the bow starts to shake, when I modify the pulltimes the animation gets offset from what the custom bow actually does. This isn't a big issue though so I'll manage without going deep into the coding for it to fix a fraction of a second.

As I check the FOVUpdateEvent I cannot see anything else than the fov variable, and the shaking occurs on the item itself, not the camera. May there be a function for it inside the Item class maybe?

One thing to note with getItemDamage() is tools or other damageable items, in those cases I'd say you'd have to check getHasSubtypes() aswell to see if there are other types of blocks/items on the same id. (One alternative is to call isDamageable() on the item, they are almost the same)