Originally posted by Satanism's Nanochips:

Simple but i need to ask, is there a reason why the models are huge when importing ? -

Source models are just huge.
The default 1x1x1 cube in Blender might look the same size as a 64x64x64 block in the Source engine (due to Blender's camera being very close to the cube by default), but it's only a 64th as big on all axes.
A player model can easily be 70-80 units tall in the Source engine, whereas you might only make it 1.8 units tall in Blender if you'd treat units as metres.

Originally posted by Satanism's Nanochips:

- it keeps it wrong size when exporting to FBX -

What does "wrong" size mean, exactly? And what are you trying to export it for (the Source engine, another game engine, ...?)?

For Source 1, there's a difference between a "flex" (shape key) and a "flex controller" (the slider/input in Source Filmmaker/Garry's Mod/other games).
You can then use "advanced" DMX flexes to give a "flex controller" (the "name" in the flex definitions) a different name than its "flex" (the "rawControlNames").

With this, you can name a shape key as "Left-Example" and "Right-Example", then do something like this in the flex definitions......and then Source Filmmaker will treat it as a single stereo flex.


I'm not proposing this as a "fix", just a "workaround", and I don't know if it works this way in Source 2.

Originally posted by Living Linguini:

<!-- dmx encoding keyvalues2 1 format model 1 --> "DmElement" { "name" "string" "root" "exportTags" "DmElement" { [Snipped to keep the quote short] }

If you didn't mis-copy this, then you're missing the closing bracket of "DmElement"; you have two "{"s, but only one "}".

Originally posted by Pte Jack:

-When I import both are going to be the same and it will be based on the first model imported-

The generated materials won't be "based" on anything. The Blender Source Tools only imports material names, not material settings or textures (since only the name is stored in DMX/SMD files).

Originally posted by Pte Jack:

- AFAIC model materials should be as unique as the rest of the model -

I repeat my previous point:

In Team Fortress 2, the Scout's legs are a different body-group from the rest of his body, but use the same material. In this instance, would you want the legs to have a separate material from the body, with the name changed to fit? Not at all.

The Blender Source Tools can't know whether you're importing an extra part of an imported character (where it should use the same material), or importing a brand-new character (where it should make new materials).



ZeqMacaw suggests having a new import setting for what to do with "duplicate" materials, which is a fine solution. But if a toggleable option is not going to happen, I wouldn't want "make new materials with numbers at the end" to be the thing that happens instead.

It's not a Blender Source Tools bug nor a Blender bug. That's completely intentional.

Think of it this way: If you import the Scout's body and then import the Scout's legs body-group, would you want the latter to use "scout_red.001" instead of "scout_red" when the body already uses that material?
No, chances are, you probably want to use the same material on both things. That's what StudioMDL does, too.

So how should it tell that two same-named eye materials should be different when two same-named body materials shouldn't?

Originally posted by Pte Jack:

- All Objects except materials get appended names (.001, .002 etc) -

You can't(/aren't supposed to) have two objects with the same name, and importing multiple meshes into the same object is bad too, so adding ".001" is necessary to avoid conflicts here.

But again, for materials, you probably/usually want to use the same material on both things, so it just doesn't make a new material like it makes new objects.

Originally posted by Cookie Mobster:

I noticed there were some options in hlmv for assigning sounds to frames of animation, anyone figure out how to do that?

You can use animation events on given frames of a sequence/animation. Some of the events can play sounds, which you can then place on whichever frame(s) you want.

Originally posted by Cookie Mobster:

- Do you know if there's a way to make collision boxes that follow the skeleton, like the characters? -

No, I don't. I usually deal with Source Filmmaker where collision doesn't really matter/exist in the first place, but from what I know/think/assume, you can't have moving physics on a single model if it's not in a ragdoll state.
I could be wrong, of course, but I don't think that it really works the way that you want, I'm afraid.

Originally posted by Cookie Mobster:

- vertex animation (which $boneflexdriver depends on). -

I don't think that $BoneFlexDriver needs multi-frame vertex animation; that's just the main case where it's usually useful to have, so hence the Valve Developer Community wiki mentioning it.

While I don't know for sure, I assume that you could just input the name of any flex controller that you want it to control.

Originally posted by Cookie Mobster:

- Also, is there a way to automatically create a collision mesh based on the bones? -

Not that I know of.

Originally posted by Cookie Mobster:

- it's like the bones have zero ability to move or shrink/grow like they did in Blender. -

Bones can move and rotate in compiled Source animations, but not scale.

If scaling is very important, though, you could either add more bones (e.g. the left, right, and front of both jaws) to move apart from each other, or you could add a shape key/flex for scaling, and use $BoneFlexDriver to add a bone that you can animate to control the flex value throughout the animation.

Please upload and link to the SMD file here (unless it's 18+ or otherwise not allowed), so that we can see exactly what's in the file.