TrashCaster

What I did for my sledge hammer in a previous mod was to make the texture double resolution, so I had more drawing space to make the item longer. Then for the scale, I doubled the values (except for I think Z, so your depth doesn't scale up). So basically, your model scale should be Obviously the equations won't parse, so do them yourself and fill in the values. Resolution X and Y are the dimensions of your texture. Keep them square values (16,32,64), or else you could get distortion or texture and/or runtime errors.

What is your end goal? To apply power, without placing a power block, basically to forcibly turn on redstone dust?

nbt.setString("entity_name","EntityVillager");

Why don't you make it use player data (using IExtendedProperties, or PlayerCapabilities), and then use a LayerRenderer to render it. The item layer renderer would be a starting point. Then make it render a chicken model instead of an item model. I suppose you could also accomplish this by making a unique entity, keep it "invisible", where the entity itself doesn't render, then with a layer renderer, check that the entity is riding the player (simple way to keep it at the player's location all the time, and track when you have a chicken), and render in hand with the above method. That's just me thinking about how to re-use existing approaches, to save you a ton of time getting the math. I don't have the documentation and code out in front of me, so I'm not going to be of any help with the actual code, but I figure pointing you in the general direction, and you digging around ought to suffice. Good luck.

Like the title says. If you give yourself an item, it counts as if you tossed it, and there is no way to test that it is from a give command, since setOwner isn't called in time. I've noticed that the event fires from "dropPlayerItemWithRandomChoice", and the boolean parameter is "unused". Perhaps it could be used to signify it should have an owner?

If you drop an item from your inventory by means of dropping it out of the window, or pressing your drop key on the moused over slot, the dropped item entity (EntityItem) doesn't set the thrower. If this is considered not a bug, and it's working as intended, then consider this a suggestion.

Ok, I have solved this. I actually had the inventory loading from item every update, which caused the duping. I had originally done this to ensure it was getting loaded (cause when I dropped it on the ground, the inventory was always empty), and forgot to remove it when that didn't resolve it. It now applies the inventory to the entity from the itemstack tag when I drop it, and that fixed all of it. Thanks again for the time anyone took to read/reply to this. Mods, you can close this

No, no, that's not the problem. That's how it is supposed to function. They share the same pointer. The problem has to be somewhere in the saving/loading of the inventory. I just can't put my thumb on where.

Well of course it's not rendering, you haven't written the rendering code! Sarcasm aside, nobody is going to be able to help you without you showing what code you have written.

I don't mean to prematurely bump this, but if there's anyone who can point me in the right direction, that'd be swell.

Alright, so I added some backpacks to my mod. The backpacks are entities with items stored in NBT, which hold the inventory. When you throw the back pack from your inventory, it creates a backpack entity instead. Right clicking opens the backpack, punching gives you back the item, etc, etc. My problem is that after throwing an item into it, and moving the item, it dupes instead. Everything else is working as I need it (or so I believe). This has been solved. Sorry.

Alright, so I've utilized some of your code, Choonster, to make sure that I'm doing it right, however I still can't get it to work. Here's my GitHub: https://github.com/TrashCaster/BroadAdditionsMod/ It's a bit messy, sorry. I tried to keep it relatively clean and easy to find things. Packaging is similar to the vanilla packaging.

Unfortunately, the only way you'll be able to utilize direct calls is through means of overriding the default rendering system, which can mean conflicts. So if it really is necessary to tweak the base classes to do so, then go for it. But it's heavily discouraged by the Forge team, simply on the fact that it has a high chance of breaking when used with other mods. And actually, I've heard of people utilizing the getModel method in the item class to do direct GL calls. That's also discouraged do to the possibility to break, and may get patched. But that may be your easiest entry point for now. Good luck, and have fun.

You can use the item model system to put use your item's texture, and then have an additional layer with an animated texture with the effect you want. It's really simple. Just look up the info for resource packs. Also, IItemRenderer didnt get "replaced". It got removed. SmartItemModel was added to give flexibility to the baked model system that Mojang added. It's not a replacement though.

Just use Techne. I still use it. It doesn't work flawlessly with the code export (some things get named wrong), but if you know what you're doing, then it doesn't matter.

You won't be using manual rendering for items, from 1.8 on-wards. Item models are the future! I know, the new item rendering cuts out a ton of flexibility and cool effects that you can use through the GL pipeline. However, it can break when several mods are trying to do all these effects at once. So to keep things simple, the items use baked models, which also speed up rendering a bit. It also means that resource pack authors can change some things in the model to suit the style of their textures. It will take some getting used to for the migration. However, it is definitely worth while. Lots of headache is saved in the long run. Plus, even with the cuts to flexibility, the Forge team has worked really hard to give us as much opportunity with this new system, to side step some of the restrictions, and implement some of the flexibility we had before.

Clearly the world generator can't find that field. So go look and make sure you do have that field.

As BusyBeever said, it's a bad idea (not buggy, just bad practice) to send a compounded string as your packet. Send 3 integers in your packet. It's less payload, I believe, than to send a string. As far as closing the interface, that is also in the GuiEditSign class this.mc.displayGuiScreen((GuiScreen)null);

So I was adding fluids (trying to, anyways) to my mod, and everything was working but the rendering. I thought, am I going crazy? I looked around, every guide showed the same as my code. However, I tried one of the Forge debug examples, and of course, no dice. So basically, it seems that Forge fluid rendering in 1.8.9 is broken. Has the support been removed, or has something changed that hasn't been made publicly addressed? I assume that this works fine in 1.8 My Forge version is 1.8.9-11.15.1.1761 I figure posting my code won't do any help since the fluid stuff was the exact same as the debug examples (which aren't working either). I'll even take a work around approach, if one is available.

Take a look at GuiEditSign. They store the TileEntity as a variable, and send the position in the packet. That's a pretty common way to do it. If you want to know how everything is working, just navigate through the various functions and objects. (Ctrl + click a bit of code to view where it's from and all that)

Wouldn't it be easiest to just manually scan for the block in range when the mob tries to spawn? I can't see it being that resource intensive to do some iteration.

Are you using the SimpleNetworkWrapper to deal with your packets? If not, I recommend it. There's a thread somewhere about it. When you open the interface, you should store the tile entity position as a variable. Then when you click your button, send it back to the server through the packet. Try to do as indicated, and post back with your results. Posting your errors, and attempted code if needed.

It's obvious some of the people on here don't quite have the grasp of trigonometry. So here's a quick rundown. First off, Java's Math functions for sin, cos, and tan require Radians, not Degrees. Fortunately, there's a convenience method toRadians that you can pass your angle in degrees. Second, to use points calculated from angles, you use origins, and deltas. This is dead simple. The sin, cos, and tan functions return numbers from 1 to -1. This is a "normalized" (technically it's not normalized, but for sake of argument, that's what we're calling it) delta based on the angle. To get the radius you want, multiply the calculated result by your radius. Now it's an un-normalized. double radius = 16d; double deltaX = Math.cos(Math.toRadians(angle))*radius; // you may have to switch these two around, and play with the positivity/negativity, since I'm unsure which way is which for Minecraft's coordinate system double deltaZ = -Math.sin(Math.toRadians(angle))*radius; double finalX = player.posX + deltaX; double finalZ = player.posZ + deltaZ;

Show your renderer class. Minecraft uses the GL scale function for fixing the "upside down" of models. You rescale it as -1,-1,1 to flip it without reversing the normals.

Why don't you cancel the render player event when needed, and use your renderer in its place? So: (Pseudo-code, may or may not work exactly as written) @SubscribeEvent public void onRenderPlayerPre(RenderPlayerEvent.Pre event) { if (event.entityPlayer.getHeldItem() != null && event.entityPlayer.getHeldItem().getItem().equals(MOD.ITEM)) { event.setCancelled(true); this.customRenderer,render(/*args*/); } }