I haven't touched the script. Instead, I renamed the original "lock.mdl", then copied a different model from the project, renamed the copy to "lock.mdl", then started the script.
Sometimes it crashed, sometimes it didn't.

I believe now, though I don't remember it 100% anymore, that it crashed with two models: The original "lock.mdl", as well as a different MDL5-version of it, and a model of a treasure chest that is in the game. These are the only models I've touched with MED since I've done a reinstall of Windows on this computer.
Other models, both from my projects, as well as a testmodel from the forum, did not trigger a crash*



I'm not sure I understood what you mean - I'm assuming the "lock.mdl"-model is the reason, but I've now replaced it by loading the original 3DS-data (the model was made in Wings3D), and saving that as a MDL. So the original faulty model isn't used at all anymore.



* - I've tried running the thing several times per model, since the crash only appears semi-regulary. However, at the time, it crashed every time with the models mentioned.

It can indeed be a different model that is loaded before the offending lock.mdl. The "bad format" message box appears when loading a model caused a crash. If the crash happened _after_ loading the model, the compiler can not detect it and crashes without message.

A damaged file often does not crash immediately, but leads to subsequent crashes, for instance when it is damaged in a way that loading it overwrites a wrong memory area.

Which should never happen. o.O
A loader has to verify the data or abort if suspicious, instead of pushing it into memory without control.

You're certainly right. At least as long as you don't use real existing software, such as Windows or DirectX.

Well, i suspect, the mdl(7) file is not loaded by directx, right?
So the stage of loading and validating is before pushing it to directx

Maybe such a validation could be implemented for the development version, preferably only when forced through setting a variable to non-zero (so it does not slow the loading down that much)?

YES PLEASE.

A standalone tool that checks all files in a folder would be fine, too.
(I wouldn't mind if it would only check Acknex-formats.)

Also, some kind of parameter that makes it so that Acknex writes the filenames of each file loaded into the acklog would help - if it crashes, at least we know which files to look at, then. I suppose that would be easier to add.


It is a NIGHTMARE to find this bug otherwise in bigger projects, what with its random, sporadic appearances.

Surprisingly today I get the same error ("Bad File Format") in a new project, no 200 lines of code. The message does not appear when I remove the second skin and weirdly when I do the following check:


the engine will not crash which makes zero sense to me.
I can send this project in to the support if wanted.

EDIT: No view entities, just regular ent_created objects.

All engine versions do file validation - it would make not much sense to validate files only in the development version. But as you see, this can not always prevent a crash.

If a model crashes during compiling, you can see the previously loaded models in the code. All object definitions are loaded in the order of appearance.

If you have no object definitions in your code, the crash will happen at runtime, not during compiling.

Let me emphasize this: In my case it's not a problem with a certain model or a texture (at least I'm 99.9% sure) because I just created a new model of 3 primitives, added two skins, made a new texture and it still crashes. There is only one model/ one type of models in this project.
I will now just send it to support, no matter if you want it or not.