coolAlias

Have you looked at Version Checker? It's very easy to use - you just put a .json versionlist online and send a single inter-mod communication message. Or, if you really want to implement your own version checking system, Jabelar has a tutorial on that topic on his blog.

Is there some reason you must write your own file read/write code, rather than using the Config class from Forge? You can read or write anything to that file, even arrays of Strings, or you could simply get the config directory like I showed you in my last post and use that to open a file directly - you don't have to use the Forge Config class to interact with files.

It's exactly the same as before, except you can't access the tag compound directly. Use stack.getTagCompound(). I recommend you to become more familiar with your IDE - you can easily find all methods and fields available to you from any class just by looking at the class outline, or even opening up the class and viewing all of the implementations.

The proper way IS getDrops, NOT BreakEvent. You would only use BreakEvent if you wanted to modify the behavior of blocks when they are broken, not even to modify drops - there is HarvestDropsEvent specifically for that, and that is still only if you want to modify behavior of blocks that are not your own. For your own blocks, you should never need to use an event to modify anything. Do it all within your Block class.

Sure, no problem @SubscribeEvent public void onStitchTexture(TextureStitchEvent.Pre event) { // My textures are in a sub-directory of the items textures directory // but you could do the same for blocks or any other directory within your resources/.../textures location String digit = "items/digits/"; for (int i = 0; i < 9; ++i) { event.map.registerSprite(new ResourceLocation(ModInfo.ID, digit + i)); } } // Then to retrieve the texture for "0": String location = ModInfo.ID + ":items/digits/0"; TextureAtlasSprite sprite = Minecraft.getMinecraft().getTextureMapBlocks().getAtlasSprite(location);

Easiest way to get the configuration file is from FMLPreInitializationEvent: @Mod.EventHandler public void preInit(FMLPreInitializationEvent event) { Config config = new Configuration(new File(event.getModConfigurationDirectory().getAbsolutePath() + "additional/path/to/your/config.cfg")); } I just put my "modid/modid.cfg" as the additional path.

I ended up ignoring the layers altogether and going with TGG's wonderfully magical method. Only step I had to take was to subscribe to TextureStitchEvent.Pre and make sure my digit textures got added to the sprite sheet, then return a new model for the GUI view with the number of bombs held set during handleItemState. I was kind of lazy before and actually made 30 textures for the digits, one for each 0-9 for each of three place values, where the digit was offset internally within the texture. It was trivial using TGG's method to cut that down to one texture per digit and simply offset it by an amount based on its place, and now I can even trim the texture sizes down from 16x16 to their actual size (5x7). EDIT: Actually, Minecraft won't let me trim the textures down, complaining about a 'broken aspect ratio' <sigh>. Doesn't matter, though, as I still cut out 20 redundant textures.

You're right, and I had seen that there in ItemModelMesher before, but totally forgot about it. My problem is just that the default model is not the one I want to render in the world and IPerspectiveAwareModel#handlePerspective is not called for EntityItems, which is slightly unfortunate. Still, changing which model I use for the default is pretty simple, though I will lose out on the changes I'd like to make based on perspective. Speaking of which, why isn't there an EntityItem camera transform anymore? Or is that 'NONE' ?

RenderEntityItem uses the model retrieved from ItemModelMesher#getModel(ItemStack), but, unlike all of the other points of rendering items / blocks, does not check if the model is an ISmartItemModel, IPerspectiveAwareModel, or anything else of that nature (there is no longer even an ENTITY camera transform...). Currently, the only way I can think of to render my item's custom smart model while in Entity form is to actually create a custom EntityItem and register a different render class for it. I can do that, but the entity itself doesn't actually need to do anything special, and the renderer would just be making calls to my smart item model, so it seems kind of like overkill. Does anyone happen to know if there are plans amongst the Forge team to correct this, or is there already a solution that I am just overlooking?

It helps if you have correct parameter names, rather than non-meaningful things like par1 and par3: getItemDropped(int meta, Random random, int fortune)

I ran into a similar problem checking for interfaces; you can get around it by writing your own method to search for entities and use that when you expect the vanilla method will fail. You can see the method I wrote to do so in the above link.

Thanks, Ernio. I'll give that a shot later on and reply back with my results.

I was using the TileEntityRenderingDispatcher previously (as you can see in the first post), which worked fine for the block in the world and, after I made an ISmartItemModel, for the first and 3rd-person views as well. I never did manage to get it working for the inventory view, however, though I didn't play around with it too much before switching to using an actual .json model for my block, as opposed to trying to hitchhike on vanilla's code. Using the .json is much cleaner anyway, as now I don't need any TESR or custom item model, and it looks just like it should, lock and all.

Well, I was able to work around it by creating an actual .json model for the block and using that as the base for the item. The TileEntity and non-inventory views both use the TileEntitySpecialRenderer to render the vanilla ModelChest with my own texture, and the inventory view uses the block model from the .json which has the correct textures. I left off the lock model for the time being to see if it would work, but now that I see it does, why would Mojang hard-code the chest item rendering like they did rather than using the .json format? They could still use the TESR to render the animation and combined chests as needed... strange. Still, I wonder whether/how one can use the TileEntityRendererDispatcher to render in the inventory view, like vanilla does in TileEntityItemStackRenderer (at least I think that's where it's done for the inventory / hand-held views)?

This is what I am trying to accomplish: As you can see, the digits only show in the inventory view, which is what I want. I accomplish this by using a combination of .json item layers and an IPerspectiveAwareModel. Relevant .json / code: That all works fine. My question is: how can I do this without having to create one .json model for every single possible number of items held, i.e. 00-99 ? I've looked at the various options available, and from what I can see none of them are aware of which layer is being rendered at any given point; if I had access to the current layer (and probably also the current camera transform), I could use that to directly render the digits during the second / third render pass, and leave the first pass as is. Is direct manipulation of the BakedQuads (as shown in TGG's chessboard item tutorial) the only way to do this? If I do it that way, should I still register each of the digit textures, or is it fine to use them directly?

