- Getting the models
- Filling out forms
- Batch script
- VPK and steampipe
- Common QC commands
- Common Errors
Part 1: Getting modelsDecompiling a model isn't hard, but to start off, you'll need to files to decompile first, if you've downloaded a model replacement mod, you'll already have these files and you don't need GCFScape (see next paragraph), otherwise you'll need to know the locations of the GCF or VPK archives.
If you've downloaded a mod, you can look through the files of the archive until you'll stumble upon a set of files with the extensions
.phy, Several of these are required to decompile a model, for the sake of simplicity it's safe to say it's easier to just use them all (if you're missing
.dx90.vtx and rename the extension appropriately). Unpack them to someplace easy to find if they're still trapped in their archive, take note of their location (i.e. copy the directory path) afterwards, you're going to need it for step 2.
If you don't have the models, which is the case for editing default models, open the GCF/VPK archive with GCFScape. GCF archives are in your
steamapps folder, if you can't find a
models folder, try a different archive, if you can't find what you're looking for (being the case for Team Fortress 2 more often than not) try thinking outside the box or search the tree systematically; VPK archives are in
common[game][game abbreviation], you'll want to open
[game abbreviation]_pak_dir.vpk most of the time, the others are usually seemingly empty.
Select the files with the extensions
.phy and put them in a folder (preferably a folder on your desktop, but not directly on your desktop, if you don't have
.dx90.vtx and rename the extension to make it fit), open the folder and take note/copy the directory path for the next step, or don't if you're using crowbar.
Filling out formsTime to fire up any of the decompilers, any will do. Depending on whether you jumped here wanting to use Cannonfodder
s decompilers Steam File Access, this next bit is going to be very easy.
If you're using crowbar, filling out both the boxes are as simple as dragging the
.mdl file onto anywhere in the program window or even
crowbar.exe, it'll fill out the directories for you and you merely have to decide whether you want to put the decompiled thing into a separate sub-folder of their own, if you're not using crowbar, read the next paragraph.
Now that you've got the directory path on your clipboard, it's time to fill out the forms; in the
Choose Model File textbox, paste what you have and add the name of the file you want to decompile (
[modelname].mdl, remember the extension or it won't work), in the
Choose Output Directory, you could choose for a different folder, but you've got this nice folder already, it'd be a shame to let it go to waste, so paste the same path again.
ExtractionClick extract or decompile. If everything's going alright, it should work without a hitch and you now have decompiled model files, along with a
.qc file, and some animation(s) file(s) and a physmodel SMD; check the destination folder if that really is the case, even in the event of a crash, it could produce some or all output.
If you don't have everything, try a different decompiler, preferably with a different destination folder so as to not overwrite stuff that did end up okay. If it's asking for a specific
.vtx file, copy one you have and make it be the one it needs. If that doesn't work, you may need to hack the file to work.
.mdl file into submission is really not as hard as it sounds, but you do need a hex editor. Open the
.mdl file with your hex editor; you'll notice the first thing it says is "IDST", ignore that and change the next character from
,, Hooch' decompiler doesn't require you to change
,, but it can't do
1. Save it and try again.
When using this program for a steampipe/common games, make sure you have the tools for the game (i.e. proper SDK tools), then point the Orange Box tools to
common[game]\bin, since following the readme file will only cause sorrow and confusion. It doesn't matter where you put GUIStudioMDL.exe, and every time you want to compile for a different game, you have to redirect the OB path because the OB path is stored in your registry. If you still get an error because the compiler can't find
gameinfo.txt, copy the one found in
common[game][game abbreviation] to
Most people will be using this program for compiling models back into
.vvd files, and in all likelihood, so will several others. The first thing you notice when opening the program is a lot of things that have no importance to you and can safely be ignored. So on to the good stuff; go to
Config on the top bar, depending on the game you're going to compile for take either "set EP1 tools path" or "set Orange Box tools path", figuring out which games uses what is real easy, only Black Mesa and a handful of other old mods use EP1, every single other game uses Orange Box.
Once one is clicked, search through the tree for
orangebox\bin. Now it's time to add games (if there aren't any yet), click on the
add in the center of the window and look for the
gameinfo.txt file, this is in
your name\gamename\abbreviated gamename (an example would be
steamapps/common/left 4 dead 2/left4dead2), it is there a file called
gameinfo.txt lies the program yearns for.
Now go to
File in the top bar and do "load QC file..." and search for your QC file, or not. A different way to use this program is to make a shortcut (on your desktop for example) and drag the QC file to the shortcut instead, that'll open GUIStudioMDL with the QC file loaded. All you then have to do is choose the SDK version, then select the right game, then hit the compile button.
Batch script compilerA second way that's faster is through the use of a
.bat file, or a Windows batch script. Open notepad (or something alike) and paste this in it:
"C:\Program Files (x86)\Steam\steamapps\common\sourceSDK\bin\orangebox\bin\studiomdl.exe" -game "C:\Program Files (x86)\Steam\steamapps\[name]\[game]\[game abbreviation]" %1
pauseAlternatively for Steampipe/common games
"C:\Program Files (x86)\Steam\steamapps\common\[game]\bin\studiomdl.exe" -game "C:\Program Files (x86)\Steam\steamapps\common\[game]\[game abbreviation]" %1
To use this properly, replace
[game abbreviation] with the proper names, if you're on a 32-bit windows machine, remove the (x86) bit, if you installed Steam elsewhere, go ahead and change that too. The pause statement makes the script wait for input before ending execution, which is useful for finding errors if you have them. After you've saved in the same folder as your
compiler.bat or something, simply double-click it and let the magic happen. After you're done with it, you can put it in a different folder where you can use it again for quick recycling.
%1 part means you can drop your
.qc file onto your
.bat and it'll take it as argument, alternatively you can rename that bit to match your
.qc, in case you want to compile a batch of
.qc files. Also make sure it's for the right engine, as it is now it'll use the game's tools, so if you're getting jiggy with an older mod, use ep1 instead, use source2006 for BMS, you can get these by downloading the proper SDK Base from the tools section of your library.
CrowbarTo decompile with Crowbar, drag the
.qc file into the window or onto
crowbar.exe. you'll probably have to set up your games first, in the boxes you see after choosing
setup games, you need to put the paths to
gameinfo.txt in the first one and to
studiomdl.exe in the second, these are usually in
C:\Program Files (x86)\Steam\steamapps\common[game name][game abbreviation]\ganeinfo.txt and
C:\Program Files (x86)\Steam\steamapps\common[game name]\bin\studiomdl.exe respectively.
The 3D model editor program Blender, along with the proper plug-ins (it's included in the SMD/DMX I/O plug-in), can also compile any model directly, which is useful for making fine adjustments to the model directly when something wrong's been spotted in the model viewer. First you enter an
Engine Path, which is
C:\Program Files (x86)\Steam\steamapps\common[game name]\bin, in the event of mods, that game name is
SourceSDK\bin[mod engine], in the end it should point to the folder containing a
resourcecompiler.exe for Source 2. After that you have to give it a game to compile for, for base games this path is usually
C:\Program Files (x86)\Steam\steamapps\common[game name][game abbreviation], which is the directory containing a
gameinfo.txt file; for mods this is instead in
C:\Program Files (x86)\Steam\steamapps\sourcemods[game name][game abbreviation]. Now it's time to feed a QC file, which can be relative to the
.blend, then you can compile. it's more of a front-end, which means you'll have to export the model yourself first before change can be noticed, but this button is just a few pixels away.
Wallworm for 3DSMax
for 3DSMax users, there's WallWorm, a nifty tool that will compile your model without having to do much of anything except having the model itself; it creates a QC file and the textures for you.
VPK and steampipeSome games are due to be relocated from your named folder to the
steamapps\common folder, this could cause some stuff to not function directly after compile. Instead, they must be placed in
[game name][game abbreviation]\custom\sensible name you write yourself, this can be done before compile time by modifying the QC
$modelname directory path as shown below.
Alternatively, you can turn it into an add-on by turning the folder you so aptly named something sensible into a
.vpk archive of its own, this can be done by simply dropping that folder into
vpk.exe, this program is in
[game name]\bin, after which you can safely delete the folder.
Common QC commands
$modelname: the name of the model itself, starts relative to
root/models and must end with
.mdl (remember that the custom folder in your
custom folder is also a root).
- A neat trick will make you compile directly in a custom folder where applicable, namely by prepending the path with
..\custom[mod folder name]\models; the
.. bit tells the compiler "Go up a folder", which is
root, from there it goes into the custom folder.
- $model/$body: the name of the mesh and the
.smd that contains it in that order; models with facial animations require $model, for $staticprop models $body is recommended.
- $cd: changes the directory where the
.smd files are, one is usually given during decompile, but if you place the
.qc in the same folder as all source files, this can and should be removed.
- $cdmaterials: the directory where the
.vmt files are to be found by the model, starts relative to
root\materials and shouldn't contain the actual material name as those are already stored in the
.smd files themselves; more can be added if need be.
- $sequence/$animation: animations your mesh might have, every model needs at least one. $animation is more extended, though they can be used in conjunction.
- $collisionmodel: contains the collision data, a simplified mesh that represents the boundaries of where the model can touch the world/another prop. Can contain several options enclosed in curly-brackets, the most common of which is
$mass, which are used for models with holes and props that can be pushed respectively.
- $texturegroup: for models with multiple skins, most extensively used in Team Fortress 2 for team coloring (tutorial here), but can be used for any prop that'll have a different look and even for replacing a model by hiding one mesh and showing another.
bbox set errorThis means the
mdldecompiler.qc file came across a
$hbox statement that doesn't comply with the model, namely the bone it's referring to doesn't exist in the model. To fix it, simply remove the offending line, the compiler usually states which bone to pick.
animationsEspecially for Team Fortress 2, animations can be completely broken on default
v_model weapons during decompile and sometimes there's not much you can do about the animations themselves to make a quick fix, but there is a possibility that there is.
Open the offending animation with your favorite plain-text editor and look for values at around 1000 or above (or -1000 and below), take note of the bone number that's affected (the first number of the line, it's usually the root bone causing this) and look for another line with nominal numbers (usually around 0) at the same bone, if you can't find any, use a different animation file, if you can't find any in those, it's probably faster to simply ignore the animations and remove them, you won't be needing them for the next best thing.
The next best thing is to edit the
mdldecompile.qc file to make use of the original animations, this theoretically gives better results than the method above, but will clutter your folders with dependency files. If you haven't already, open the
mdldecompiler.qc file, remove every line mentioning
$animation with extreme prejudice and put in their stead the following:
Change the path to where you want it to be, it's usually best to make this the same as where you put your end result, change the name to something sensible, such as what you put in
_anims after it.
To make this work you'll need to do some more stuff after compiling, namely get a copy of the
.mdl file you decompiled (i.e. has the animations), append the name of the file with
_anims and put it in the same folder as your final
.mdl. it's important to note this can be done after compiling since
$includemodel doesn't actually include the model during compiling but rather make a dependency on that file existing.
For CS:S (and maybe some others too) it could happen your gun will be invisible when doing this, it's not actually gone, just rotated. To fix this, add a
rotate 90 statement in every
$sequence anywhere after the
.smd; if that still doesn't work try -90 instead.
Access ViolationsThis could literally be anything, but it's always something in your QC file; try removing lines one by one to see which one is the cause.
Q_AppendSlash cannot be found in vstdlib.dllInstall your decompiler properly, read the readme, if your decompiler isn't in
sourcesdk\bin\ep1\bin, try putting it there; if that doesn't work, launch the SDK.