• First, plan your stuff ahead. This always helps. Make the map, or use an existing one.
• If the animation needs to match up with scenery, import the map into 3ds Max. Choose the root of the local space for your animation wisely.
• Import the actor(s) into your scene. Everything that you are going to animate is an actor. A camera is an actor.
• Once you're done animating, export the sequence SMDs separately (and properly; only the bones must be exported). Compile the MDLs.
• Make a choreography (VCD) with Faceposer. Authoring expression files for lipsync may be required.
• Play back your scene in-engine, with the help of the S.E.M.M. addon. Writing a CFG with a set of commands and exec-ing it can help a lot.
• Use the Source Recorder (not demos; they are a completely different thing), in association with SrcDemo², to render out the footage.

This section will be fleshed out later, maybe with a video. I don't know (yet).

Actor manager

actor_create	[actor name] [path to model]	Creates an actor at the specified coordinates, target, or under your crosshair.
actor_playscene	[target actor] [path to vcd]	A fail-safe wrapper for the setexpressionoverride input. Essentially the same thing, except you don't have to add /scenes/ or .vcd in the path. It also warns you of non-existing scenes!
actor_setpos	[target actor] [target entity / xyz coordinates]	Matches the coordinates of an actor to another entity (or actor). Very useful in batch commands, as you can adjust one actor, then execute a CFG to automatically match the other ones!
actor_additem	[target actor] [model to bonemerge]	Redundancy with the bonemerging script. Will give an entity name to the bonemerged model automatically! (actor name + number)
actor_removeitem	[target actor] [model / id]	Redundancy with the bonemerging script.

Bonemerging

bonemerging_help	[actor name]	Prints help to the console.
bonemerging_merge	[target model] [target entity]	Applies the EF_BONEMERGE effect.

IMView camera management

imview_toggle		Lets IMView take over the current player view.
imview_select imview_select_name	[entity name]	Select the target through which to see, either by class, entity name, or under your crosshair.
imview_attachment	[name of target attachment]	Attachment on which the view will be overriden. IMView can fall back to the entity's origin & angles.
imview_fov_toggle		Overrides the current FoV with the Z coordinate of the fov_override attachment on the target's model.
imview_fov_override	[integer value]	Offsets the FoV value given by the attachment.
imview_shake_toggle		Toggles the additive shaking effect.
imview_shake_pitch imview_shake_yaw imview_shake_roll	[positive integer values]	Intensity of the shake on rotation axises.
imview_shake_dampen	[floating point value higher than 0]	Speed of the shake. Higher is slower.
imview_tracking_select imview_tracking_select_name	[entity name]	Enables camera tracking — CANNOT BE DISABLED, WILL REQUIRE A MAP RESTART TO TOGGLE OFF! Will override the attachment's view angles.
imview_tracking_attachment	[attachment name]	Attachment to track instead of the entity's origin, e.g. "eyes".
imview_tracking_tolerance	[positive integer value]	Distance from the center of the screen from which the tracked point can move, without adjusting.
imview_tracking_damping	[positive integer value]	Speed of the camera's tracking.

Runtime depth-of-field

rmk_menu

Opens the runtime DoF menu.

Teleport

teleport_x teleport_y teleport_z	[floating point values] (range: -16384 to 16384)	Specifies position coordinates.
teleport_pitch teleport_yaw teleport_roll	[floating point values] (range: -360 to 360)	Specifies rotation coordinates.
teleport_target	[entity name]	Selects the entity to teleport.
teleport_perform		Performs the teleport. (duh!)

---

Don't forget: these scripts unleash their full potential when their commands are executed in bulk with a CFG file! Here's what I used to directly spawn the actors and preview the scene of this video; all I had to type was "exec tf_horatio" which is obviously much less of a hassle...

Let's say you have a multi-actor scene that doesn't depend on map placement — you're free to place it wherever you damn well please. You can try out different positions and angles by moving one actor (John), then using actor_setpos to quickly and easily match all the other actors to John!

actor_setpos Tom John; actor_setpos Dan John; actor_setpos camera John

actor_create medic player/cs_medic.mdl
actor_create spy player/spy_head.mdl
actor_create camera camera.mdl
actor_playscene medic tf/tf_horatio

imview_select_name camera
imview_fov_toggle
imview_fov_override 30
imview_toggle

The mystery of jittery animations

In Source engine builds prior to the Alien Swarm branch, position data in animation MDLs is encoded in 48-bit without any bells and whistles. Think of each MDL being allocated a 3D grid made of points... the numbers of points is always 65,536 for each axis. A single $sequence can stretch that grid for all the other ones. If a bone moves very very far away from the origin (let's say 20,000 units), then you'll lose precision. A $sequence that is compiled in the same MDL but doesn't go far (let's say 300 units) would have extremely poor precision.

This means that, if we assume the minimum precision you want to have is 0.2 units, your animations would need to go no further than 300 units away from the origin (in each direction of the axis).

There are two workarounds to this:

• Compile the "long-distance" animations only when needed. (which is what I personally do)
• Move all the $sequences that are susceptible to cause a major loss of precision to another MDL. An animation MDL can $includemodel another!

In Alien Swarm, the animation encoding has been changed to 64-bit, with RLE compression. That's roughly 65k times more accurate. It also results in a lot of model-related crashes, which were supposedly fixed in later games such as Counter-Strike: Global Offensive.

Reloading materials

The console command mat_reloadallmaterials will reload all materials, but it's slow. For this reason, you might want to use mat_reloadmaterial, which accepts wildcard paths!

mat_reloadmaterial models/player/scout/*

The above example will reload all materials from that folder and its sub-folders. However, there is a small trap that can make you wonder what's going on if you're not aware of it: mat_reloadmaterial will only reload materials that have been found already. So it will not get rid of missing materials. To effectively load these, you must use mat_reloadallmaterials!

I can't compile my animations: StudioMDL freezes!

You need to export only the correct bones from 3ds Max, as shown in the [insert title of future section here sorry this is wip] section.

I can't compile my animations: "write opening" error!

StudioMDL can't create new directories itself. So if you're compiling, for example, models/player/scout_animations.mdl, make sure models/player/ exists!

I decompiled this model, and...

STOP. You should never decompile a model and expect it to work properly. Valve provides some source files with the Source SDK you can find them at:

C: > Program Files (x86) > Steam > SteamApps > Your Steam username > sourcesdk_content

How should I use the source files provided by Valve?

I'd recommend you make your own copy of them in a separate directory. I have a folder in my Dropbox just for that, because the revision system is extremely useful to prevent unrecoverable mess-ups! And then, you can also delete what you don't need (in my case, the original DMX animations and the official Valve Maya rigs), so you can organize that how you want.

How did you get Faceposer working on Windows 7?

If Steam runs on your Windows machine, Faceposer will also run without any problems. The fact that it can't run on anything else than XP is an annoyingly widespread popular myth. What you can't do on anything else than XP is automated lipsync recognition. But it's not an issue, because the output of that API requires more work to fix it up than doing it from scratch, and you'll most likely be using expressions to do your lipsyncing anyway.