First of all, you should understand that GUIs and such are CLIENT side, and that you should never try to change something, such as a player's inventory, on the client side. So you will need to send a packet when your button is clicked with information about which item the player was asking for, and when the server receives this packet, you can decide if the player is allowed to be given the item. To add an item to a player's inventory, you can use player.inventory.addItemStackToInventory(ItemStack).

You can make a class that acts as the basis for most of your other Item classes, but if by 'universal' you mean only one class for all of your Items, then no, you can't, unless all of your items are boring and don't do anything. You need different classes for different types of behavior. A sword, for example, should extend the vanilla ItemSword class, but a cookie would not make any sense to use that same class.

Both that code and this thread are for 1.7.10, in which the network was still on the main thread. @TheRealMcrafter - if you're going to verbatim copy / paste code from a tutorial (you didn't even remove my comments!), it's considerate of you to write a note in the code saying where you got it from, i.e. giving credit where credit is due.

I did: vanilla sprinting adds an AttributeModifier to the player's movementSpeed SharedMonsterAttribute, and then removes that same modifier when no longer sprinting. Everything needed to use AttributeModifiers can be seen by looking at the vanilla sprinting code, but in a nutshell: 1. You need a UUID for your modifier so you can remove it when necessary; I use http://createguid.com/ to get a UUID string, then UUID.fromString to get the actual UUID and store it in a static final instance. 2. You will also want to create a static final instance of your AttributeModifier, even if the internal value will change, simply so you can reference it when removing it. 3. When you determine the modifier should be applied: a. Get the IAttributeInstance of the appropriate SharedMonsterAttribute for the entity in question b. Remove any previous modifier: if (attribute.getModifier(uuid) != null) { attribute.removeModifier(yourAttributeModifierInstance); } c. Then apply the modifier, either the statically referenced one, or a new one with the same UUID attribute.applyModifier(yourAttributeModifierInstance); You can find information about the final constructor parameter on the Minecraft wiki in the Attributes section; it determines how the 2nd to last parameter (the value) is applied, e.g. simple addition (0), multiplier to the base value (1), etc.

