There are two fixes that I can think of.

The first is to triangulate before splitting shapes into separate objects, but that's a bad idea as it can lead to drastic changes to the output (e.g. per-face dupligroups).

The other is to recombine all of the shape objects to one mesh after triangulation, then split them off into separate objects again. That should work, but would make exports considerably slower. Given that this is an edge case in a legacy export format, I'm not happy about that prospect. I may experiment with it and see how bad the slowdown is though...

This isn't going to be an easy fix at all. The issue appears to be that the triangulation operator gives one result when two faces are connected in a convex manner and another when the connection is concave. That is exactly the change that the shape you're trying to export makes.

This also explains why DMX is unaffected: it supports ngons, so no triangulation is performed.

So yeah, use DMX! :)

You need to use a more recent version of Blender.

DMX is required for several of the Source engine's newer facial animation features. It's also faster to export and compile, particularly if your model is very large and has lots of flex shapes.

If you're making simple props you won't notice any difference.

Only the name of the material is exported. The Mdl file is the output of compiling your exported files with Studiomdl, which as Vintage points out can be automated via one of the panels in Scene Properties.

I've discovered that the order of vertex loops can differ between the original mesh and the baked copy of the shape. Try this download[steamreview.org] and see if it fixes anything.

Your two findings above are expected. Not calculating the normals leads to them all being (0,0,0), and the mismatched verts are common with VTA. Use DMX!

I'm unlikely to have the time to do this in the near future. Give it your best shot. :)

If you need help navigating DMX files try my desktop editor, DMXPad[github.com]. It's a bit wonky in places but it does have a massively useful file comparison feature.

In terms of the formats, they are very similar. Here's the spec for the basic studiomdl format; anything SFM does ought to be a layer on top of that.

The problems you're seeing are where SFM's DMX animation format differs from studiomdl's. There's no reason why these features can't be added, but I haven't done it (yet) because 1) SFM import is a relatively obscure thing to do and 2) there is potential for confusion:

• If export is supported, when a user exports a file with SFM data and naively tries to compile it with studiomdl.
  
• If export isn't supported, whet a user imports a SFM animation and tries to export it again.

In both cases the SFM data is lost and the best I can do about it is provide spammy warnings that the user may not understand nor even read.

I think the best solution is to implement SFM import/export as a different operator from studiomdl import/export, and perhaps even a different addon. This new operator would invoke the Source Tools and then do its own SFM-specific work afterwards. How does that sound to you?

(I just remembered that there is a third SFM-only feature: bezeier handles on each keyframe. The importer currently ignores them, and the exporter bakes them into extra keyframes. That's another feature that could be implemented.)

You don't need to open the zip file. Follow the installation instructions on the download page.

https://developer.valvesoftware.com/wiki/Blender_SMD_Tools_Help#Exporting