I just tried Charset chests and wasn't able to find any textures or ways of adding textures to certain generated chests. I create a lot of my own assets for things as my tastes are ridiculously particular. So I was wondering if perhaps there could be some way to override the generated textures with custom ones.

Maybe a json file somewhere?

A config where you can tell the mod to look in assets/charset/chests/textures/entity/chest first and fallback on generation if it finds nothing?

Maybe a zenscript solution? mods.charset.chests.textureOverride("minecraft:planks:1", "assets/charset/chests/textures/entity/chest", "spruce"); or something like that.

Ideally, it would give you full creative control by attempting to detect for the 4 variants. In the example of spruce, it would look for spruce_normal, spruce_double, spruce_trapped_normal, spruce_trapped_double.

This feature, assuming I haven't derped and missed it, would make it just perfect in my opinion. Either way, though, keep up the good work. :)

Caught your message on IRC.

It is planned already! Just a bit of a low priority right now between the more urgent things (features necessary for the upcoming BTM and some things I just need to introduce now).

I'm going to propose a stopgap solution and listen to your input:

The command "/ch hand material" currently gives you the material ID of a given item in your hand. (It's in green; I'll make it more clear in 0.5.4.6).

Using CraftTweaker for this would be sub-par, as I'd like to have users provide resource packs. However, the material names, especially when NBT comes into play, can become very long and definitely unsuitable for a filename.

As a resource pack developer, you would create a .JSON file, called assets/charset/material_keys.json:

{
    "minecraft:planks;1": "spruce"
}

This would then let you put textures named assets/charset/textures/entity/chest/spruce/normal.png, etc.

I am not sure about this (I really want texture generation to be the key route for consistency between mods, and if you can point to specific issues I might be able to tweak the algorithms to cover them), but if I were to implement is it'd be that way.

Yeah, ideally it'd be something detectable from the resource pack, I only mentioned anything else as a possible option depending on what'd be easier. And yes, generation would still be the main method of course, and would be used as the fallback of not finding the hard textures. This feature would mainly be a content-creator's dream feature more than the standard user feature. Generated is definitely fine by a lot of people's standards, and what you've got generating isn't bad at all!

The feature is more about creative freedom. For those who go hardcore into delving into the customization of their packs, or those who just want their favorite wood type to have a pretty, unique texture, or those who just expect a stone chest to look very different from a wooden one, and other varying degrees of pickiness. The generated textures are consistent, which is awesome by itself and one of the biggest things I look for in a pack (mods, resources, or otherwise), but it's just that one step short of being freedom.

Placing all of the keys into one file, detectable in a resourcepack would be pretty good. Perhaps this could also be yet another means for your mod to pickup something to generate textures for? Say, it's mentioned in the file, but does NOT have a folder given to it containing any hard textures, it would detect that this is just a material a new chest could be made from, and generate things how your code normally handles it.

However (feel free to ignore this if it means cancelling the idea), how would this work in the cascading of multiple resource packs work? Would it only read the upper-most file, or would you grab all the unique ids from each file, prioritizing each one as resource packs do? This isn't particularly important to me myself, but I could see how some users might find it helpful.

I make no demands, expect no feelings of obligation, nor would I blame you for trashing my ideas and doing things your own way, but it certainly is nice to know you're listening. :p

I get the idea, but I'm also about creative integrity of my own work, and every configuration option tends to be a bit of a trade-off.

However (feel free to ignore this if it means cancelling the idea), how would this work in the cascading of multiple resource packs work? Would it only read the upper-most file, or would you grab all the unique ids from each file, prioritizing each one as resource packs do? This isn't particularly important to me myself, but I could see how some users might find it helpful.

In this vision, every resource pack would have its own unique IDs - that is to say, no cascading, but also no issues with stacking resource packs.

I see what you're saying. I didn't think this to take away from that, but I'm no good with code as I am with textures/resource packs. I apologize.

Anyways, the resource pack .JSON file would be perfect if you decide to implement it. It's what people are most familiar with in resourcepacks now considering Mojang adopting the format for the last few years.