[Solved][1.7.x]Confused myself about renderer registration

[jabelar]

Okay, I've been happily modding entities for a while now, with custom models and renderer classes and it worked well.  I recently tried to do something that required something to be dynamically passed to the renderer and when I really thought about how the renderer registration works I started to confuse myself. 

 

The confusion came about because I was creating an egg-like throwable item and so I copied the render class for the snowball item.  However, the constructor for the snowball takes an Item parameter and so at the time of registration you have to pass an instance to it.  But my problem is that each instance of my item may render differently (mostly different colors).

 

So I think it won't work directly because the Item instance passed to the RenderSnowball during registration will be different than the instance of the item I'm actually wanting to render.  In other words it will render the original item passed and not the current one that created the entity being thrown.

 

I just want to confirm that point, as I guess I'll have to go through some hoops to make it work.  Basically my plan is to have the throwable entity get the custom render information from the item at the time it is thrown, and then pass that back to the renderer.

 

Not sure if my explanation above is clear.  My question is specifically whether the RenderSnowball will render the Item as registered rather than the item as used to create the entity.  My review of the code indicates: yes.

[coolAlias]

You could do as suggested above, or try something I've used which is to store the ItemStack in the entity's DataWatcher:

// data type 5 is ItemStack, as seen in EntityItem's entityInit()
dataWatcher.addObjectByDataType(DATAWATCHER_INDEX, 5);

// then before you spawn your entity, update the DataWatcher with whatever ItemStack you want

 

I did it that way because at the time I didn't know about IEntityAdditionalSpawnData, and it seems to get the job done just as well. I don't know if there is any advantage to one over the other, but perhaps some others have input in that regard.

[jabelar]

Thanks both of you.  Pretty much what I expected.  Need to bring original item along with the entity.  Data watcher is interesting as it would save the packet sync.  I need to look at that additional spawn data interface, also looks interesting and isn't something I noticed before.

[coolAlias]

Thanks both of you.  Pretty much what I expected.  Need to bring original item along with the entity.  Data watcher is interesting as it would save the packet sync.  I need to look at that additional spawn data interface, also looks interesting and isn't something I noticed before.

The additional spawn data is for the spawn entity packet sent to the client automatically by Forge (this is why you need to register all your mod entities, for this specific packet); thus, if you implemented that interface, you wouldn't have to do interact with the packet at all manually.

 

Either way you do it, you still need to set the ItemStack you want before you spawn the entity, and then have a method to retrieve it (or make it a public field, but that's just bad practice )

[coolAlias]

DataWatcher is a bit overkill in this case, because I assume the Item will not change once the entity has been thrown.

Ah, I hadn't thought about that - I guess it makes sense that DW must have some processes going on in the background to check if the data has changed, otherwise it wouldn't work Good point!