This document describes the problems regarding the creation of a global system for working custom armors.

• What mods work with this system out-of-the-box
• How Minecraft's armors generally work
• Model Standard Proposition
  • When will an armor model get considered for Mutation?
  • Types of models

Here's a list of mods that have been tested thus far and work with the system (for the most part):

• Ice & Fire: Dragons
• Thaumcraft 6

If you happen to use another mod that has armors, and they work with Mo' Bends, please contact the staff on my ~Discord server~!

• Armors model instances are used across entities, and across body-parts.
• If we'd want some body parts to stay vanilla, and some not, we'd have to somehow show the same instance in different states in the same frame.
• We can't create another instance, since some armors are custom.

• Changing visibility between renders of the same part in a single frame.

• We assume that the amount of boxes stay constant (no new boxes are added past initialization).

• Switching between vanilla and mutated has to be completely reversible, otherwise we get wierd disapearance glitches.
• Each original part has a visibility group associated with it. That means that the visibility of each of the mutated parts is synced with the original.
• If a box has been mutated, we keep the original saved, so that when we need to swap, we swap.
• The original rotation point and rotation angles have to stay unaltered, and they have to behave as they were during vanilla, so that when we swap all the rotations and positions are consistant.

This proposition's aim is to standardise the creation of custom armors in a way where Mo' Bends can safely and easily mutate them, adding changes to fit the animated model if need be. These guidelines should be very easy for developers to implement into their mods.

Legend:

• Mutation - The act of adjusting an armor model to fit the animations of Mo' Bends. This could involve making some parts of the armor follow specific body parts, or in more drastic cases, splitting boxes in two.
• MR - An instance of the ModelRenderer class, usually representing a cluster of boxes, rotating and moving as a whole. It can also be used as an invisible pivot point, where other visible MRs can have it as a parent.
• Box - A box that has it's own texture offset and position relative to the pivot point of it's parent MR. This is what actually going to show up in-game.
• Standalone MR - An MR that's not a child of any other MR. It means that it most likely gets rendered seperate from the others.
• Child MR - An MR that is a child of another MR.
• Limb split boundary - The boundary where the upper arm/leg and the lower arm/leg would meet after splitting the limb.

The model has to be an instance of a class (let's call it the Model class) that extends the ModelBiped class. This means that by default they have the base humanoid body-parts:

• bipedBody
• bipedHead
• bipedLeftArm
• bipedRightArm
• bipedLeftLeg
• bipedRightLeg

Let's call them Original MRs.

Warning: The bipedHeadwear model is not being taken into account because it complicates the system. Please refrain from using this model part in any way.

Model renderer type	The actions Mo' Bends will perform on them
Original MRs	Any boxes attached directly to Original MRs are going to be considered for slicing. Slicing will occur only when the boxes lie on the Limb split boundary. They will automatically be moved around with the animated limbs, as they did during vanilla. Warning: Although this is pretty unlikely for mod developers to do, and I advice against it, but if any offset is applied to the boxes during the runtime of the game (post initialization), it's going to get lost and won't be reflected in Mo' Bends. If you want to move boxes individually, you have to put them in seperate MRs.
Direct children of Original MRs	MRs which are direct children of the Original MRs are going to become children of their mutated counterparts. That means that they will follow the movement of the parent limb. The rotation point and rotation angles are kept as they are (mutable during the runtime) but are now relative to the mutated counterparts they are children of.
Children-of-children and Standalone MRs	The children of the direct children of Original MRs are going to stay untouched by Mo' Bends. Same goes for MRs that are not children of Original MRs.