-
Notifications
You must be signed in to change notification settings - Fork 1
FAQ
If this pack was made for Optifine: No. VCIT uses its own resource format, and has a fundamentally different approach to CITs.
Optifine works by defining variants on a case-by-case basis. Variants-CIT works by defining a "module" for an item, which manages multiple variants at once.
VCIT works best for packs that have many variants for a single item. Its goal is to handle as many variants as possible using as few files as possible, and yield better performances in the most extreme cases.
Historically, the main design philosophy for modules was to have a single generic rule that lets the mod automatically figure out an item's variants, and their associated models. Today, there's also a predicates module type that works more similarly to optifine, on case-by-case basis.
Follow the introductory tutorial. Then pick a module type that best matches your use case.
Follow the introductory tutorial, which does precisely that.
Instead of using the custom_name module showcased in the tutorial, use a component_data module with a Regex Transform.
{
"items": "...",
"modelPrefix": "...",
"type": "component_data",
"parameters": {
"componentType": "custom_name",
"transform": [
{
"function": "sanitize"
},
{
"regex": "prefix_(.*)_suffix",
"substitution": "$1"
}
]
}
}You can use Regex 101 to test your regexes and substitution strings. Make sure to select the "Java" flavor and the "Substitution" function in the left panel.
Remember that unlike optifine, VCIT does not work by matching values, but by transforming raw data into a variant ID. Similarly, the regex here does not simply validate the name's format, it extracts a variant from the name, using capturing groups and a substitution string
See also: Regex-related Issues
Check whether there is a purpose-made module for your use case. Otherwise, use a component_data module.
See also: Item properties and 'item_component' property
Use a component_format module instead of component_data.
See also: Item properties and 'item_component' property
For checking some invariant data on an item, use the precondition field of a module.
For checking data that directly affects the item's variant, you may use a predicates module type (if no other module matches your use-case).
Example:
Not Supported.
Some other modules do support thresholds: component_threshold, item_count, enchantment_vector, etc.
If all else fail, you can also try using a predicates module type.
Not supported. Under consideration, but no ETA. Please open an issue describing your use cases, to help shape a potential upcoming feature.
In short, add those fields to your modules:
{
"hook": "equippable",
"assetGen": "equipment/humanoid"
}See Equipable Modules for detailled instructions.
Not supported. Projectiles are rendered as entities, not as item stacks.
Set the "assetGen" field of your module to the appropriate preset. Common tools use item_model/handheld. Items with animations have more specific presets such as item_model/bow or item_model/trident.
See "Built-in Asset Generator Presets" for the complete list of posssible values.
For items with no animation, you can also use the simpler "modelParent" field instead of "assetGen".
If no preset matches your item, you will need to provide your own item states. You can provide them directly as plain variant assets (see: modelPrefix), or you can write a custom asset generator to write most of those assets for you. Either way, this requires a good understanding of how vanilla resource packs.
Item states are a vanilla feature. If you have trouble getting item states to work, you can also try seeking help from other minecraft communities; they probably have more resources and will be more reactive than I. See also: Item Model Definition, Item-states related issues
Just use the vanilla format for your textures. This means putting all your frames in a single png, with a corresponding .png.mcmeta file.
If you have trouble getting vanilla animations to work, also try seeking help from other Minecraft communities; they probably have more resources and will be more reactive than I.
Do not use Optifine, Cit-Resewn, or Blockbench as indicators that your models are valid.
Your json models probably rely on features that are exclusive to optifine, those models are not compatible with vanilla minecraft and need to be modified. Unlike Optifine, Variants-CIT does not change the inner-working of models; all it does is swap one model for another.
Known issues are:
- The resource location of models or textures uses a bad formatting
- The assets are stored in an invalid directory
Either disable ModernFix's Dynamic Resources feature, or bake Variants-CIT's generated assets.
This wiki is for version 5.3 of Variants-CIT
{ "modelPrefix": "enchanted_end_sword/", "assetGen": "item_model/handheld", // Invariant requirements do not affect which model is used, but are still required to apply a model at all. "items": "diamond_sword", "precondition": { "custom_data.server_item_type": "END_SWORD" }, // Case-by-case variants "type": "predicates", "parameters": { "predicates": [ { "variantId": "ascended", "precondition": { "custom_data.ascended": 1 } } { "variantId": "reforged", "precondition": { "custom_data.reforged": 1 } } ] } }