[1.10] Custom ItemBlock class?

[Draco18s 2414]

One last question:

Any way to do something similar with regular items? All I'm seeing are these predicate overrides which point to alternate model jsons.

 

Its fine if not, just would've been nice.

[Choonster 1651]

Any

Item

can use a model specified by any blockstates JSON. Regular items obviously don't have a

Block

to get the variant names from, but you can use an enum like

ItemDye

and

ItemFishFood

do.

 

In my

ModModelManager

class, all of the overloads of

registerItemModel

are designed to be used for

Item

s that have a single model. The overloads of

registerItemModelForMeta

are designed to be used for

Item

s that have a different model for each metadata value.

 

All of these overloads just boil down to a single

ModelLoader.setCustomMeshDefinition

or

ModelLoader.setCustomModelResourceLocation

call with various default values.

[Draco18s 2414]

I was looking at

ItemDye

and it forwards everything to a bunch of models.

 

But yeah, I have an enum and the ordinal of each one would be the metadata involved, but I couldn't get things pointed at a block state file in a way that the game liked.  I had things going down the same path as the metadata block, but I either got purple squares and no errors or invisible items (the textures in use at the time were vanilla items).

 

It was basically ignoring the "variants" section in the json file, as far as I could tell (as I had one or two matching the variants generated by the code below, but I wasn't getting "could not find variant in file" errors unless the json file itself didn't exist).

 

Anyway, this is the code I have:

	public void RegisterItemWithVariants(Item item, String registryname, IMetaLookup variant) {
	super.RegisterItemWithVariants(item, registryname, variant);
	List<ItemStack> list = new ArrayList<ItemStack>();
	item.getSubItems(item, CreativeTabs.SEARCH, list);
	for(ItemStack stack : list) {
		registerItemModelForMeta(item, stack.getMetadata(), variant.getName()+"="+variant.getByOrdinal(stack.getMetadata()).name());
	}
}

 

Where

registerItemModelForMeta

is that same function being used by the blocks that you had in your code and

IMetaLookup

is just an interface wrapper around the enum I'm using so I can convert it back into the variant strings similar to the block's "getPropertyString()" call (I pass in MyEnum.ARBITRARY_VALUE and it's just used to access the lookup methods).

 

(JSON file at the moment is set up with predicate overrides, not variants, so not including it).

 

Is the problem the fact that for the item it's looking at "modid:models/item" for the json file (due to

item.getRegistryName()

and I really need to point it at "modid:blockstates"?

 

TL;DR:

I'm basically scratching my head because I'm getting no feedback when something doesn't work.

[Choonster 1651]

I'm not entirely sure what you've done wrong, but you can see my implementation of an item (and its models) with enum-based metadata variants here.

[Draco18s 2414]

Yeah, like I said, I'm not sure what I've done wrong either, only that no errors are logged.  I'll digest your code here in a bit.

 

One of the differences is that my enum list isn't going to be used in its entirety: I've got several ore types to deal with, but any given item won't necessarily be valid for all the ore types, e.g. metal nuggets.  I don't need to create a Gold Nugget variant item model because that item is already supplied by vanilla.  That was why I was using item.getSubItems() rather than enum.values; I want to maintain metavalues across several items.

 

Anyway, thanks for the continued help.  Eventually I'll understand how the vanilla systems work well enough to rapidly prototype items like I used to.

[Draco18s 2414]

A lot of things

 

Ok, that came down to realizing that you had a custom model defined in an odd spot that I didn't notice right away.  It looked so much like something else that.

 

Urg.  So many things can go wrong with this new system, especially when trying to avoid asset bloat (seriously, vanilla has sixty four models for the clock).  And half of them don't even generate errors.*  Makes me feel like this json model system is built out of magic strings.  Which it kind of is, the problem is that it's not well documented so setting up something is either: do it the painful vanilla way or try to examine the code that parses the json files (I tried and couldn't even locate an entry point that I could follow).

 

That whole "abstractions at their core are lies" thing.

 

[me=Draco18s]archives the project in this state so if he ever needs to do this again, he has it.[/me]

 

*This is probably an exaggeration, but the number of times I've gotten purple squares or outright invisible models without a single logged error is about as many times as I've had errors.

[Choonster 1651]

I did link to an explanation of the model loading process in my first reply, you may want to look through the code paths it mentions to see how models are parsed.

[Draco18s 2414]

I did link to an explanation of the model loading process in my first reply, you may want to look through the code paths it mentions to see how models are parsed.

 

I know. It was a problem of not being able to see every detail that I needed to see.

 

And I'll do that at some point, but not right away.