Ernio

Thorny, seriously? #doRender is called everytime, on beginning of rendering of given entity. It doesn't matter what you did before, it matters what you do inside. You have entity parameter inside, you can use it to e.g entity.getModelName() which would e.g return String which you could then use in HashMap.get(StringYouGot) -> and return some model. Then you simply do this.model = modelYouGot. All that in doRender, Map of models should be kept as static field initialized on mod startup. Bam, your models are per-entity, same can be done for textures or whatever, Just keep in mind that you have to do proper casting.

I don't think you (OP) know what an API is and how it should be made. Best way would be: Make your mod's API and build your mod onto it (well, that's basically what you should do). Place all data-holders inside API's classes, make everything private, create getters and setters ("adders"). Export your API as ready to use (one for developers (not obf), one for use - obfuscated). Import .jar of dev API into your libs. Inside your mod you can now use that .jar's methods for getting and adding new recipes. Your MainMod will need to be dependent to this API and when looking for "recipes" - ask the API about them. Developers (other) will simply get API and add their stuff. And wtf with that reflection? Whole point of APIs is to not have one. Note: Yes, we are talking about 2 mods, and yes - you can export them in one JAR.

Yeah, why not? You can (anyone can) check if some mod is running and add stuff accordingly. Do tell - what exacly are you doing? Are you: - making it possible for other people to add recipes to your mod? - making dependency that if some other mod is running, then add some recipes that will use other mod's e.g items? - making dependency that if other mod is running, then your mod will add recipes to other mod's "machine"?

The author himself is stating that those are only things you can send. An object is nothing else but a 'wrapper' for other values and references. So no, you can't "send" Object. You need to encode (split into parts) it and decode it (put toghether from parts). There are ways to do it, but that will not be anythig close to efficient and will not have anything to do with InterModComms. Personal opinion: Don't use InterModComms, you may aswell setup optional dependency or make API (idk what exacly you are planning). There is no point in encoding and decoding data when you are in the same JVM process. Btw. - if you are just sending this (what you told), you are probably doing it once - during recipe registration? If something is NOT used very extensively (per tick, per entity, etc) then you don't optimize it, no point. Disclaimer - I don't use IMC, so above is not opinion of professional IMC user, but a modder.

I will start with this: "Please, go learn basics of Java." Nothing will help you if you can't even override methods. You need to override vanilla Item.class's method: public boolean onEntitySwing(EntityLivingBase entityLiving, ItemStack stack) { return false; } You will want to grab 'entityLiving', check if its player (instanceof/cast), then get current held item (the stack) and set it different, new one. playerIn.inventory.currentItem

Drawing strings (FontRenderer) is nothing else but a tesselator that grabs a symbol on some coordinates in symbols map and draws it in sequence. After using FontRenderer your bound texture is set to using this symbol map, you need to come back to default (icons). How: At the very end of your own rendering do: mc.getTextureManager().bindTexture(Gui.icons); Gui.icons is minecraft field (public static final ResourceLocation icons = new ResourceLocation("textures/gui/icons.png"). Note that OverlayEvent has many rendering phases (each for every overlay part) - use rebinding not in all phases but jsut after you do something in one of them. P.S: And yes, I made mistake, not widgets, but icons.

#Selfishness #Safety #IWanna ...I mean, those were the reasons I was doing it (2 separate mods for my server and clients). This is probably only reason that could almost justify those actions. Or maybe hiding mod's internals - good reason too. There are people here who would hate you for being selfish and "hiding" code, but nah Note: If reasons are different than mentioned - you simply DON'T split your mod, bad thing.

Lots of mess in code. Your problem sounds like you are not rebinding texture. After using FontRenderer in OverlayEvent you need to rebing WIDGETS. They are in Gui I think (or somewhere). Note: Might not be it.

I am on 1.8 so no help here, BUT - notice that blocks like Workbench only 'work' when you are not sneaking. (sneaking makes you place blocks). Use reverse-tactic (look vanilla). Also - if you don't want to use player.isSneaking (or whatever the field's name is)and need that value on server, you will need to make IExtendedEntityProperties and store when the button is pressed and when not (send packet from client to server - on click "true" on unclick "false").

Well, this shit turned out to be more challenging (and fun) than I expected. After a while (days) I decided to redesign system and actually simplify process to rendering item from few models. Basically: combinedQuadsList.addAll(iBakedModel.getGeneralQuads()); Now, the problem is that item to be rendered from few other models is like super-parent to them, meaning that the offset and thickness for partial models is derived from those defined in the item-to-be-rendered model file (json). Explanation: Okay, so while it is NOT that bad (considering that I alredy rewrote everything I had), I'd like to manipulate those BakedQuads a bit. For example to make guard thicker than hilt and blade (obviously). Problems: 1. I have no clue (can't track down code) where the json transformation happens. - On the one end it seems like models are generated on startup, BUT when I look at it - that would mean that if'd put together BakedQuads of few different models the transformations would stay and they don't. So I think - the transformations for given .json MUST be stored somewhere, BUT WHERE? I am planning to get them (for specific part) and apply (partially) on the BakedQuads I'll be adding to the to-render-model. (ofc. caching stuff) 2. How to manipulate vertexes? (tuts, explanation) Useful info is around FaceBakery#storeVertexData. Now I'd like to know what is what (I meam, I can read names of vars but I don't quite get which represents what). Plan is "simple": - get all "front" and "back" quads and move them a bit "forward" (thicken model) - get all rest (the "vertical" ones) and expand them to fit thickening. - cache ready-to-use list of BakedQuads and use it for rest of renders. While it might be an overkill, I feel safer doing this than making models on my own. 3. In RenderItem: private void renderModel(IBakedModel model, int color, ItemStack stack) { Tessellator tessellator = Tessellator.getInstance(); WorldRenderer worldrenderer = tessellator.getWorldRenderer(); worldrenderer.startDrawingQuads(); worldrenderer.setVertexFormat(DefaultVertexFormats.ITEM); EnumFacing[] aenumfacing = EnumFacing.values(); int j = aenumfacing.length; for (int k = 0; k < j; ++k) { EnumFacing enumfacing = aenumfacing[k]; this.renderQuads(worldrenderer, model.getFaceQuads(enumfacing), color, stack); } this.renderQuads(worldrenderer, model.getGeneralQuads(), color, stack); tessellator.draw(); } Question: Difference between general and face quads. I mean, names are pretty self-exp, but while: combinedQuadsList.addAll(iBakedModel.getGeneralQuads()); ...adds everything to model, the iteration over all faces and quads with 'model.getFaceQuads(enumfacing)' adds nothing. (Shouldn't those lists be the 'parent' and 'children'?) Damn, it's a lot Thanks for any help

