[1.12.2] Model overrides applying globally instead of per stack?

[IceMetalPunk]

*EDIT* The original issue has been solved, but it's led to a related issue. Please check out that issue down below, in this reply. If you can help get this working 100% instead of just 75%, I'd appreciate it!

 

The repo/branch for this issue is the same, still here: https://github.com/IceMetalPunk/Magical-Meta/tree/feature/ender-compass

Original post kept for context and archival purposes:

==========================================================================================================

I'm working on adding an item that's basically a compass, except it points to a player-set location instead of the spawn point. So I more or less copied over ItemCompass's property override for "angle", its model files, and its textures (and made the appropriate changes). And then when I load the game... it's the purple-and-black "not found" model and texture. I get no errors in the console. So I started throwing debug logging around, and it looks like my models are never being registered. Yet I can't figure out why.

Here's the repo and branch where I'm working on this: https://github.com/IceMetalPunk/Magical-Meta/tree/feature/ender-compass

 

Ultimately, I'd expect things to work like this: proxy instantiates ItemRegistry and adds an instance of ItemEnderCompass to it. ItemRegistry listens for events to register it, including the ModelRegistryEvent, during which (if it's on the client, i.e. instantiated by the ClientProxy) it'll call the item's registerModel() method. At that point, the model from the assets/magicalmeta/models folder will load, including the model overrides for the "angle" property, like a normal compass.

But somehow, the debug logging I added to the BasicItem#registerModel method isn't showing up, which tells me the model isn't being registered at all.
What am I missing here? It's been a little while since I've dealt with the foundations of Forge, so I know I'm rusty, but I just don't see the issue.

Edited August 9, 2018 by IceMetalPunk
Updated issue with link back

[Animefan8888]

8 minutes ago, IceMetalPunk said:

What am I missing here? It's been a little while since I've dealt with the foundations of Forge, so I know I'm rusty, but I just don't see the issue.

You need to have a ModelRegistryEvent to register your models. Also take a look at Code Styles #1 and #3.

[IceMetalPunk]

14 minutes ago, Animefan8888 said:

You need to have a ModelRegistryEvent to register your models. Also take a look at Code Styles #1 and #3.

I do... if you look at the ItemRegistry and BlockRegistry (in the api package), they both listen for the ModelRegistryEvent and only fire the model registry methods on their items/blocks then.

As for the coding styles, I guess that makes sense, and I can change it once I get things working here. (Correction: I have fixed it on the master branch, and am waiting to merge those changes into this Ender Compass feature branch until the item works, because I'd rather deal with all merge conflicts at once.)

Edited August 8, 2018 by IceMetalPunk

[Animefan8888]

10 minutes ago, IceMetalPunk said:

I do... if you look at the ItemRegistry and BlockRegistry (in the api package), they both listen for the ModelRegistryEvent and only fire the model registry methods on their items/blocks then.

Ahh I see, my bad I've never seen someone have two ModelRegistryEvents and separated them between Blocks and Items. Speaking of which, don't, you only need one.

 

Your problem is that since you are calling the super method in your client proxy the item is being added to the common proxies items and not the client proxies. Don't have two instances, only have one Registry Event per type.

[IceMetalPunk]

5 minutes ago, Animefan8888 said:

Ahh I see, my bad I've never seen someone have two ModelRegistryEvents and separated them between Blocks and Items. Speaking of which, don't, you only need one.

 

Your problem is that since you are calling the super method in your client proxy the item is being added to the common proxies items and not the client proxies. Don't have two instances, only have one Registry Event per type.

I admit I'm not as familiar with Java as I am with other languages, but... is that how inheritance works? If A extends B, and B calls a super method from A, doesn't that method still reference fields from B which override fields from A? (So in this case, since ClientProxy extends ServerProxy, and ClientProxy also overrides the blocks and items fields, shouldn't references to blocks and items point to the ones from ClientProxy?)

 

*EDIT* Welp, my lack of Java knowledge has bitten me today, it seems. A quick Google (now that I know what to look for) tells me that fields in Java can be shadowed, but not truly overridden. Blech. Okay, time to merge in the refactor and move more stuff around... thanks.

Edited August 8, 2018 by IceMetalPunk

[Animefan8888]

13 minutes ago, IceMetalPunk said:

I admit I'm not as familiar with Java as I am with other languages, but... is that how inheritance works? If A extends B, and B calls a super method from A, doesn't that method still reference fields from B which override fields from A? (So in this case, since ClientProxy extends ServerProxy, and ClientProxy also overrides the blocks and items fields, shouldn't references to blocks and items point to the ones from ClientProxy?)

Yes that is exactly how this works. Its called variable shadowing, you can read a bit on it here.

 

Edit: Wait I read that wrong. No they do not you actually end up with two variables with the same name.

Edited August 8, 2018 by Animefan8888

[IceMetalPunk]

Yep, everything's working now that I've switched over to the no-common-proxy style I still have an issue where *all* Ender Compasses point to the same location, even though the stack is being passed into the property override and the stacks should have different tags being read by the IPropertyGetter's methods. But that's a bug for a different day, as it's 1AM here now. (Unless someone wants to take a look at the ItemEnderCompass in the latest commit on the branch I linked to above... but if not, that's fine, I'll work on it tomorrow-ish.)

 

Thanks!

[Animefan8888]

10 minutes ago, IceMetalPunk said:

Yep, everything's working now that I've switched over to the no-common-proxy style I still have an issue where *all* Ender Compasses point to the same location, even though the stack is being passed into the property override and the stacks should have different tags being read by the IPropertyGetter's methods. But that's a bug for a different day, as it's 1AM here now. (Unless someone wants to take a look at the ItemEnderCompass in the latest commit on the branch I linked to above... but if not, that's fine, I'll work on it tomorrow-ish.)

 

Thanks!

Is the apply method even being called?

[IceMetalPunk]

21 hours ago, Animefan8888 said:

Is the apply method even being called?

Yep. Not only is the compass pointing to the right direction, but any debug logging added to the apply method is output. It's just somehow applying to all copies of that item, even in different item stacks with different NBT data. (At least, they should have different NBT data. I'm about to start debugging now.)

 

EDIT More debugging later... according to the apply() method, they *are* being called with different stacks, which *do* have different NBT data, as they should. But they're still rendering the same even though their overrides are being called with different data...

EDIT 2 I've done some more investigation. I now know the stack trace (for lack of a better phrase) by which items are rendered into GUI slots.

1. GuiContainer calls drawSlot(), which grabs the item stack from its given slot index.
2. That calls RenderItem#renderItemAndEffectIntoGUI(), passing it the stack.
3. That passes the item stack over to its getItemModelWithOverrides() method, and the result is passed to renderItemModelIntoGui(), which ultimately actually renders the item.
4. getItemModelWithOverrides() passes the stack to ItemOverrideList#handleItemState().
5. That passes the stack to its applyOverride() method. That passes the stack to ItemOverride#matchesItemStack(), for each ItemOverride in its list (which is populated with the overrides from the JSON model on construction).
6. And finally, that passes the stack to the PropertyGetter's apply() method that we all know and love by now.

Nowhere along that path is the stack altered, and debug output on the apply() method shows the two stacks I have contain different NBT tags being used in the getPosToAngle() method.

Whew. That was a long path. And yet, at the end of it... each stack should be rendering separately! So why are they rendering identically? (Literally, I can change the NBT tags of one stack, and both models change simultaneously instead of just the one from the stack I changed.)

Edited August 9, 2018 by IceMetalPunk
Formatting.