<cat>Dev.Model</cat> <title>Citizen</title>  The Citizen character is the default player model provided by Facepunch. # 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 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.) If you create a new "forked" VMDL, you may have keep up with any changes and updates that we make to citizen.vmdl yourself. However, this is largely automated by simply using the *.vmdl_prefab files, and do your changes right besides them: that is to say, you don't touch the contents of the prefab at all, and your new nodes go under the prefab nodes. These prefab files can be thought of as the Source 2 equivalent of .qci (QC includes) files. ⤶ This isn't the Source 1 "$includemodel" feature, but it's the next best thing available for the time being. If you don't do anything too off the beaten path, it means you'll only need to recompile your model every so often. ⤶ Now, 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. If you want to create a model that differs radically from the proportions and look of the citizens, though, it'll be up to you to provide your own skeleton, animations, and animgraph... but that's outside the scope of this page. # 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. ## Animating with the SFM There is, however, one downside to this: when you're animating the character in the SFM, you are animating on something that is already scaled. Therefore, if you try to export animation out of the SFM to be used in the VMDL, things will look very wrong because the scaling will effectively be applied twice. There is, however, one downside to this: when you're animating the character in the SFM, you are effectively animating on something that is already scaled. Therefore, if you try to export animation out of the SFM to be used in the VMDL, things will look very wrong because the scaling will effectively be applied again on that. The workaround is to create your own copy of the VMDL with the global scaling node disabled, and use that to animate. # 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! ## Animation compositing with helpers If you're using an animgraph to animate a character, it's best not to touch the helper bones at all, or to reset them to the bindPose state right before the end of the graph. However, if you're using old-school Source1-style direct sequence playback, and if you're doing any compositing (in ModelDoc), your weightlists should include the helpers when relevant. # 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. It also needs to always point forwards (zero rotation), otherwise funky things can happen. 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.