I will not say this is good idea, but unless you want to re-setup whole gradle and eclipse (which I don't know how to do), you could go like this: Make 3 packages, common, server, client, create a GOOD proxy that will point into right packages and never ever reference server in client and vice versa. After compiling you can simply remove whole server part, the mod WILL run and will not crash, yet - this is again - very bad thing to do. Actually you might even start using SideOnly to know for sure if the mod will run outside dev.

Bukkit is a relict of the past. Forge is the only future. Our only salvation. Those who oppose shall be purged by the holy fire of Blazes' spirits. All hail Minecraft Forge!

Recipes accept different (look constructors) kinds of input. One of them is ItemStack which allows you to define metadata (item damage). https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe35_recipes/StartupCommon.java

As to caching I will probably create model map (String+String+String = key, model = value). As to generating - pretty much what I was afraid to do (make cubes on my own). Thanks for class-references, gonna look there. One question tho: When MC bakes models it doesnt care about resolution, you said I should draw 16x16 cubes, so if I'd want resolution support do I actually have to generate e.g 256x256 (shitload of cubes)? Was trying to find (in MC) where exacly that happens (reading pixels and making cubes) - do you know by any chance? I did like 30+ callbacks and shit is leading nowhere, probably got lost ;_; Thanks for all help (Btw. I actually managed to render sword from 3 other models, that is easy, but generating it whole different level).

Well, I must say I don't know next shit about what am I supposed to be doing. Could you maybe walk me through how those things even work? (not Tess, that I know how to do). 1. How to put ResourceLocation into TextureMap, when and with what (I know there is some event regarding stitching). 2. Inside My ISmartItemModel I have ready-to-use ArrayList<ResourceLocation> that points (in order) on textures that should be rendered. - What now? I assume I have to: TextureAtlasSprite one = Minecraft.getMinecraft().getTextureMapBlocks().getAtlasSprite("roa:items/firstTextureFromMyList"); TextureAtlasSprite two = Minecraft.getMinecraft().getTextureMapBlocks().getAtlasSprite("roa:items/secondTextureFromMyList"); TextureAtlasSprite three = Minecraft.getMinecraft().getTextureMapBlocks().getAtlasSprite("roa:items/thirdTextureFromMyList"); And somehow put them together. You said that I need to have model for each weapon part. The whole point was to NOT have model. I want to generate model in runtime. 1. Get 3 textures 2. Put them together 3. Stretch thickness 4. Return created new model 5. Render Hulp me doctor, it hurtz. Thanks.

I alredy some experiments, but I have to ask: What do you mean by above? Particulary: "you will need to load in all the textures in advance" - My textures (like one shown in op post) are loaded on startup (are simply all inside assets). E.g.: "weaponpart_shortsword_blade_demonic.png" Whole "weaponpart_shortsword_blade_" is derived from Class, only "demonic" is read from NBT. "If you add an item with a new NBT later, you will need to refresh/restitch the texture sheet" I mean, there will be like hundreds of different guards and blades. What exacly are we talking about here? Isn't .png being in assets folder enough? I have to manually add it in code?

This is not how you do it. ServerTick is for whole server. Whole server can have more than one world. Use WorldTickEvent for server side. For client - yes, you have to use ClientTickEvent or PlayerTickEvent (which is called on both sides for all players). If we are talking armours - use PlayerTick.

I know that there are at least few people here who dealt with this thing. *Looks at TGG* Now, I've alredy looked (read code/notes) at all MCByExample Item tutorials and I am "still" wondering if what I am doing it supported and how should I archieve it. Examples are best: Let's say player wants to make Longsword. Player crafts 3 items: Hilt, Guard, Blade. Those items can be crafted from like literally anything, they have their factors and most importantly (in this case) - texture key. Putting together those 3 items in next crafting process creates custom sword - that holds 3 texture keys. In order: Hilt, Guard, Blade Partial textures are alredy offset to not deal with translations. Hilt and Blade should be placed 1st, then on top of them (overlap) there should be "connecting" Guard (to not leve glitches where e.g blade is rendered on top of Guard). System was designed and was working on 1.7.10 with IItemRenderer, which was like the best thing that has ever happened to "smart" rendering, ever. *Looks at ISmartItemModel with hesitancy* Now - how would I get that working in 1.8? Goals: - Put Guard on top of Hilt and Blade (with no texture overlapping glitching) - Allow any .png input (read from stacks's NBT) - texture keys look like this: String key = nbt.getString("K") Then: MODID + ":items/" + key System know which one is which (e.g Hilt/Guard/Blade). - Texture-resolution-compatible, so that it works with x16, x32, x64, etc. Note: I am not talking about that Guard would be 16x16, and Blade 64x64, no need for that, all parts are always same-resolution. Additional: In 1.7.10 I also made "bigger" weapon rendering (so that your item is rendered twice the size), so 32x32 texture looked like 16x16 resolution after rendering (item was twice size in-game). Is it possible in 1.8 and how would I approach it? I am seriously thinking about reimplementing IItemRenderer on my own, just to not deal with all those models... Well, that's it, any hints - appreciated Thanks

Item (as class) has only one instance (or rather that many as you register into Game). The Item is a definition of what you are holding, the ItemStack is the thing that actually holds data. You cannot assign ANY data to Item that you don't want to be global. To save data per-item you need to use ItemStack's NBT. You can do that straight from yourItem class. No point in explaining further. www.minecraftforge.net/wiki/Creating_NBT_for_items Post code if you can't figure out why it doesn't work. (note: NBT is null on default). EDIT Why am I not getting notifications that someone wrote before me? :C

Build 1.8-11.14.1.1354: ohai.iChun: Readded but deprecated the old RenderPlayerEvent that were deleted. Sorry, Lex. Build 1.8-11.14.1.1353: ohai.iChun: Reimplement RenderPlayerEvent that was removed in the port to 1.8 from 1.7.10. RenderPlayerEvent.Specials was removed because the special effects are done in the LayerRenderer now. Is it possible that you are outdated? Also - I hope you are registering event in client proxy. Extend RenderPlayer and alter anything you want, Model, whatever. DO NOT make "new" every frame, declare static firld for your extending class. EDIT And btw. you HAVE TO use x/y/z from event, not zeros.

Yes, ideed, that's what I wrote before: What I ment by damaging is the fact that while Player's AttackEntityEvent happens on PLAYER himself, the LivingAttackEvent happens on entity HIT. That's what I "don't like" about it. For AttackEntityEvent you can cancel everything, calculate on your own and perform: targetEntity.attackEntityFrom(DamageSource.causePlayerDamage(this), DAMAGE); For LivingAttackEvent you have the ENTITY that was HIT by something and the DamageSource/Damage of that HIT. Problem here is that in this case I have to get Source, check it and only then HOPEFULLY get the attacker entity. Then only after I got attacker, I can start calculating like I do in AttackEntityEvent. Main problem here are a lot more checks, and most of all - problem of attacker. "Problem of attacker" is fact that attacker's Object MIGHT dissappear while attack is being performed, thus if that happens i am unable to calculate ANYTHING (I have no attacker's stats) and I have to totally cancel event to avoid NullPointers. This is REALLY critical case, but CAN happen. And I like to know there is no possible way of breaking code.

new RenderPlayer(manager).doRender(event.entity, 0d, 0d, 0d, 0f, 0f); Don't do this ;_; (new every frame) There is RenderPlayerEvent - use that one.

If you can't do it, it's most likely lack of Java experience, in which case i suggest learning and not give up Even if you can't Java good - just by googling it you would be able to get it working, I told you what to look for. If you are not planning to use that info: Know this: - Potion effects should be added server-side. @Override public void onUpdate(ItemStack stack, World world, Entity entity, int par4, boolean par5){ super.onUpdate(stack, world, entity, par4, par5); if (!world.isRemote) // This will run on server { EntityPlayer player = (EntityPlayer) entity; ItemStack equipped = player.getCurrentEquippedItem(); if(equipped == stack){ player.addPotionEffect(new PotionEffect(Potion.regeneration.getId(), 60, 2)); } } } - Applying potion effect every tick is NOT BAD. Vanilla handles it on it's own, so as long as you want to keep potion effect all the time when item is held, you can leave code as it is. - Setting potion duration to 1 will cause glitches, always use 2+ values (this has to do with update of effects, that might occur before or after you added the potion, thus - effect can act weird). No, I told you all possible proper ways, anything out of this (3 ways) is probably weird or same thing wrapped in different code (or is it?)

Two ways: 1. Per-item solution: - Use ItemStack's NBT to store how many ticks ago buff was added. - +1 with every check. - If value reaches 60, add buff. Flaws: Vanilla is retarded and can't handle ItemStacks' NBT changes like normal human being would, and "recreates" ItemStack with every NBT change, instead of just changing value - which, in many cases, is stupid. Opinion: Don't do this, too easy, too cheesy. 2. Per-entity solution - Use IExtendedEntityProperties to store integer (ticks elapsed) and utilize Tick event to ++ it. - Same as in 1. when tick reaches 60, do update (add effect). Pros: Good and efficient, proper thing to do. How-to: Decide if effect should be for all entities or only players, pick LivingUpdateEvent or PlayerTickEvent. Create class that implements IExtendedEntityProperties and save your value. Use that value in previously created event. How to use events: google has like million examples/tuts. How to IEEP: Working, long: http://www.minecraftforum.net/forums/mapping-and-modding/mapping-and-modding-tutorials/1571567-1-7-2-1-6-4-eventhandler-and Short: It's quite easy, look at code EDIT 3. There is also other per-item solution that includes saving timestamp the moment when buff was last added, then instead of incrementing tick-count in NBT every tick, you simply check timestamp and see if 60 ticks passed - if so - save new timestamp and re-apply. For timestamp you can sue currentWorldTime. Flaws: Timestamps are not always cool to work with. Pros: Better than 1; still worse than 2.

Best part - you can't (in clean code). When you have problems like this one you should think about your design. The easiest (fast) to code would be making protected void addAttribsAfter() which would have all your attribute-adding from Pet's side and would be called at end of Cat's constructor. Above is, in my eyes, like the worst possible design, literally saying "I don't give a damn about inheritance", but it will work.