Please copy the entirety of StudioMDL.exe's compile log for this model, and then paste it in a comment here.

Originally posted by 55 year old Zoomer:

- why would I need to flip the top mesh if the faces were not destroyed by blender in the first place? -

Because Blender by default renders the back-sides of things, while Source doesn't (and usually shouldn't).

Try to hover the mouse cursor over a 3D viewport in Blender, press N to open a side panel thing on the right, and then enable "Shading" > "Backface Culling" in it. This will cause Blender to not render the back-sides of meshes (just like Source).

Originally posted by 55 year old Zoomer:

- Reguardless of that, the textures were creating other weird effects too but nocull fixed that aswell.

What "other weird effects"? $NoCull lets the back-side of the mesh be rendered, and does not change anything else about the model or material, so any "other weird effects" really should not be affected by $NoCull (except in a few cases (such as environment cube-maps), where they're affected negatively due to not working correctly on the back-sides of things).

Originally posted by 55 year old Zoomer:

- nocull -

Again, $NoCull's only use is to allow the back-sides of things to be rendered, and there are many things which only work right on the front-sides of things, so it's (nearly) always better to duplicate and flip stuff to technically have a front-side on both sides than it is to use $NoCull.

Unless you know exactly what I mean about $NoCull and you know exactly why I'm telling you to not use it, you really should not use it. And even if you do know, you probably shouldn't want to use it, anyway.

Originally posted by Pte Jack:

- Also, negative context if the item is rippled or concave/convex in nature. -

"Negative context"?

Originally posted by Pte Jack:

- Best way to do something like this is with a solidify modifier. Front and back are aligned, - and normals face outward.

Again, the same holds true if you duplicate a mesh and use "flip normals" on the duplicate.

Originally posted by Pte Jack:

- Best way to do something like this is with a solidify modifier. - thickness -

Again, I'm specifically saying that while some thickness can be nice, I'd argue that that's more often unwanted than wanted, especially when transparent materials are involved (as then you can peek through the transparent bit into a place between the front and the back, which thus shows nothing even if it's supposed to, which can look wrong at bends/curves and such (which infinitely-thin things won't in the same way)), which the materials seem to be here.

Originally posted by Pte Jack:

- if you duplicate mesh and flip it, your reversing the faces all together. -

Please define "reversing - all together" in that context. The way that you're phrasing it makes it sound negative, so I'm not sure that you think of "flip normals" in the same way as I do.

If you use the "flip normals" function thing in Blender while in Edit Mode, it makes the selected faces swap their front-side to the back-side, both in terms of which side is the new "front" and which direction lighting is calculated from. It does not do anything besides that. This is perfect (and the exact wanted behaviour) for having a mesh display both of its sides.

Originally posted by Pte Jack:

- If you use a solidify modifier, the mesh is thickened -

As I said and explained the reasoning for, this is not always a good thing, and can often be a bad thing when transparent materials are involved.

Originally posted by Pte Jack:

- If you use a solidify modifier, - the mesh is an actual reversed mirror of the upper side and the new mesh uses the same texture.

The same holds true for duplicating a mesh and using "flip normals" on the duplicate.

Originally posted by Pte Jack:

- You might want to consider giving your mesh some thickness so the backside is actual mesh.

You don't have to give it a thickness. If you duplicate the mesh and change the duplicated mesh to face the other way (Blender calls this "flip normals"), it will render both the front- and back-sides of faces, while the model is still infinitely thin.

Note that if you give a model a thickness, the inside and the outside mesh will not line up perfectly, which allows you to see between the inside and the outside meshes. (Unless you keep the very edge either infinitely thin or with a visible edge, neither of which work that well if the model uses a transparent material where not all of the mesh is visible, which it looks to me like is the case here.)

Originally posted by 55 year old Zoomer:

I will give that a try. -

If "that" is using $NoCull in the material, please re-consider it. $NoCull causes the back-side of a mesh to be rendered... but it's still the back-side. To clarify, this means that it'll pick up lighting from the front, not the back, and display the "front" lighting on both sides. And to clarify, this means that even if you use an incredibly strong light on the back-side of it, the back-side (and also the front-side) will not show any effect of the light from the back.

Duplicating the mesh and flipping the duplicate will cause both sides to pick up lighting from their respective sides.

(Sometimes, you may want a side to pick up lighting from the opposite side... but in most cases, you probably won't want that, especially if you're uncertain of what this means.)

Originally posted by Deo3560:

The game the model goes into strictly uses SMD unfortunately, -

If it's GoldSrc, I think that it only allows 1 bone per vertice when compiled, ignoring the "multiple bone influence" stuff that Source supports, so your model won't animate quite right in-game in that case. If it's Source (or Source 2), then, as Momo asked, which specific game? Most Source games should support DMX mesh files for model compiling. (I know that it isn't necessarily GoldSrc, Source, nor Source 2, but beyond those 3 engines, I have no idea at all.)

Originally posted by Deo3560:

- unfortunately I can't use .dmx, and I really need .smd -

Out of curiousity, is there a specific reason that you can't use DMX for this?

DMX is, more or less, (near?-)objectively superiour to SMD in many ways, with the only "advantage" that SMD has (amount of bone links per vertice on a file that StudioMDL accepts) being a sidegrade rather than an upgrade (and also rendered invalid once the model is compiled using StudioMDL, anyway, as it apparently culls it down to 3 bone links per vertice if you use SMD (while simply not accepting 4+ if you use DMX)).

(If you want to use VTA flexes for the model, you can do that just as easily with DMX as you can with SMD, though in that case, it'd be better/safer to embed the flexes within the DMX than using VTA flexes. And if you want to use VTA "vertex animation", then as I said before, you can use VTA files for DMX meshes if you want to.)

Originally posted by Deo3560:

-Link- -

I don't know if this is important or not, but in the Blender session, you have vertex groups on the mesh called stuff like "Right Arm", "Right Arm", and "Right Arm.001", while the armature only has bones called stuff like "Right Arm".

This means that there are some vertex groups on the mesh for bones not present on the armature, and a few vertex groups even somehow have the same name as each other.

(So, I'm guessing that this is important, and probably related to the issues that you're having.)

Neither DMX nor SMD animation files support bone scaling. They only support translation (positional movement) and rotation. So if you've scaled bones in the animation, that won't affect the exported DMX/SMD animation file.

If you haven't used bone scaling, which I actually don't think that you have, it's possible that there might be some armature settings or modifiers that DMX/SMD format animations don't support properly/at all, causing inconsistencies with the exported product.
In this case, you may need to share the original Blender session (or another session with the same issue) for people to get a better look on it. (I'm not saying that I'll be able to help, but seeing the Blender session might be beneficial for other people.)

Originally posted by Momo:

I do believe that SMD supports the influence of maximum 3 bones per vertex. Could this be the issue here?

I don't think so. The SMD format itself theoretically supports an infinite amount of bones affecting a single vertice (although StudioMDL (the model compiler) will, from what I've heard, automatically "cull" this down to the 3 most "effective" bones when compiling the model), and both of the animation examples are within Blender while the Blender Source Tools keeps all bone weights intact when exporting mesh files.

Originally posted by Pte Jack:

- He is using Multi-$model statements for different body groups and trying load VTA files for those. I am sure this cannot be done for SMD source filed models. -

As sure as you are that it's impossible to use $Model multiple times to apply different VTA flex files to different SMD mesh files in the same model, I am equally sure that it is possible. So, not 100% certain, but over 90% certain.

Originally posted by Pte Jack:

- how do you create multi-VTA files for the object you are giving the individual flexes to? -

The way that I think that one should do that is "preferably not".

Originally posted by Pte Jack:

- Build a flex, export, delete the shapekey and rebuild the next, re-export, repeat process? -

For the Blender Source Tools plugin, probably. All I know is that the author of those multiple VTA flex files that I spoke of does not use Blender/the Blender Source Tools plugin, so it may have been easier to do this in their program of choice than it is in Blender with the Blender Source Tools plugin.

Originally posted by Pte Jack:

- All flexes built into 1 VTA is more efficient (IMO, -

That's actually objectively more efficient. As I said, a single VTA file with many flexes is much faster to compile than the same flexes when split into multiple VTA files.