Alpha-masked models need a flag set in their properties. This can be done in QME 3.1.2 in the By Number tab of the Flags tab in the model properties window. You must use flag 0x00004000 (MF_HOLEY). DO NOT USE 0x40000000 as the QS readme specified.

Putting this here for reference. 

I am trying to understand the model positioning.

When I have a model.mdl that is coded to be set on
setsize (self, '-16 -16 -24', '16 16 40');
and I use a model that is in QMle on the groundplane
I see in game a model hanging in the sky.
I load the model in Quark and see that it stands on the groundplane.
When I lower it untill it is halfway down this groundplane the model appears well in game.

I'm asking this because I get some errors using selfmade models in game when using teleporters.
The most seem to teleport in the ceiling, no matter how low I place them.
Note the map uses lots of small corridors. (128) 

i don't have qME installed so i can't check, but i believe each model has a setting that puts a vertical offset on the model. Maybe it's called "eye height" or something? If you check other models like the grunt you should see it, perhaps this is something you need to set on your model. 

It's just the funny thing ID models fit well in Qmle's groundplane.
When I place my own models in Qmle they always drop down.
And only logical as it is -16 -16 -24'.
The groundplane is based on -24. 

the .mdl file has a vector field known generally as "eye position".

This vector is a bit of a red herring because it is ignored by the quake engine. However, QME does use it to offset the position of the model as seen in its viewer.

The only use of this as far as I can tell, is when you want the origin of an entity to coincide somewhat in the middle of its visual model, but you also want the model to appear offset, relative to the groundplane, when viewing in the model editor.

So for a monster, the monster entity "origin" could be in its belly for example, but in QME, instead of seeing the groundplane cutting through its belly, it uses this extra offset to raise it up just enough so that its feet are on the groundplane. 

I modelled a smashed window1_2 texture, sorry for that.
With some patience you can make your own shatters.
I could animate it, that would be a nice effect.
So far I threw in my own window. :P

shattered

download 

...that's a really impressive attention to detail. 

Inside a wall it looks great without the shatters, but with a transparant glass texture.
Also the possibilities to extend it to func_breakable, using the shatters as gibs and climb through. 

I have a model.mdl and a weapon.mdl.
Usually I can merge the weapon.mdl into the model.mdl and manage it on the right place.

This goes for models with a single sided skinfile, ie. no vertice parts behind eachother.
Result is that the weapon skin ends up aside the original skinfile. Fine.

Now I have this model that uses a skinfile without the mirror side, it uses a UV filter.
So when I try to merge the weapon.mdl the skin part splits up the original skinfile and ruins it.

With great patience I reordered the base file back to a new skinfile, but end up with a model that looses vertices.

Is there another way to add a weapon.mdl to a model.mdl? Without crunching the skinfile. 

What is the easiest way to combine the several md3 model parts together in one mdl?

md3tomdl uses a txt file for python, but its use is only one md3 file.

Me stupid donkey won't concern to export every single frame to a dxf, and then merge it into the other.
But old qmle has a way to merge only one mdl into the whole frame set.

So if I'm right I will export 180 frames of the head.mdl to dxf to import into 180 dxf files of the upper.mdl for another 180 dxf files of the lower.mdl into the converted frames of the combined head/upper single frames.
Then rearange the merged file to the already fixed model for a fitted look.
Finally I can import them all in one mdl file.
I know it sounds a bit hillarious, but by that time I think my skinfile as my patience is ruined. :P

That's because I end up with three md3 files that need to be merged into one mdl file.

I've done it once with the Q3 skeleton, but I'm wondering if there isn't a simpeler way. 

Hi Madfox. I'd say this is a task that GMAX is very suited for. With the Quake 3 bits installed I recall that it has the native ability to match up tags. Once you've merged the models in the editor & lined up the animations how you want, you can export them as a single MD3 file and use md3tomdl from there.

Blender is probably capable of doing the same things, although you'd have more manual work lining everything up there. 

Thanks for the hint, I have Gmax, but I considder it a big jump.
It gives me the same result as QMLE.
When I import a file it goes along the whole animation for hundred of frames.
I think I'm too stupid to use the manual. It all reclares on instant files of animations. So I have to take the track of starting from zero.

Also I'm a bit concerned I loose the skinfile on the way. My knowledge is rather poor and I'm so keen on old Qmle and Quark4.07.

It shouldn't be that big deal to write a script that joins these seperated md3 files?
Anyway I'm already sofar I installed Python32 to use the Qmle-v0.6. (readme says v0.5)
I thought it was the same python that comes with Quark, me fool, took me years to discover.

The Python Image Library, the Pillow fork only goes for Python2.4. Learned something again.

Here is what I wrenched out of three md3 files with QME v3.0 and Quark4.07.
It's a hell of a job and I think I lossse my relegion.
But resistance is futile.
:P 

The problem is that each step of the merging requires you to make decisions about how to perform the merge:

When you're merging the skin file, how do you want to combine the pieces into a single image? Do you want to shrink some parts down, can you rotate them to fit?

Similarly, when you're combining the animations of a torso/legs model, the two sets of animations are independent, so you need to decide if you want the idle animation or running animation for the legs to go with the firing animation from the body.

It ends up being too many decisions to handle properly in a script - there's no sensible default answer to each question. 

I've got another question that is rather obvious.

I made a tessla coil with a lightning bold instruction on
classname info_notnull
use CastLightning
enemy 1

When I made the map in 2013 everything went well.
Now I want to use this static entity again, but I'm left with a dark line that seems to be a changed lightning bold.

I tried the same mapfile in the pack, used different older compilers and engines but the results stay the same dark line in stead of a bright bold.
Strange enough the bsp in the pack gives a bright one. 

• The lightning bolt models are progs/bolt.mdl, progs/bolt2.mdl and progs/bolt3.mdl. I think that shambler lightning uses the first one. Look in your mod directory and check you don't have a modified version of the model anywhere

• Test different engines and see if they have the same problem or not 

After compiling a new map with the components and using it in a fresh dirctory everything works fine.
My progs directory has got deluted somehow.
Thanks for the advice.

I tried Blender for the modelling part but this engine is so clumsy for a newbee. But it's free so I shouldn't complain.
Gmax has its efforts, but I'm stuck on the export extentions *.gmax and *.P3D. I might as well use Max3d-r4, although I can only work with it on win98. 

To export to MD3 you need the "Tempest" add-on pack installed. Once you have that in place, you can install a better MD3 exporter than the default, but one step at a time... 

Also posted on discord, I did not want to forget about this place. I've had a few people ask me about foliage, so I've posted this model pack with 3 pine tree models. All use alpha-masked skins.

Models:
https://i.imgur.com/uptT7Gc.png

In game preview:
https://i.imgur.com/RXmrcbH.gifv

Download:
http://www.quaketastic.com/files/models/pinetree_set.zip

The zip includes a short readme on how to setup the animation frames if you desire and some lighting tips. (Note in Trenchbroom because of the way interpolation works, the skin will have 'pink' pixels unless you render in Nearest interpolation. In game the skin will be masked properly by the engine.) 

Looks incredible especially animated. Thanks for sharing. 

Thx a lot!! 

Makes me to reconvert my Q1Treez with transparant layers. 

nice additions! 

I hope these get put to good use :) 

Is there any reason to not go crazy using models? Any performance or other technical issues? Redfield's trees led me down the rabbit hole of Quake models plus I've been wanting to make use of foliage for a while now.