TrashCaster

Try getting rid of the forward slashes that you put after the colons in the resource locations. IE. Change "" to ":"

What parameters would I be passing in for the IBlockState, IBlockAccess, and BlockPos? Cause it's not physical blocks in the world, it's just ItemStacks stored in NBT. Is it safe to pass null for the last two? This is why I thought getItemModel would work cause I will be using item stacks.

Alright, and is there a function that gets the block models of said blocks? I'm thinking getItemModel() in the ItemMesher, but I don't know if that will work. If it's wrong, where do I start with that? Also, when I return the TextureAtlasSprite, how will I compile all the textures of all the blocks into one? And if I do so, will all the block faces grab the right textures, or do I have to re-uv map them?

What I want to do is render my item as a series of mini-blocks stored in the item's NBT data. I'm used to doing this via IItemRenderer, and seeing as how that's deprecated, I've been guided into using ISmartItemModel. Problem is, I don't know where to start. Has anyone delved into this? How would I go about doing this? I'm trying to use SimpleBakedModel's builder, and don't really know where to go from there. I have no code to show, because I don't know what I'm doing to begin with. Just being honest here. All I've done is create empty fields to see what methods are what, and what parameters they can take, so that I could have a general idea of a starting ground, but would rather not waste my time banging out code that's wrong or won't compile or run. Help me, without spoon-feeding complete code? I'd like to learn the new way of dynamic model generation.

Ah, ok. I see it got added in a version later than I was using. I'm updating as we speak, and I will try this. Thanks for the quick replies, it is much obliged. Any further questions, and I will post in the support section. Thanks a bunch. Feel free to close/lock this thread.

I want to render the same compiled model for being on the ground, in the inventory, in hand in first person, and in hand in third person. This is why I need IItemRenderer. It had the ability to render said model, which I would be rendering on the go based on the blocks stored in the itemstack. Rendering it on the head is relatively simple, as there is the RenderPlayerEvent. But there's no "RenderItemEvent". IItemRenderer was that event, essentially. I want to iterate through a list of itemstacks stored on the itemstack (via a compound tag list) that is either equipped, or in hand/inventory/on the ground, and render each block. If it's possible to do that without the use of IItemRenderer, then it would be very swell to have a link returned. I'm all for keeping the methods of rendering to the new default way, but we at least need a way to compile our own unique, per-itemstack models on the fly. As for your suggestion, if it still pertains to the above re-defined description, how would I go about doing that? Do we already have tutorials made for going from using the old IItemRenderer + GL function and Tessellator method to this new system? If it isn't possible to do what I am describing with the new rendering method, then why abandon a functional component, that does get it done, without limiting the creative boundaries of Minecraft. I would say it should be noted to use the new system as much as possible, but if you really must, then feel free to use the old method.

I don't see this being relevant to my needs. Care to explain?

My approach would have to be done programmatically. For my project, I want to the item to render a series of blocks based on the blocks stored in the NBT of the itemstack.

You could make copies of all the entity classes that would go into your dimension, and basically convert them when they enter, rather than put the actual entity in, and do the reverse for going back to other worlds. Just make sure to extend their copied classes to retain the same compatibility. Ex: // On send entity to dimension EntitySheep sheep = (EntitySheep)originalEntity; EntityStellarSheep stellarSheep = new EntityStellarSheep(); stellarSheep.setPositionAndRotation(sheep.posX,sheep.posY,sheep.posZ, sheep.rotationYaw, sheep.rotationPitch); stellarSheep.setFleeceColor(sheep.getFleeceColor()); // etc, etc Then after all is said and done, just override their update methods to apply your gravity instead of the built int gravity.

You need to handle your Gui, and return a Container object for the server element, and Gui Screen object for the client element. You can define your own Gui ID constants in your mod class, and then use them to test the ID sent to the handler via player.openGui(MOD, GUI_ID). This is the Forge tutorial on the wiki (I've done the Google cache link, because the Wiki was loading really slow for me): http://webcache.googleusercontent.com/search?q=cache:5hpWm4A2w1MJ:www.minecraftforge.net/wiki/Containers_and_GUIs+&cd=1&hl=en&ct=clnk&gl=ca

I would like to see IItemRenderer stay because I need to generate the model based on various ambiguous NBT tags. For example, a player creates an item with custom components, based on any possible input, and the model in hand is a collaboration of all those items. I really need this feature for a mod I am working on, so some way of creating models through the mod's code, and not through model files, would be best.

The problem is: a) Then you are using the update method of the seat to constantly test that the player that was on the seat previously, is no longer there (Why store an additional entity field if not necessary) b) The teleporting will look awful if jumping from pre-set location "A" to new location "B". I have just tried this, and it actually looks fine. At least in SSP. Not sure of SMP yet. Keep in mind, that with 1.7, dismounting is done by sneaking, not right clicking. So it would need to be overridden at the source. I don't think bad-practice "work arounds" are an efficient way of programming, and there really should be an override method for it, as is. At the very least, the option to just cancel the integrated dismount and apply a new one manually.

Currently, by default, when dismounting an entity, you teleport away from the entity. If there were a way to override this location via a DismountEntityEvent, the possibility to alter it based on various factors would be near endless. Example: I have a mod, where you right click a chair, and it summons a "seat" entity, then mounts it. When you dismount it, you are teleported several blocks from the chair. With a hook to override this, I could make the player dismount the seat to a location relative to the seat; by grabbing the block-metadata at the seat coordinates, and applying a delta position. Then I could have it drop the player off right in front of the chair block, rather than 3 blocks away. Any alternative ideas/workarounds? Anybody support this idea?