I'll go you one better... Here's the entire project,

2 blend files - 109_original and 109 Bone Fix.
SMD and DMX exports with QC for both
Valve compiled mdl files and Valve mats

File is 57 megs...

Now, while playing with this...

The original DMX output with the problem_dmx.qc produces the spun up model...
The original SMD ouput with the problem_smd.qc produces a clean model (I did not add the VTAs to the SMD calls)

The Bonefix blend produces a clean DMX compile. (This is after renaming all the bones.)

But, I went one further and just renamed the fuse bone to bip_fuse and left the rest. The resulting compile flipped everything to normal except the prop. (The prop mesh object has the same name as the prop bone)...

I renamed the prop bone to bip_prop and just exported the prop object and recompiled. The result was the the prop flipped, except it flipped only 90 degrees and appeared in the starboard wing facing the wingtip instead of off the front of the aircraft. I had to export the entire model again to get a good DMX compile.

Anyway, if your interested in investigating, the RAR file is here... https://www.dropbox.com/s/l844qsejhfpy07n/Stuka_Rot_Prob.rar?dl=0

And thanks again for your time...

hmmm, I have never had to parent models before, I just simply added vertex groups, and an armature modifier. This model had a mesh object called fuse and the main bone was also named fuse. When using my usual method, I got the problem of the FUSE weighted objects doing the 90 degree flip. As soon as I changed the name of the main bone, everything worked properly. This only happened with DMX exports and compiles, the SMD exports compiled without problems (using my usual parenting method) which lead me to the conclusion that the DMX compile could not distinguish between the mesh and armature data types when it came to parenting using vertex groups. It defaulted to the mesh as the parent.

Now this could also be a studiomdl bug as BleST is merely a GUI into the compile process. But I thought I would report it just in case. I'll do more testing as an End User on some other models later. But for this case... The problem was solved by renaming the main bone.

Thanks for the help and for checking into it Art...

I wasn't sure if it's BleST or StudioMDL problem. I was going to do the drag and drop on to the studiomdl.bat to see if it was somethng that Studiomdl was doing, but if you have it in your court, I'll leave you at it...

Thanks Artfunkle...

Found the problem. I had 2 object that were the same name, a mesh object (named fuse) and the main bone I parented the other bones off of was named the same (fuse).

After changing the name of the main bone to something else, everything came together properly. So, this is an asummuption,

I guess the SMD compile knows the difference between the object data types and the DMX compile doesn't. (Maybe??) Might this be something to look into on your end Artfunkle??

I don't know if the same behavour occurs if the objects are named the same deeper in the hierarchy... (haven't tested)

Thanks for the help!

After doing a backward decompile of the model compiled with the DMX files I found that the armature did have some problems. There were 90 degree rotations and an animation embedded in the bones (not sure how these got there because I had completely replaced the armature but they were there.) So I'm in the process of repairing the armature and attempting again.

All objects have been to assigned to Vertex groups and weighted with a value of 1. There are no blended weights in the model. Bones control 100% of the mesh assigned to them. Each object has an armature modifier, all bones/vertex group names are correct. All objects have the location, rotation and scale coords "Applied", so rotations of objects is 0, xyz location of all objects and armature are in the same place (0,0,0) and scale for everything is 1.

Besides, if things were not set up properly, the SMDs would not compile properly.

I had originally thought that maybe some other plug in might be inteferring somehow so I renamed the appdata 2.76 repositorty, grabbed a clean vanilla copy of 2.76b from blender.org and a did clean install of BleST 2.6.2 (which is the only plug in installed other than the ones that are preloaded on clean install) . Exported the DMXs again and got the same result, so it's got to be something in the model exported DMX files themselves that just isn't clicking. The SMDs compiled perfectly again.

Well, back to the drawing board. Maybe I'll delete all vertex groups and the armature and rebuild the structure (again). I'll let you know how things work out after doing that.

https://steamhost.cn/steamcommunity_com/sharedfiles/filedetails/?id=619705440

Looking for an explaination why the DMX compile is out of whack, everything in Blender is set up and SMDs produce a perfect model from the same session? Can someone explain what is happening?

Thanks

Then I guess there's nothing to be done except inform the masses the situation exists and provide the "turn off Auto Smooth" as the the current work around. But as far as I'm concerened this is a solved situation for me.

Thanks everyone. I can carry on now.

Ok, seen... When I exported the model as a DMX Auto Smooth WAS off, however when I imported the DMX back into blender, the model came back in and Auto Smooth turned on.

Turning off Auto Smooth in the normals section of the object data panel fixed the problem. Thanks Keepon. I'll make sure to include that tidbit in my tutorial.

Well, isn't that special.... Good eye Keepon. Still not on that other computer but will check that out and report back when I do. Thanks...