WIP - Other rig properties, mob type, color variant

[zNightlord]

WIP of #440, second part of #561 (This is not ready for review, discuss further on how this should be implemented)

As in #440 this add a system for rig have MCPREP_RIGTYPE non "Custom" under the rig armature object to use a different skin swap tab. It would be an improvement spawn_with_skin since it getting directly from the resource pack path.

https://github.com/Moo-Ack-Productions/MCprep/assets/61040487/5fc96af7-5e12-4648-94da-d9de2de3611d

The UI properties is store under a class and go through store at WindowManager context. Question: How should it have access to the rig materials? 1) Have a for loop iterate though the objects find matching material type property MCPREP_MatType (for example "Profession" "Level" "Biome" for villager) 2) Have many custom properties MCPREP_MatVillagerProfession MCPREP_MatVillagerLevel MCPrep_MatVillagerBiome string name under the armature object and materials.get( name) to get

and use skin swap function to set the texture inside.

"Invert" mob type. How or should have an "invert" or zombified type as a checkbox? Allay -> Vex; Piglin -> Zombified Piglin; Hoglin -> Zombified Hoglin; Zombie Villager;

UI it would be something like Mine imator with the variant but rather upon adding the mob you do it after with an operator button to switch variant or color MCPREP_HAS_COLOR.

[zNightlord]

Some code during the merging is mess up at some spot and not tested so I want to see how it should be structured from this draft.

How should it have access to the rig materials? 1) Have a for loop iterate though the objects find matching material type property MCPREP_MatType (for example "Profession" "Level" "Biome" for villager) 2) Have many custom properties MCPREP_MatVillagerProfession MCPREP_MatVillagerLevel MCPrep_MatVillagerBiome string name under the armature object and materials.get( name) to get and use skin swap function to set the texture inside.

"Invert" mob type. How or should have an "invert" or zombified type as a checkbox? Allay -> Vex; Piglin -> Zombified Piglin; Hoglin -> Zombified Hoglin; Zombie Villager;

There are 2 questions.

The first one it is because there is a function in MCPrep that goes over select armature to get the materials. That is why I'm not sure of using it or not while we could add a properties under armature that have material name to get it quickly.

The second one is just to reduce the usage of only 2 variant switch type mobs like Squid only have a default and Glow variant, allay and vex, slime and magma is also in that.

[StandingPadAnimations]

Some code during the merging is mess up at some spot and not tested so I want to see how it should be structured from this draft.

How should it have access to the rig materials?

1. Have a for loop iterate though the objects find matching material type property MCPREP_MatType (for example "Profession" "Level" "Biome" for villager)
2. Have many custom properties MCPREP_MatVillagerProfession MCPREP_MatVillagerLevel MCPrep_MatVillagerBiome string name under the armature object and materials.get( name) to get and use skin swap function to set the texture inside.

"Invert" mob type. How or should have an "invert" or zombified type as a checkbox? Allay -> Vex; Piglin -> Zombified Piglin; Hoglin -> Zombified Hoglin; Zombie Villager;

There are 2 questions.

The first one it is because there is a function in MCPrep that goes over select armature to get the materials. That is why I'm not sure of using it or not while we could add a properties under armature that have material name to get it quickly.

The second one is just to reduce the usage of only 2 variant switch type mobs like Squid only have a default and Glow variant, allay and vex, slime and magma is also in that.

1. I think it's better to go over the materials on the selected armature. We should try to avoid adding properties to objects unless we're constantly using them (ex. needing to access something for the UI, which updates very often)
   • Assuming we're dealing with armatures, we could simply iterate through all child objects of the armature and get their materials. For the purposes of generalization, this function could be called something like get_child_materials
2. For mobs with just 2 variants, a single enum/thing to represent the 2 states might be an option, and might also make things more extensible for custom mobs. However, I'm not sure if this would make things more or less readable (I guess we'd have to try to find out)