<cat>Dev.Model</cat> <title>Citizen</title>  # Download All source files of the Citizen model come with the game. You can find them right in the game folder, under **"addons/citizen/models/citizen"**. These files are effectively always synced straight with the official sources; when new animation files are added on our end, they'll show up in that folder for you too! If you don't have access to the game yet, you can find a FBX file here: [citizen.fbx](https://files.facepunch.com/maxlebled/1b2011b1/citizen_2021-05-20.fbx) If you don't have access to the game yet, you can find the FBX file and textures here: [citizen.fbx](https://files.facepunch.com/maxlebled/1b2011b1/citizen_2021-05-20.fbx) [citizen_textures.zip](https://files.facepunch.com/Taylor/1b2011b1/citizen_textures.zip) # Creating a new player model...? Before you do anything with the sources, ask yourself: do you just want to add a new model on top of the existing animations (like in Gmod), **OR** do you want to add new animations and effectively "fork" the model? If you create a new "forked" VMDL, you'll have to keep up with any changes and updates that we make to citizen.vmdl yourself. However, if all you're trying to do is "create a new player model", in the sense of Gmod 13, that is to say, a character model that references an existing animation set, you should not "fork" citizen.vmdl! Your gamemode should instead use citizen.vmdl as is, but hide all its meshes, and then bonemerge your custom meshes on top. Think of it like bonemerging a hat in Team Fortress 2, except you're doing that with the entire body. (There's no equivalent to $includemodel for animations yet, hence this solution.) # Scale Note that the model is provided in centimeters; we've chosen to let the engine take care of scaling it down into inches. The conversion takes place using the global **ScaleAndMirror** modifier in ModelDoc. We're NOT doing it at the import level on the mesh node, though that might have been a nicer choice for a couple reasons. (The global modifier isn't actually consistently global, it's kind of weird.) So if you want to fit something onto the character as it exists in-game (compiled and all that), you should work against the source as it exists in centimeters, then in ModelDoc, you can perform the scaling down to inches either at the import level (on the mesh node), or using the global ScaleAndMirror modifier, **using a value of 0.3937.** (Only 4 decimals; this is an arbitrary choice.) You should ideally NOT be doing any scaling on your 3D app's side. # Helpers These bones are set up to be procedural helpers driven entirely by constraints configured in ModelDoc. Feel free to open up citizen.vmdl and look at the constraint folders to see what makes them tick! * arm_upper_twist_* (from shoulder to biceps) * arm_elbow_helper_* (better deformation for extreme bend angles on the elbow) * arm_lower_twist_* (from forearm to wrist) * leg_upper_twist_* (from pelvis to thigh) * leg_knee_helper_* (better deformation for extreme bend angles on the kneecap) * leg_lower_twist_* (from calf to foot) Animation data doesn't need to be exported from your 3D program for these (it's, in fact, set up to be ignored). Our own animation FBX files usually don't have them. It's just not needed! If you're making a model (e.g. clothing) to be bonemerged on top of the citizen, you don't actually *need* to skin your mesh to these bones... but it's better if you do! # IK bones These bones are used to drive IK constraints in-engine. They need animated data.  root_IK is the parent to all *_IK_target bones. These are effectively "model-space" IK targets. Why are we doing it this way? Because the position of these targets needs to be kept in a different space that won't be affected by any layers, weightlists, etc. that animation compositing is touching, otherwise we can't restore the positions through IK afterwards! Think of them as a way to keep the pos/rot data of hands and feet intact, separately. root_IK is, in the control rig, constrained to follow X and Y of the pelvis, but with Z (height) forced to 0. This Similarly, the hand/feet target bones are pos/rot constrained to their respective hand/feet bones in the control rig. Additionally, there are two special IK bones, which are an attempt at reproducing the "ikrule touch" feature from Source 1. * hand_L_to_R_ikrule (child of right hand, constrained to the left hand) * hand_R_to_L_ikrule (child of left hand, constrained to the right hand) These are used as a way to keep the position and orientation of hands the same *relative to each other*, even after applying layers, weightlists etc. and they are pos/rot constrained in the control rig.