coolAlias

Or you can heal the entity for 1 hp or something before returning from the cancelled death event. As you said, though, the effect is similar either way.

world.isRemote returns true on the client side. Keyboard and all other input is also client-side only code, and will definitely crash you on a server when used like that. Anyway, you should open the gui on the server and give it both a server- and client-side element. See this tutorial.

The problem is that getModel can only return ONE model. I want to render two models - the bow, in whatever pulling state it is at (this part is already working), and the arrow that is nocked in the bow, based on whatever current arrow is selected. I'd prefer not to have to store a bunch of extra data in the NBT tag. I have done that before and it causes animation glitches any time it updates. I guess I only really care about player's using the bow, in which case I can try using mc.thePlayer, but I suspect that will not work well in multiplayer because the renderer is called client-side, so whenever someone is looking at an entity using the bow, it will use the viewer's data rather than the actual entity being rendered. With the current placement of ISmartItemModel's hook (@ItemModelMesher#getModel(ItemStack)), it's not possible to obtain the entity. I wonder why it wasn't also placed in RenderItem#renderItemModelForEntity which is where the lovely Item#getModel method is called? Or, rather, had an additional hook there, since ItemModelMesher is called from so many different places.

Right, but where in that equation do I get the entity using the item?

That's what I thought, but I saw it was still in the Forge code and, it being there, assumed it would still work. That's what deprecation means - still works, but being phased out or not as preferred as some other method. It doesn't mean 'we left this artifact here for you to gaze upon, but it has no use.' If it is not going to be implemented at all, it should be removed entirely so people do not think it still exists. That aside, I've looked at IPerspectiveAwareModel, but I also need the ItemStack and the entity using the item to determine which model / transformation to return - IPAM only gives the camera transform type. What I'm trying to do is render the currently selected arrow along with the bow currently in use. This was trivial to accomplish with IItemRenderer (much like many other things in the past... oh, nostalgia), but I cannot seem to find anything that provides that same level of flexibility in the new format. I actually am coming to quite like the new systems, especially IBlockState, and even using JSON for models to some extent, but there I've run into several cases already where the model system seems very limiting. I'm sure it's just because I don't completely understand some part(s) of the process, but it has been the one thing about updating to 1.8 that has caused me the most grief.

IItemRenderer is deprecated in 1.8, but has not been entirely removed. Since this is the case, I would expect it to still be usable, but after trying it I found that my custom renderer is never called. Opening up the call hierarchy for any method in MinecraftForgeClient reveals that none of them are ever called (except by me to register my IItemRenderer). Is this an oversight, or should IItemRenderer, MinecraftForgeClient, and related classes (if any) be removed from the Forge code base? If they will be removed, what is the alternative to IItemRenderer that gives access to the entity for which the item is being rendered as well as the current camera transform? ISmartItemModel#handleItemState gives only the ItemStack, which is not sufficient for my needs.

The only way to do this that I know of is to iterate over all the blocks within that radius (for loops) and check each for line of sight (ray trace). For better performance, you can limit the 'sniffing' to occur once every several ticks rather than once per tick, since the mob probably didn't move too far.

In 1.8, you can create block models directly via JSON. This post by TGG covers it pretty well.

Yep, a constant like that is not possible to use with Items or Blocks because the Item / Block is not initialized until later, so when you assign the constant the reference is null.

I have a custom chest that renders fine in the world using a TESR, but in the inventory it renders as a vanilla chest (achieved by using {"parent": "builtin/entity"} in the item model json). In 1.7.10, I got it working using an ISBRH with a dummy TileEntity of my custom chest, and had that render during #renderInventoryBlock. I tried something similar using ISmartItemModel, but only with partial success: private static final TileEntityMyCustomChest dummy = new TileEntityMyCustomChest(); @Override public IBakedModel handleItemState(ItemStack stack) { GlStateManager.pushMatrix(); GlStateManager.scale(0.625D, 0.625D, 0.625D); GlStateManager.rotate(245.0F, 0.0F, 1.0F, 0.0F); GlStateManager.translate(-0.5F, -0.5F, -0.5F); TileEntityRendererDispatcher.instance.renderTileEntityAt(dummy, 0, 0, 0, 0); GlStateManager.popMatrix(); return defaultModel; } If I don't return the default model, the inventory uses the 'missing texture' icon. If I do return it, it renders as a vanilla chest. The item in the player's hand (i.e. in world, not inventory), though, renders with the appropriate custom texture, but the vanilla model renders underneath it making it look kind of funny. I'm thinking if I can return the TextureAtlasSprite for my own texture, I can forgo all that other stuff. I've looked around for a while trying to find where I can retrieve an existing TextureAtlasSprite / instantiate a new one with the current resource location (is that even a good idea?), but I have not had any luck yet. I suppose there's always Reflection.

Works great, TGG - thanks!

Take a look at this post. In sum, look at RenderSnowball.

Gotta go to work now, but I'll try it out when I get back tonight.

Hmmm that's not good, sorry dude! The Camera Transform replaces the IBakedModels with a wrapped version but it doesn't implement ISmartBlockModel (only ISmartItemModel) so Forge's instanceof ISmartBlockModel fails. I'll update it... perhaps add a warning too... -TGG I was wondering where that IFlexibleBakedModel.Wrapper was coming from. Looking forward to the update, as it really is a very handy tool - it beats loading up Minecraft dozens of times per item just to check if the rotation looks okay.

You can't (and shouldn't!) just add @SideOnly to cause something to happen on one side or the other - that annotation actually strips the code below it from the jar when it is on the other side, so (Side.CLIENT) stuff doesn't even exist in the server jar. Side.SERVER is ONLY for the dedicated server, not even the integrated server (which is what is used in single player), and I haven't seen a use case yet in my own mods where it is ever needed. Long story short: NEVER use @SideOnly annotation. Use world.isRemote to check for which side your code is on if you don't already know - when it is true, you are on the client side, when it is false, you are on the server side. Here is some more information on packets. Here is some information on using events (e.g. KeyInputEvent). Here is an example of sending a packet to the server. Be sure to also check out the actual packet class for how it processes, and keep in mind that the server and client proxies must both implement a few methods to return the player / main thread, as explained in the packet tutorial linked earlier.

