It could also drop troops, or just do flyovers like in q2. 

Yeah, I'd never given thought to using it as an enemy but I think there's potential. You could probably adapt the skin into a Rubicon style thing fairly easy, if you rusted all the gunmetal bits brown and muddied the paint with more texture and the correct shade of green. Then it could compliment those enforcers on the hoverpads, ether as transport or gunship.

And yeah, it's possible to do Q2 style flypast animations in Quoth with one. Since func_rotate_train entities are non-solid, you can use a .mdl format external model for one and it's just a matter of creating the right path corner ents for convincing flight.

So, on to today's stuff. I posted a fair bit about it in this thread recently, so it'll come as no surprise that I'm about to post the Qexpo tutorial:
http://tomeofpreach.wordpress.com/2013/09/14/the-return-of-the-qexpo-tutorial/
Well...I've still got 4 more to type up or recreate, but the first ones are restored. Thanks again to Madfox!

And what better model to go with it than the Fusion Cannon from tutorials 3 and 4, which I finally got round to finishing off during the downtime!
http://tomeofpreach.wordpress.com/2013/09/14/fusion-cannon/ 

I'm glad you got the tutorial back up. I remember reading that way back and i learned tons from it. 

The pace is maintained, another day, another model:
http://tomeofpreach.wordpress.com/2013/09/14/blinds/

This time you can create some beautiful windows, and give the illusion that you aren't blocking vis through them. Amaze your friends with the obviously fake HDR effect they create.

Also the final four parts from the tutorial are up if you want to brush up on your animation technique or the essentials of the mdl format.
http://tomeofpreach.wordpress.com/qexpo-tutorial/ 

I posted a new version of qmdl earlier this week. It turns out the merge_vertices function is worth running even on models that have come straight out of the md3tomdl converter. I ran it on my ogre model and it went from 692 vertices to 666. Not only is that a really cool number of vertices to have, but it's a pretty good saving to make. md3tomdl follows the topology of the md3 model exactly, so I'm guessing that there are places where vertices are separated due to subtle difference in smoothing groups. Once we get down to mdl format the fine distinctions are erased, and there's no reason not to merge the vertices.

I also discovered a bug in merge_vertices - it doesn't cope with framegroups correctly. So if you are going to add framegroups, for now you need to run merge_vertices first!

No new model today, but I've gone through and updated all the old models that had weird normals created by the old version of md3tomdl. The list of updated models is at:
http://tomeofpreach.wordpress.com/2013/09/15/new-md3tomdl-qmdl-fbxtomdl-and-updated-models/
If you use any of the models in this post you should pick up the new version.

Also today sees a new version of fbxtomdl released which handles indexed skins in a simpler and more intuitive way(the same way that the helper in qmdl does). It's also got its own page now:
http://tomeofpreach.wordpress.com/qmdl/fbxtomdl 

 

Yeah, here's some more. Quite a few of the model this week have undeniably been random odds-and-ends that I just got round to polishing up and releasing. Today we've got a red-hot new model, created entirely this week.

It's a door pull mapobject for adding detail to your medieval and metal maps:
http://tomeofpreach.wordpress.com/2013/09/16/door-pull/
Nothing complicated going on, just a static model to make a plain door interesting.

On the tools front, I've got a slightly weird exclusive to func_ deal going:
http://www.quaketastic.com/files/tools/windows/model-compiler.zip

This is the little package I use to jump-start my model making. When I embark on a new model, I create a clean directory for it, and then drop these 4 files into the directory. If I export the new model with the filename "model.md3", running the batch file compiles it to a basic mdl with no other input required.

The files also have all the scaffolding needed to build the model properly as I go. For example, once I have the first skin on the go, I overwrite the "dummy" model.pcx file with it. If I need to add extra skins, there's an empty array called "skinlist" in model.py I can add the filenames to. Similarly as I add various animation to the file, I can add to the list of (name, length) pairs in the rename_frames list. I can even amend the last line of the batch file to give the model file a less generic name.

