Hi,

I was writing a bunch of property file to change painting icons based on variant, and found the task to be needlessly repetitive.
Since CIT already supports regex-matching, I though it would be nice being able to use regex capture groups to automatically derive the texture path from the variant id. This way, everything could be compacted into a single file, which would look something like this:

type=item
items=painting

# Variant id is saved in capture group number 1
nbt.EntityTag.variant=regex:^mynamespace:(.+)$

# Value of group 1 is used as the filename
texture=regex:mynamespace:item/$1.png

Being able to merge everything into a single file could also offer an extra layer of optimizations. (Probably related to #230)
When stress-testing, I noticed that increasing the amount of .properties files for painting items could cause the framerate to drop quite fast.

When looking at an inventory-full of paintings, I'd loose 40fps for every 100 property files I added. (Increasing the cache period does help a little, but still causes lag spikes whenever paintings are dragged and dropped.)
For reference, the mods Painting+ and Texel Paintings alone add 74 and 40 paintings respectively. So reaching that amount of variants in-game seems plausible to me.

If anything might as well use named capture groups as they are much more readable.

The problem here is that as of right now CITs are fully deteministic, meaning that from reading the properties file you could learn the entire tree of json models that need to be loaded by the game. Which is what I am doing to request that these json models be loaded in addition to vanilla jsons.

Introducing something that creates the model path based on an ingame dynamic property turns this process non-determined. Like, what if some player ingame names an item something that the game isnt expecting, or modifies the nbt to be a new value that the properties is not taking into account since it is reading the value of the wild card it asks for. The cit conditions already passed, is it supposed to just throw a missing model on the item and call it a day?

This also means that the game would not be able to know right away(during resource loading) what json files it needs to load for the properties file.

I do however agree that this could be insanely powerfull for pack makers, and it would allow for a lot of cool stuff beyond the issue you described. And it would definitely reduce drastically the amount of cits required in large resourcepacks. The only question is how to implement it cleanly.

This is good timing as before I was taking my break from CIT Resewn I was working on recreating the model structure that the mod uses to be more usable. This is something I need to look at before I continue with that because it'd be hard to modify after.

As for the lag spikes when a high cache is used, that is exactly why the cache is there, without it, those lag spikes would be the case for every frame the game tries to render. It's just a mitigation for when things stay the same across frames(items arent being created and destroyed or modified so no need to recheck all of the conditions)

Named capture groups would be great as well. Functionally, they aren't much different from the numbered ones; those are just implicitely named.

Throwing a missing texture would sound like the expected behaviour to me. I've never manipulated models though, even outside of cit, so I have no idea what a missing model would look like.
Ignoring the file and falling back to a lower weight cit could be a handy option, but by no means necessary.

This also means that the game would not be able to know right away(during resource loading) what json files it needs to load for the properties file.

Here are a few ideas that came to mind :

• A single separate file, which lists all files and folders with additional resources that need to be loaded, even if they are not mentioned in a cit property file.
• Require pack makers to provide a search pattern in the cit files what need it, and load all resources which match this pattern. This would also allow them to provide resource patterns that are even more specific. For example I have a tendency to include dimensions in painting variants, so I can use that to exclude non-painting textures:

nbt.EntityTag.variant=regex:^mynamespace:(.+)$
texture=regex:mynamespace:item/$1.png
resources_to_be_loaded=pattern:mynamespace:item/*_?x?.png$

• Automatically derive a search pattern from the model's regex, and load all resources that match this pattern. For example, mynamespace:item/$1.png would turn into mynamespace:item/*.png just by substituting all variables with *.
  (Although in this case, it would be best that I move my painting textures into a subfolder or give them a constant prefix, so the resulting pattern can be more specific.)