@Thornack, you fix it by applying an AttributeModifier rather than setting the attribute's base value. Just like sprinting does. You should only ever set the base value when an entity is constructing - any modifiers to that value, whether temporary or permanent, should be AttributeModifiers.

You don't want a vector, though, you want world coordinates: add the vector coordinates to the player's position, not the player's position to the vector: Vec3 look = player.getLookVec(); float distance = 1.5F; double dx = player.posX + (look.xCoord * distance); double dy = player.posY + player.getEyeHeight(); // notice I'm not using the vector here: if the player is looking straight down, the item would end up in the ground double dz = player.posZ + (look.zCoord * distance); // now spawn your entity with (dx, dy, dz) as its position

Yes, I know about IPerspectiveAwareModel, but I figure the more my model can use the vanilla system (i.e. .json files), the better. I mean, why do all the rotations manually when they can be included in the .json file? If you hard-code the rotations, it would be very difficult for someone to make a resource pack for your mod. And what do you mean getGeneralQuads() is/isn't mutable? It's a method: methods can neither be mutable nor immutable. I haven't delved too deeply into model registration; are you saying that once a model is registered, getGeneralQuads() is never called again?

AttributeModifiers would be the preferred method, in my opinion. Attributes such as player movement speed are automatically synchronized to the client in the background, so you don't need to worry about packets so long as you add/remove the modifier on the server. If you want it based on armor that the player is wearing, you cannot really do it in ItemArmor#onArmorTick because you will be unable to remove the modifier (i.e. onArmorTick is only called if the armor is worn, not when it is taken off). The only way I've found to do this is to store the last armor worn in IExtendedEntityProperties for the player, then each player tick (use PlayerTickEvent), I check if the armor has changed. Whenever it changes, you need to both remove your speed modifier and, if the player is wearing the correct armor, apply it.

Yes, you have to send a packet. You ALWAYS need to send a packet when you are performing actions on the client that need to impact the world in some way, including which item will be consumed, etc. Never set a value on the client that has a correlating value on the server; instead, tell the server what the player wants to do, then let the server decide the value and inform the client player what that value is. E.g.: 1. Player wants to change ammo, presses 'R' 2. Key handler sends packet to server saying 'Player A pressed the change ammo key, now what?' 3. Server receives packet, determines player A's next ammo type 4. Server sends packet back to player A on the client side, saying 'Your new ammo type is X' That's how your program flow should go, always, for things like this. As for tutorials / explanations, did you try Google? There is a tutorial by diesieben07 right here in this forum in the Tutorials section, and I have one over on MCF that does things somewhat differently, but I have improved upon it quite a lot since I wrote that tutorial and haven't gotten around to updating it.

Isn't the type of ammo the player is using based on what they have in their inventory? Or are they selecting it from somewhere? If the latter, that would make sense to store it like you have. I had a look at your main class' registerEntity method, and there are a few things wrong with it: 1. Don't register your entity with a global entity ID - that is for vanilla only 2. If you don't need a spawn egg, there is even more reason not to use global entity ID, as that is its only benefit (well, and the /summon command) 3. Tracking update frequency and range values should be set based on the type of entity you are registering, not as a blanket value for all of them. Furthermore, NO vanilla entity uses an update frequency of 1, and you should not either. Always choose values closest to the most closely related vanilla entity you can find. You can find tracking values in EntityTracker, or online here, though I don't know when it was last updated. Generally, projectiles (except for arrows, for some reason) use (64, 10) and mobs / animals use (80, 3).