Originally posted by Pte Jack:

- If you don't know if a QC can use multiple $model statements, how can you say a SMD can use multiple VTAs? -

By, from own experience, finding out that using a single FlexFile statement in $Model is much, much faster than using 20+ FlexFile statements in $Model.

(Most modern My Little Pony: Friendship is Magic pony models actually use one VTA file per flex, although with "stereo" flexes having both the left and right flexes being in the same VTA file... but still, one VTA file per wanted flex.)

Originally posted by Pte Jack:

The thing is, SMD only support 1 VTA file. -

This is wrong. In fact, a single SMD can use multiple VTA flex files if it wants to.

I also think that, though I don't know for certain if, you can use multiple $Model statements for the same QC file, allowing you to use VTA flexes for multiple SMDs(/DMXes, although DMX flexes are preferred there). Yes, VTA flexes are unuseable for body-groups, but they can be used as much as you want for non-grouped body parts (until you hit hard flex amount limits, but that applies to DMX flexes too).

Originally posted by TheManOfButtons:

- $modelname "D:\art\hlmodels\knightblue.mdl" -

$ModelName is, again, relative to the root "models" folder.

For example, if you have $ModelName set to "player/scout.mdl" and compile the model for Source Filmmaker, it will, by default on a 64-bit operating system, be at C:\Program Files (x86)\
\Steam\steamapps\common\SourceFilmmaker\game\[folder]\models\player\scout.[extension]

