Do you mean Qmle or Max3d?

Here's a new version of my Granito monster.
The first one was rather blocky.

http://members.home.nl/gimli/granito.gif 

still need many fixes but is looking great! 

feels like asking how to learn riding a bike,
and then say don't use the bike. Start walking.

But the bike keeps crashing, mostly because it has bent wheels, no handlebars and a loose chain. Under those circumstances anyone would recommend you try walking!

I don't make the model with Qmle, I'm glad I can import them into Qmle with 3DS files. This goes with an animation programm which is more specificated. I have to change the export to one patch per polygon.
And as it only goes with squads, all triangles get doubled.

Yes! The point at which you start importing the frames into qme is the point where the problems arise. This is what I'm driving at. You can avoid that problem by creating an mdl with all the frames in first, and then open it in qme.

I'm not saying it's impossible to make a model importing it frame by frame in qme. But if you import frame 1 into QMe, then change the original model, then try to import frame 2 from it, then it's very likely to fail. The import system from QMe just isn't designed well enough to do that(if indeed such a thing could be made).

The only reliable method is to re-export all the frames from the latest version of the model, and import them into a fresh qme file. Since then you need to scale them all, reimport the texture each time, etc - EVERY TIME the source model changes, it becomes a huge hassle. But if you stick with just QMe for the conversion, it's what you must do. 

this has bit me in the ass twice, once a few years ago, and then it happened again until i realized what was going on:

If you are modelling something like a laser or fireball or something, the temptation is to just fill the entire skin with the color or pattern that you want to use as a texture. The problem is, glquake and most variants will flood fill black into whatever color is in the top left corner of your skin. So if your blue laser has blue all the way to the corner, that blue will turn black and you will be saying WTF when you see it in the engine.

Fix: for solid-colored skins, put a single black pixel (or other un-used color) in the top left corner. 

Trinca, thanks, but explain me the need of fixes.

Preach, don't care my foolish waistblam, it was just the first thing that came up to me. Being modelling so long on my own way made me more curious to other ways.

Hassling the first frame is because I want to have a good skin.bmp
When the basemodel is imported it can be on different sides. At that point my model is already done. So I can import them as one load, and the only problem I reach is some verticemeshes. The way I described it was somehow confusing. My fault.

Something else got my attention in trying to avoid the mirrored texture.
When I delete a triangle in Qml and add a new one the original count gets different. This seems odd as logically this shouldn't be so.
After that I can't add frames to the original.
But when the model is full of frames, these changes don't seem to bother. 

The reason why you can change triangles like that is because the first frame you import to qme is given special treatment.

When the first frame is loaded, the program loads the triangles and the vertices. The vertices are assigned numbers as they are loaded, and the triangles are recorded as sets of three numbers, each number corresponding to one of the triangle's vertices.

For all the subsequent frames, the triangle information is entirely ignored. All QMe does is load the first vertex from the file, and move vertex 1 to it's location, then load the next one, and so on. The list of triangles from the existing model is always used. You could import a frame from an entirely different model, as long as it had the same number of vertices.

The obvious danger is that your modelling program might not always export the vertices in the same order, particularly if you change the model somehow between two exports. This is how triangles can start to go astray. There's no way to control this kind of thing, which is why the import process can get frustrating. As far as the exporting 3d package is concerned, one ordering of the vertices is as good as another. But for the import, it's the only important thing! 

You could import a frame from an entirely different model

This reminds me to the moment I had the last death frame of granito,
and used the expand function in Milkshape to make all polyhedrons
wide out as an explosion.
It took me quiet some time to make sure I had the right count.
The frame imported the well, but when I closed qmle and reopened the old death frame came back again.

So it are the vertice count that need to match, not the triangles? 

In my search to new monsters I'm fixed upon the need of some danger in Quake waters. Only the hartbreaking code part stopped me from doing. This doesn't avoided me to try and I came up with this creature.

In Quake defs it outranges the limits as it goes up to 507 verts and 957 triangles. But I still see it appear in Quake so my greatest concern is to have it good skinned.

http://members.home.nl/gimli/frogman.gif 

;] 

 

I restarted the frogman again because the base frame had a bad texture error. By doing so I got messed up with vertice errors that went so far that now on my x-th frame I became a little nerd.

I wondered. If I look at the dragon.mdl of DOE it seems they have cut the whole monster flat on the texture frame. If I look at my base frame I get the picture of the monster front and back. If I cut the monster into pieces (sure, one day) Qmle gives me the well known error: vertices and triangles are not the same.

How do they do it? 

found it. it has something to do with cheating qmle import and export abbilty's.
yes, this makes the texturing a lot more acurate. 

I plunged myself adding a new weapon in Quake1 and have come to the point I could compare it with the SuperNailgun. I added an arrow and add it to this weapon. Sofar sogood.

Then my perfektionistic habbits turned up and thought: how can I make this arrow fall to the ground instead of vanishing in space?

I'll stop because I want it's velocity not as fast as 1000 and I want it replaced by the axe and... so how make I fall it against a wall and it lies there for say a few seconds?

And post with content so here I go...
http://members.home.nl/gimli/cross.zip 

i did this for my stake gun a while back.

essentially, you're going to go into the projectile touch function and get rid of the the lines calling remove(self) or SUB_Remove().

now, it's a matter of changing the movetype, so where the remove lines were, you put it self.movetype = MOVETYPE_BOUNCE.

now, you don't want the thing to stay there forever, so we're gonna put SUB_Remove() back in, but in a different way.
put in self.nextthink = time + 4 and under that self.think = SUB_Remove. this will get rid of it 4 seconds after it hits.

finally, you can add in some extra stuff like making it spin around randomly with setting self.avelocity to some random values or you could spawn a TE_GUNSHOT for sparks or something else. 

necros, I will try it out.

But I was thinking, what if the arrow doesn't hit a wall but a monster?
Then it should disappear immediate. 

you're quite right.

luckily, it's very easy to do so.

simply make a check:

if (other.flags & FL_MONSTER)
remove(self);

this will check if other (whatever it hit) is a monster, and if so, remove itself. 

Look in the RQ code for nails. 

apparently you can have skin groups on models. o.o 

Yeah, I discovered that when fooling around with my model editor. Some cool stuff could be done like blinking lights on enforcer suits and blinking, glowing eyes on monsters. 

Animated monster and weapon skins. You remember the 'talking' skins in Seal of Nehahra? 

 

I renewed the download with my additions.

Although I altered the weapons.qc with your advice on #22 the arrow seems to stick in the wall and slightly turn to left untill it meets the corner. Then it disappears.
I also added the grenade tumble but it doesn't append.

I only had one time it started raining arrows.
You can cheque it on the same download. 

you put all the stuff in the if statement that checks if it hits sky, that's why. 

It was the first calling remove(self) in arrow_touch I came to.
I didn't realize it had to be the second one on the end of the script.

It's working well now, thanks! 

But shouldn't just adding 'nextthink X' and leaving SUB_remove have this work?

The projectiles would still do damage while waiting to be removed, but not if their touch was changed / removed.

Argh. The definition of complex - lots of simple.