So to make use of it, you need to extract the files somewhere safe, and then make one very important change. Open the batch file and modify the first line to specify the full path to the location of your copy of md3tomdl (advanced users could instead add md3tomdl to their path). Anyway, I hope this helps someone out there get things done with a little less fuss. 

door pull model is very cool and can be very useful. i'd love to see more things like this-- subtle details that are not meant to be the center of attention; the hallmark of a good map object. 

Yeah, so I've about run out of tools and utilities to post about, but I will continue with a trickle of models to use. Today we've got a gas cylinder which I originally made for a top-down zombie shooting mod. So the idea was to try and make a model which looked interesting from above. Luckily I did skin the whole model so it can be used in 3D maps as well.
http://tomeofpreach.wordpress.com/2013/09/17/gas-cylinder/

Also, quick note on the republished vine model. Before this morning the "fixed" vine was missing the extra skins that the original came with. So you might need to re-download that one yet again... 

I have heard so much about beez.
Yet I never saw them in Quake1.
I have heard about a swarm entity,
but it is beyond my grasp.

Here I have some beez in beta state.
Thing izz... I can't kill them.
I even can't hurt them.

Help!
They hurt me, and kill me. 

any ideas for the model are welcome.
I can't loop the sound, although I ripped it with cooledit to loop mode. 

I have managed to kill the swarm. My hint is that to run your mod in fitzquake, and run the console command "r_showbboxes 1". You should then see where to aim, and it'll give you a clue what's gone wrong in your code.

Incidentally, I spotted a mismatch in the code at the moment. In the QC the pain animation is defined all the way to pain14, but the model only has 8 pain frames. This means the death animation glitches half way through. 

Can't check out what you've got there...

The RMQ swarm were distinct enemies, basically each bee was thinking in its own right. In theory with a collision they'd be kill able but this would ruin the shotguns - the code would only allow you to kill one bee of the swarm at once.... Unless you made an invisible explosion happen on the killed bee when hit by a shotgun.

You should be able to grab the swarm.qc from the RMQ SVN - it is almost completely nuclear as I remember, just needing a defs reference.

There's also a small qc maggot mod from idgames2 which could be useful, which is a micro enemy based off the Flesh Grub (I think). 

That's hillaric!
I thought I was a bad-aimer, but this cheats me.:P

Yes Preach, the bbox is out of order. It has to be in the center. The $painframe a typo.
I'm surprised I can easily walk through the bbox. That gave me the feeling I had to shoot one bee.
How does that bbox come up so left lifted?

@Ijed- always something new with that monster entity. When I started the swarm, I was afraid I couldn't make them too large because of that bbox. Now it seems it is just a tiny thing. 

Compare your line:
setsize (self, '16 16 16', '24 24 24');
to the setsize line of other monsters. 

I changed it into setsize (self, '-12 -12 -12', '12 12 12'); and that seems to work.

If the swarm gets killed the bbox hangs in the air, as the swarm is.
This looks rather odd. How come the bbox hangs in the air after the deathframes? 

check the wizard qc for this, specifically the death frames. you need to change the movetype to toss. 

Works great now!
Thanks for the advice, necros, preach, ijed.
^v^

beez 

So even though I haven't posted things on here for the past few days, I have managed to keep up "one model a day" through today. What you might have missed:

A model with the qualities necros looks for in a map object - but only useful if your map has a nautical flavour...
http://tomeofpreach.wordpress.com/2013/09/18/mooring/

On the opposite end of things, a section of river you'd need to design the whole area around, although it does have some interesting techniques to demonstrate...
http://tomeofpreach.wordpress.com/2013/09/19/rapids/

Finally, a length of bright warning tape for base maps, gimmicky but fun...
http://tomeofpreach.wordpress.com/2013/09/20/warning-tape/ 

totally downloaded the mooring. :) 

Safety first 

Can't help it.., seen too much futurama 

Maybe he's king of those robots from Rubicon 2, so he can be the boss of the level. 

Or it can be a Duke Nukem cyborg (the cigar man, the cigar !!) 

He's more an update from metroid.

I modelled it so, it can open its mouth and animate smiley's. I wanted to add the abbility of lipsync. Qmle screws a lot while importing.