(Yes, Source Filmmaker is a Source thing while you're working on a GoldSrc thing... but still, $ModelName is a relative thing in Source, and I don't think that that's different for GoldSrc.)

So that $ModelName is not a valid $ModelName, as the only time that a ":" can be in a Windows file-path is directly after the drive letter at the start, while if you start $ModelName with "D:", that "D:" is not a drive, but is instead still relative to some other folder, causing that ":" to make the file-path not Windows-compatible.

Originally posted by TheManOfButtons:

- $cliptextures -

This is $ClipTextures, but it should be $ClipToTextures (or $cliptotextures) instead.

Originally posted by TheManOfButtons:

- $bodygroup "studio"
{
studio "knightblue"
} -

Again, this would (subjectively) be better written as......as that's functionally equivalent while only a single line (thusly filling a lot less in the QC file).

(For GoldSrc, you may have to use $body if $Body doesn't work. I'm not sure, though.)

Originally posted by TheManOfButtons:

- $externaltextures -

The page that Pte Jack linked to in comment #24 of this thread explains that that's supposed to be used for optimization... but that said optimization doesn't do much benefit anymore, and that that command should preferably be avoided nowadays.

Originally posted by TheManOfButtons:

- $texturegroup "skinfamilies"
{
{ "knightblue.bmp" }
} -

There's no reason to use $TextureGroup if you don't add a second skin to the model. (Additionally, the page that Pte Jack linked to in comment #24 of this thread says that, in place of where you currently have "skinfamilies", the SMD mesh's file-name should be used instead. I'm not sure if that's correct or not, but it's worth mentioning.)

Originally posted by TheManOfButtons:

- // Created by Crowbar 0.51.0.0 -

You don't have the latest version of Crowbar. The latest version is 0.56, not 0.51. You might want to get the latest version from the description of the Steam group that Pte Jack linked to in comment #8 of this thread. (Not that it really matters that much, but it's usually a good idea to use up-to-date versions of stuff.)

Originally posted by TheManOfButtons:

- Is there a guide out there witch explains what these commands do? -

Perhaps. See the Category:QC Commands page of the VALVe Developer Community wiki for links to most QC commands. Of course, some of them only work with Source, not GoldSrc, but still.

Anyway, of the things in that QC file:
$ModelName is the file-path and -name of the compiled model, relative to the "root" of the models folder. (I'm not quite sure how this works for GoldSrc, but it works that way for Source.)
$CD is for the directory of which to load SMD and other such files from when compiling the model. For Source, this defaults to where the QC file is. For GoldSrc, I don't know if it has a default, but if you just leave it set to ".", it'll be the folder that the QC file is in, too.
$CDTexture and $ClipToTextures seem to be related to turning BMP files into GoldSrc textures when compiling a model. These functions are not available for Source, though, and I've never made anything for GoldSrc, so I have no idea how this works.
$Scale changes the size of imported SMD files and such (but not VTA files; not for Source, at least). For Source, this defaults to 1.0 (which means 100% size). I don't know if it has a default for GoldSrc, so just leave it set to 1.0 in the QC file. It should be set before loading any SMD files or such (unless you're okay with the default, if there is a default).
$BodyGroup allows you to swap out any listed option with any other listed option in the same group. For example, Team Fortress 2's Engineer uses this for his right forearm, with his main body not having the right forearm, and with a bodygroup for just the right forearm, with the first(/default) option being his normal right forearm and orange/yellow glove, the second option being his Gunslinger weapon (mechanical hand), and the third option being invisible (used for arm-covering other things, like certain cosmetics and the Short Circuit weapon). I personally highly recommend using $Body instead of $BodyGroup if you don't want changeable options, as......is functionally equivalent to......while the latter is (subjectively) much clearer and easier to read, only filling a single line instead of 4 lines.
$Flags is presumably for setting some flags on the model. For example, in Source, whether a texture repeats or "stretches" if UV mapping goes outside the texture is determined by "flags" that are set in the texture. (As far as I'm aware,) $Flags is not a command in Source, however, so I don't know what impact it has on a model. I don't even know if $Flags is for the model itself or for its textures.
$CBox and $BBox have something to do with collisions. (Not ragdoll physics collisions.)
$Sequence is for adding a sequence to a model. In Source, a model must have at least 1 sequence to be compileable, so I think that the same probably holds true for GoldSrc. One can often use one of the mesh SMD files for $Sequence in Source, so I also think that that's the same for GoldSrc. (A sequence is an animation... although in Source, $Animation is for advaned sequence stuff, so calling a sequence an "animation" may be confusing, even if it's correct.) A sequence (and an animation) doesn't have to be animated. It can be static if you don't want the model to do anything special.

Edit: $HBox is for hit-boxes (which are the things that "hitscan" weapons and such can hit). I forgot to mention that when writing this comment at first.

Originally posted by GoblinCrusher:

I've gotten the eye controllers working properly on one of my models, with the exception of one last step: the view target. I couldn't figure out a solution from the threads I found on the subject. As far as I understand, it's this line in the QC that controls the starting positon of the view target: $eyeposition 0 0 70 -

It's not. $EyePosition is only for AI stuff, as in enemies in games and such, as in completely irrelevant for Source Filmmaker and stuff like that.

You can't set the default viewTarget bone location for a model in Source Filmmaker. It spawns that high and that much in front of the model, whether you like it or not. The closest that you can get probably just involves using the "localViewTargetFactor" slider within Source Filmmaker or such, making the model simply ignore that bone.


Edit: Technically, you can make the viewTarget bone in Source Filmmaker appear in the right location relative to the model by default, but as that involves simply just making the model itself bigger to make the model fit the viewTarget's default rather than the other way around, that's probably not what you'd like to do.

Originally posted by GoblinCrusher:

- I also was under the impression that the eyes had to be exported separately. -

Unless you know exactly what you're doing, all eyes actually have to be part of the same mesh file. And unless you have a reason for it, you also shouldn't split eyes away from the head mesh file in the first place.

Originally posted by GoblinCrusher:

- - D:\Users\Alfred\Desktop\LetsTryBlender\DMX\Pao Pao.dmx - 66 flexes -

Originally posted by GoblinCrusher:

- $model "Body" "Pao Pao.dmx"
-
$model "body" "Pao Pao.dmx" { - }

If I understand this correctly, "Pao Pao.dmx" has 66 flex controllers, and you load "Pao Pao.dmx" twice in the QC file, which loads the 66 flex controllers twice. 66 x 2 = 132, and 132 is more than the allowed 128.

It's generally not a good idea to have a model that loads the same DMX or SMD file as visible 3D mesh more than once in a QC file (your issue here is one of the reasons for that).

What happens if you try to compile a model that only consists of the "Pao Pao.dmx" file, with no other mesh files being loaded?

Originally posted by GoblinCrusher:

- Stereo Flexes -

Keep in mind that a stereo flex uses two flex controllers. One called "right_[controller]" and one called "left_[controller]". So if you have 66 shape keys for a model that are all set up to be stereo flexes, that adds up to 132 flex controllers, which is more than the 128 that StudioMDL.exe says is the maximum allowed amount.

Originally posted by Momo:

There Is a way to import VTFs and VMTs in Blender with the help of a few surprisingly unheard of addon: -Link- -

"Surprisingly unheard of" indeed. Actually searching for "Blender VTF plugin" or such simply shows results about "it's not worth making such a plugin, just use VTFEdit to convert it to PNG".

No. Source uses VTF-format textures, and there doesn't seem to be a Blender plugin that imports VTFs into Blender. And if it could, Blender would have to find the VMT material files of the model (which are typically very far from the QC/DMX/SMD files), look for $BaseTexture in the VMTs, and load the VTFs specified by $BaseTexture (which are sometimes not even in the same directory as the VMTs). Even then, what about VMTs that use special options, like the Refract shader or completely overriding $BaseTexture with $Detail?

So no, even with a VTF import plugin, it's simply not possible to automatically do this with the Cycles renderer, Eevee renderer, nor "Blender" renderer, unless you're okay with Blender Source Tools looking through every single folder on your computer until it finds what it's looking for, making it possibly take hours to import a model.