It seems like some of the cit properties are not working correctly as they should.

Using latest CITResewn version.

"tile" as a replacement for "texture" gives an error: "Skipped CIT: Cannot resolve path for model/texture"

"regex" does not seem to work at all sadly. ( Used something as simple as "nbt.display.Name=iregex:(Test)" or "nbt.display.Name=regex:Test" which work just fine in Optifine )

The tile thing is not documented anywhere both in optifine and in mcpatcher. But it is an alias for texture in optifine for some reason so I added it(b3dd941) because it wont hurt anyone.

The regex thing was just me not removing the iregex: fully from the pattern(2f45ca5).

Fixed in v0.6.1.

Just want to add, please do not use tile. I added it just to add support for old packs but if you're making anything new you should use texture instead.

Wow, that was fast :O

I know its a mess with the Optifine docs and the tile textures were just some old ones i never changed until now cause they never made problems ^^" Glad it works now.

Thank you very much for the lightning fast response and fixes, ill test everything as soon as i find the time.

There are either no jsons or there are.
If there are jsons, the jsons can define their own textures like vanilla models do normally.
If there arent jsons, specifying just texture is enough for the properties to create a new model internally out of the textures.

Essentially, a pack wouldnt need 200 extra jsons if it didnt already have them.

It works! No errors anymore and regex also works as intended. 👍

But... It looks like its not possible to define a custom model and a texture inside the same .properties file.

Example:

items=wooden_sword
nbt.display.Name=iregex:(Staff)
model=optifine/cit/test/staff.json
texture=optifine/cit/test/staff.png

The model has no own texture but is an edited version of the default "handheld.json" to look like the player holds the item vertically.
All items using this method are invisible, so i think the texture isnt even loaded.

Using a model that has a texture itself works just fine. But you cannot overwrite the texture maybe because of the same problem.

This is the staff.json i use:

{
  "parent": "item/handheld",
  "display": {
    "thirdperson_righthand": {
        "rotation": [ 0, -90, -10 ],
        "translation": [ 0, 1, 3 ],
        "scale": [ 1.7, 1.7, 0.95 ]
    },
    "thirdperson_lefthand": {
        "rotation": [ 0, 90, 10 ],
        "translation": [ 0, 1, 3 ],
        "scale": [ 1.7, 1.7, 0.95 ]
    },
    "firstperson_righthand": {
        "rotation": [ 0, -90, 25 ],
        "translation": [ 1.13, 3.2, 1.13 ],
        "scale": [ 1.36, 1.36, 0.95 ]
    },
    "firstperson_lefthand": {
        "rotation": [ 0, 90, -25 ],
        "translation": [ 1.13, 3.2, 1.13 ],
        "scale": [ 1.36, 1.36, 0.95 ]
    },
    "gui": {
        "translation": [ 4, 4, 0],
        "scale": [ 2, 2, 1 ]
    },
    "fixed": {
        "translation": [ 4, 4, 0],
        "scale": [ 2, 2, 1 ]
    }
  }
}

I'm marking that one with "working as intended", there are both some technical problems with adding the texture to the model in that manner as well as the design problem where the philosophy here is that if someone can define a model, they know how to define textures in said model. The texture tag is meant for people who do not want to mess with jsons at all.

You can also define relative paths in models that are loaded by cit, for example:

  "textures": {
    "layer0": "./staff"
  }

will load the staff texture you have next to the staff json.

This would be the way to go yes, but doing this for 200+ weapons, shields and other items means 200+ more .jsons to generate on top of the .properties files ^^"

I know its a "nice to have" feature and not a bug, but it would still be very helpful.

Right now and without a given texture inside the model i am able to use this same model for every item that needs it, requiring only one model for x staffs.
As soon as i define a texture inside the model i need one model for each item, so x models or maybe x+1 if i use parenting to do it correct.

Hmm.. haven't thought about that..

Is this a thing that works in optifine's implementation?

Its a little tricky way to save a lot of work making a bunch of models that you wont really need ^^"

And yea it works just fine with Optifine

Ok, I'll look into it. I've opened #33, you might want to enable notifications there.

Thank you very much, i will 💯

Could you please send over the resourcepack with the one model, multiple texture properties thing for me to test with?

MultiModelExample.zip

There you go ^^
Some shields and weapons using this method.