Ernio

Please - learn Java before modding. 1. Constructor can't be protected - make it public to be able to use it outside inheriting classes. 2. Constructor takes Material as argument, you can't construct it without it. Material.class (lookup vanilla).

I know "ways", I am just looking to implement best way (without using useless tagKeys). Instead of: {List:[0:{Thingy:"String",},1:{Thingy:"String",},2:{Thingy:"String",},],} There will be: (obviously not realistic example) {List:[lenght, String, String, String,],} Btw. if anyone is interested why - when ItemStack has tons of strings in it and is used VERY often (super common item, there is more of it than e.g iron ingots) it actually matters if you are sending almost half the data less.

Looking at it from outside - seems easy - just extend NBTBase and make your read/write streams. Looking at the inside - NBT types are hard-coded and even worse - are actually used in few places. protected static NBTBase createNewByType(byte id) What I want to ask - how would I approach making such array? I was thinking about overriding "createNewByType" + using #writeUTF8StringToBuffer (or something like that, forgot name). Will that work? Maybe someone has such thing in utility? (on my way to check out SevenCommons).

https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample MBE14 and MBE15 Without GOOD knowledge of Java and minecraft model system itself it will take some time till you can do good with it. Even if you are good - this thing will take hours of testing to learn. (as always - look vanilla implementation). + Learn tesselator.

* I am not your dude, bro. - I am not your bro, man. * I am not your man, m8. - I am not your m8, guy. * I am not your guy, homie. - I am not your homie, buddy. * I am not your buddy, comrade. - I am not your comrade... <ran out of words> Anyway. You are missing the point. When extending RenderLiving you need to provide EntityLiving for it to render. EntityThrowable is NOT EntityLiving - it's just Entity. It will AT LEAST crash on casting. Not to mention probably other problems (nulls etc). Do not use RenderLiving. Use Render (extend it) - look at vanilla - it's best teacher (how do you think snowballs are rendered?)