Whenever any of those numbers change, you need to mark the block for an update so it sends the description packet, otherwise it will not send one until the chunk reloads or some other situation forces it to.

Current as in the player's currently held item? Since user input is all handled client side, you are safe to use Minecraft.getMinecraft().thePlayer for the current client side player (i.e. the one who pressed the key). From there, simply get player.getHeldItem() and check if it is the item you want, but really I would just send the packet right away to the server saying 'player A pressed button B, now what?' and let the server handle all the logic. Unless whatever you want to do is client side only.

It has, but not really - a few methods have been renamed, the AI has changed a little, entity rendering has changed a little with the addition of Layers, but the basics of the actual entity class itself are nearly identical. Unless you are planning to something really complicated, which it doesn't sound like you are, you are unlikely to run into any major issues following a 1.7 tutorial and using that code for 1.8.

You need to subscribe to the KeyInputEvent (search for KeyHandler, KeyBinding, that kind of thing and you'll find tutorials on that), then when the key is pressed, which happens CLIENT side, you must send a packet to the server to let it know the key was pressed, and the server then decides what to do (e.g. clear the NBT data of the currently held item). If you are unfamiliar with packets, diesieben has a tutorial here in the Tutorials section that should get on the right path.

Have you tried searching, perhaps on Google? There are lots of tutorials, though I'm not sure how many are specifically for 1.8. Any tutorial for 1.7.10 should get you going for 1.8 as well, since the basics of coding an entity (registering it to EntityRegistry#registerModEntity, registering the render class, etc.) has not changed a whole lot, and mostly not at all. As for the entity in the end, that's an EntityEnderCrystal, but the code for healing is actually within the ender dragon class called from onLivingUpdate() -> updateDragonEnderCrystal().

This is really frustrating - I copied the code for these blocks into a blank workspace, as well as all the surrounding code for handling the rendering registration and such, and it works perfectly fine... yet I can't seem to get the original code to work again >.< Surely it is something different between the two sets of code, likely in one of the parts I removed so I didn't have to import everything. Guess it's time to run some diffs. EDIT: Holy balls, it was TGG's mod f-ing everything up somehow. As soon as I removed that, everything started working perfectly again. Can't believe I wasted so many hours on something that should have been the obvious difference between when it was last working and not. @TGG - I'm not sure how your camera code is messing with things, but you may want to check into that. Otherwise, it's a very handy tool (and still is, but sweet Jesus that caused me to waste a lot of time).

EDIT: Somehow caused by using TGG's camera tool. I have an ISmartBlockModel implementation that was working fine earlier (the most frustrating part, and I stupidly was not using git during my update process) to render a block based on its extended state. After adding many other things mostly unrelated to blocks, I added TGG's camera transform helper to get some item json files up to snuff, when suddenly my game crashed. NullPointerException retrieving my block's quads from the model because I have it do just that in the model class: public class MyCustomBlockRenderer implements ISmartBlockModel { // other code @Override public IBakedModel handleBlockState(IBlockState state) { System.out.println("I used to print, but now I don't! "); return defaultModel; // model swapped in from ModelBakeEvent } @Override public List getFaceQuads(EnumFacing face) { return null; } } That's what I don't understand - if my ISmartBlockModel class is getting called for 'getFaceQuads', which it is because I can return valid quads from there and the block renders, just not dynamically, then why is the check to see if it is an ISmartBlockModel failing: // In BlockRendererDispatcher#getModelFromBlockState: if(ibakedmodel instanceof net.minecraftforge.client.model.ISmartBlockModel) // <------ HERE is failing for my block model { IBlockState extendedState = block.getExtendedState(p_175022_1_, p_175022_2_, p_175022_3_); ibakedmodel = ((net.minecraftforge.client.model.ISmartBlockModel)ibakedmodel).handleBlockState(extendedState); } When I swap the baked model during ModelBakeEvent, my custom class instance is correctly identified as an ISmartBlockModel. To sum it up: it was working just fine previously, but I have obviously changed something somewhere that makes the baked model think it's not smart anymore even though the other methods in the class are being called; any ideas what it could be?

Yes, I suppose one could. I would argue for maintaining vanilla behavior as the default, so modders know what to expect rather than having nasty surprises, but that's just my opinion. Glad I saw this topic or I would have no doubt been scratching my head later on down the road.

This seems odd, since this behavior is exactly opposite of vanilla tile entities: public boolean shouldRefresh(World world, BlockPos pos, IBlockState oldState, IBlockState newState) { return !isVanilla || (oldState.getBlock() != newState.getBlock()); } What is the reasoning behind this choice of implementation? I would think that the majority of modded tile entities are modeled after vanilla tile entities in one way or another and would benefit just as much from having their data maintained by default. Would creating a 'base' mod TE class that overrides this to return just the getBlock() check have adverse consequences of some sort? What are some scenarios when one might want to re-create / destroy the tile entity? (should I ask this in a separate thread?)

That does work similar to what I'm looking for, however I'd like the spread to be much tighter, and just a little less random. It doesn't seem to be generating a trail, just a bunch of particles where the EntitySpell is at that moment. That formula will be useful though once I figure out the best way to use it on about every 0.2 blocks. Perhaps I get a vector from the caster to the Spell, and maybe I can do something with that? Please read more carefully - I already said I use the player's look vector to determine the x/y/z and iterate along that, I just left that out of the code example. Of course if you just copy/paste the above without changing anything all of the particles spawn roughly in one location. To get a tighter pattern, reduce the randomness: coordinate + 0.25F - (rand.nextFloat() * 0.5F) // now the random value can only be +/- 0.25F in either direction Whereas in my previous example, it was +/- 0.5F in either direction. Random#nextFloat() returns a value between -1.0F and 1.0F, inclusive.