Everything clear as always, thanks man, saved me at least 2 hours. As to Unlocalized name - I just messed up naming. That's what I ment (registry identifier). Basically, if I'd remove something - until I load world for the first time after removal, I can easily register totally other thing to same (old) identifier and it will work (old will become new one, assuming there won't be loading - read NBT error). And if I'd load it at least once, the world will forget about identifier and only leave locked id behind it - which will cause all old stuff to be removed and if I'd put other item with same name identifier - it will still get a new ID (forge won't remember it). If that is right then I am so damn happy. (I have to be reassured because i will be implementing something that simply can't have any issues with its removal in future). Muchas Gracias

Writing adventure mods requires you to make load of quest items, which MIGHT be unobtainable in future (deprecated) or even removed from game code. While deprecation case doesn't really matter (since item is still in game), there is problem with stuff that is removed from game code. Forge has its system that (I am assuming from observation, not code itself) when world is created creates "dictionary" which matches unlocalized name (short: UN) of item with its world-unique-internal-ID. Then all items of this UN are saved in world as those ids. This is true, right? For some time now - forge has detection of items that were not found in game code (were not registered in gameRegistry). I am sure everyone saw on-world-load GuiScreen that says that world couldn't assign item to loaded world-saved item. Questions: * When item is totally removed from registry - what happens to: - Forge's UN-to-ID "dictionary"? Does the UN stay and points at null thing or is it also removed? - What happens to world-saved things that cannot find its registy-matches? I know for sure that items and blocks simply disappear - my guess is that if loaded item/block points at nothing it's set to null/0 and removed from loaded-NBT (from world save). Are they removed from disk or just bypassed and left? - What would happen if I'd remove item from game and after some time re-added other item with same UN (unloc name)? How will forge deal with it? EDIT: - What about TileEntities, when their block gets removed - are they not-loaded and if not - is their data lost or just bypassed by world-loading code? - What about removing TE and leaving Block? Same cleanup disk-data questions apply. Basically - if someone knows how forge deals with world-data cleaning up, I'd be glad to hear anything. Also - I have no idea where to look for the code responsible - right now I am literally searching for stuff like "save" "load" keywords, but there is so damn much callbacks Thanks

If you would actually learn Java and know what are you doing you wouldn't be having problems like that. Throwable is an Entity, not EntityLiving, you can't apply RenderLiving to it. Aside from that - making texture won't make renderer render it in 3D - you need to learn at least tesselator to do that, or GL to actually make something good looking (real 3d stuff).

GuiContainer actually uses initGui() in its class. When you are using it you need to call super.initGui() (first thing you do). EDIT Also - you shouldn't have to have any globals in YourGuiContainer - everything is alredy provided from GuiContainer. Seriously - everything. @SideOnly(Side.CLIENT) public class MyGui extends GuiContainer { public MyGui(TileEntity te, EntityPlayer player) { super(new MyContainer(te, player)); this.xSize = 164; // set those in constructor - those should be literally width and lenght of your gui.png which will be the background. this.ySize = 233; } } Then you have those: protected int guiLeft; protected int guiTop; Those two are literally "the top border and the left border" of your gui.png (you need to set x and y Size in constructor). What MC will do is in initGui() it will take those xSize and ySize and set guiLeft and guiTop to right values.

MC will only bake default models. If "empty" is something that is NEVER registered, it's not baked (in preInit) - thus you cannot assign it to anything (in init). If I'd have to debug it you would need to post your proxies, all json files and block/item initialization. Post src on Git - you will get direct help much faster. Seriously man - just go to MCByExample - EVERYTHING is there if you follow it VERY thorough. There is nothing left to say.

When minecraft starts, in preInit() you need to tell it to load all model files. If there is one item or one block - it will do it automatically. When block or item has variants - you need to tell it that "hey, also load this model.json". Then in init() you need to tell MC to assign registered and baked models to item and itemMeta. Why it does work: You are using same texture (same model) for both metadata variants of item. This model is registered. What you do is only assign model to its meta item. When it will stop working: if you make 2 models for 2 different meta, only one will work or neither if variant changes unlocalized name of item (which is possible). EDIT Fixed lot of typos (I just woke up).

Post block.class + proxy where you register items. Does your item exist in game?

Also: Did you do ModelBakery.addVariantName(...) in your ClientProxy#preInit()? https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe03_block_variants Everything is here.

I don't know why, but since I posted here: http://www.minecraftforge.net/forum/index.php/topic,29227.0.html Everyone has been mad about RenderPlayerAPI. I mean - I see it everywhere right now. EVERYWHERE. That is not a bad thing, just know for fact that RPA is powerful tool and if you are not planning on using it extensively, stay with the forge. There is a reason for those hooks in forge. More dependencies = worse.

Nope and nope. drawTexturedModalRect always takes 256x256 (resized with resolution, so e.g 512 or 1024) image as Resource. You need to make your button image be insie 256x256 palette and then choose coordinates for it to draw. EDIT Note - there is also method +"withCustomSize" or something like that. That one allows you to have custom sized png.

If you are actually trying to cast light from player (like a torch does), then there are only 2 ways to do it (not counting stupid try-hards). Either write core mod that will change lighting system - lookup atomicstryker's DynamicLights. Or update block light around source every tick. This is btw the stupidest idea anyone could come up with - it will cause massive lag. Good solution only for hype-PC and super-servers. If you want to know exacly how to write it - GOOGLE or better - use this forum's search engine. There was a thread about month ago (maybe more). Unless you wanted different thing?

Frge for 1.7.10 has wavefront model support. There is loader in some client packages. Obviously you need to just load model and render it - there are hooks to do it. Then you will use RenderPlayerEvent (most likely) to grab model and render it usig GL. And yes - you need to actually learn how to use GL in this case, it's not going to come on its own :C

Sounds like your env was badly set up (not deobf). Follow the tutorial: http://www.minecraftforge.net/forum/index.php/topic,14048.0.html

event.drops.add(new ItemStack(Item.getItemFromBlock(Blocks.stone), 1, 1)); // 3rd is meta Don't make this harder than it should be. I don't get why people go with states - numbers are as nice as they get. If you really want to extract meta its .getMetaFromState (other way around).

Look inside BakedQuad maybe? int[28] vertexData.

Note that there are 2 pickup events. One FMLs, other Forges. FML: ItemPickupEvent Forge: EntityItemPickupEvent Forge (fired 1st) allows you to intercept picking up item entity. In that manner - when you pick it up (collide with entity and won't cancel picking up), you can't do entityItem.getEntityItem() because the ItemStack will be alredy transfered into your inventory (the ItemStack inside entitItem will move its properties to your inventory). FMLs one is fired on ItemStack that was transferred to your inventory and after actually picking up. Allows you to manipulate stack. EDIT Learn to use events (all over google). Then simply use them like event.pickedUp.getEntityItem().getItem() == YourItem -> give archivement. Remember to check for nulls (hardly possible during picking up, but better to do that).

Me: Let's give my item 100 uses with nice 100/100 (percentage-like display). What do you say Vanilla? Vanilla: Ye, sure bro, why not! This is the kind of shit I have to go through. Why?!

This is like really simple math, but it's still bothering me (and I need some sleep). Is it just me or setting items max durability to X given you X+1 uses? I mean - looking at sword - for iron it has 250 "uses" written in material enum. Items start with 0. Each hit gives +1 till it reaches 250. Items DON'T break at >= but on >, so basically after 250 uses there is still one to go. On in-game display 0 is 250/250, while 250 is 0/250. Now - I am not dumb, but the logic here seems awfully annoying. It's like someone couldn't decide if to go with > and +1 or >= and just wrote something. maxUses = 250 is actually 251. Should this be considered as bug (bad design?)?

net.minecraft.entity.passive.EntityHorse

I'll just say - if you think you wrote something well and it's not working - the problem is NOT THERE. Please - full code. What is you entity? Are you sure you are grabbing right one? DId you register (created) particle? (EDIT: Its vanilla particle, isn't it?) Are they working elsewhere? Have you tried SIMPLE debugging (printing x/y/z for one)?