That looks similar to making lightmaps in doom3.

I guess the compiler would need to both export the lightmap as a texture AND output uv information for the bsp faces being mapped?

I don't know how likely someone can do that for q1... 

Looks very similar to what you could do in ut2k3, making entire levels out of meshes that were pre-lit in Max/Maya.

crappy screenshot

Was a gorgeous effect if used properly, fantastic lighting and such (on the environment at least), given that ut2k3 didn't have any kind of light bounce and meshes were purely vertex lit... problem was building an entire map in Max was a bastard :( 

Yeah, that was the same thing for d3. I found building maps in max to be much easier too, because you could make complex shapes much more easily and utilize the scripting capabilities to quickly build stuff. 

Do models have their own centre point that Quake somehow reads?

I'm trying to swap models and my enemy is getting stuff stuck in the floor. I set the bbox manually, but it seems to get confused depending on when I make the walkmove! check.

Might be better off just setting model to null until it needs to be alive and using a .entity for the other version. 

There's an 'eye plane' or something like that, but AFAIK it's just some helper that Qme included and didn't actually do anything. 

There is an origin on quake models. You need to have the model's feet 24 units below the model origin in order for it to line up with the ground. 

Need to throw more DropToFloor experiments at it.

What's 24 units in normal dimensions? I googled a bit and this: http://www.gamers.org/dEngine/quake/QDP/QPrimer.html

Tells me it's 72cm...

Feel like I should know all this stuff, but its the first time I've had this problem - or maybe just the first time I've noticed since I'm mixing legacy with new assets in the same monster. 

The engine bounding box plays a role in determining the position of the model as well.
eg: '-16 -16 0' '16 16 64' is not the same as '-16 -16 -24' '16 16 40' 

That's probably it then - I've been getting odd behaviour and after the previous problem tried changing the order of where I was defining the box / changing the model asset.

Sure enough, things got free that weren't stuck before.

Weird how it was done. Especially using imperial measurements. 

hold on... i might be wrong on my last post... it's been a while since i've messed with models and bboxes too. :S 

Well, I'm going to be redoing the mesh from scratch anyway, but want to get something lashed together in the code for now anyway.

So will have to experiment and see what works.

FYI it's based off that model you sent me some time ago, although I've modified it pretty heavily into something else now, next step being an updated mesh... 

Thanks for the help :) 

How do I get a flyer to prefer to be higher than the standard 'eye level' fly height?

Searching around, it seems that movetogoal is the answer, but this is in the C code apparently and I want to stick to qc.

I don't exactly want a B0b vertical dodge - although that could be useful as well for when it's in hunt mode. 

Look at rubicon 2 source, I have a hard-coded min and max altitude that can easily be changed. The trick is using an invisible dummy entity as .enemy to trick movetogoal into seeking the desired altitude. 

That's how i've done it too. Here's my implementation: http://mobile.sheridanc.on.ca/~jonescor/temp/ne_q2hover(01.09.13).qc 

Thanks guys. 

Lots of useful stuff to learn from.

Insightful to see two different implementations that work with slightly different approaches. 

Oh no, another blog post. If you're using the hipnotic rotating entities, you might want to go grab this fix...

http://tomeofpreach.wordpress.com/2013/01/18/sub_normalizeangles-bug-squashed/ 

Thank you! 

did you have an old version of hipnotic? mine already had that fix in. 

I was working on Quoth when I noticed it, so that might have been out of date. 

I'm puzzled about monster behaviour.

After setting the qc for self.th_stand, self.th_walk and self.th_run, self.th_pain and self.th_die I'm left with the self.th_melee and self.th_missile.

As long as I take the "SUB_NULL" everything goes fine, except the monster can't attack.
As soon as I give these parms a function the game returns them as

ai:CHeckAnyAttack
fight:CheckAttack
monster:monster_atk1
stack overflow.

Maybe it is my wrong assumption a monster can be added with only changing the monster's qc and leaving the ai and fight.qc aside.
Earlier I added monster with the enforcer.qc and there were no console messages.

I know I have to change things in ai.qc and fight.qc, as I did by adding a CheckAnyAttack in ai.qc and a CheckAttack in fight.qc.

Still the compiler sees no wrong but in game the console hangs on stack overflow. 

Stack overflow often comes from two functions calling each other in a loop that cannot be escaped. CheckAttack will run any function you put in th_missile or th_melee. If monster_atk1 calls CheckAttack, then the QC just goes back and forward between the two. The fix is to make sure that you don't call CheckAttack in monster_atk1.

What can make it harder is that you might not run CheckAttack directly - you might run ai_run which runs CheckAnyAttack which runs CheckAttack. So post exactly what your monster_atk1 does and we can see how to break the loop... 

The qc is a bit long so you find it here
As i started to make changes to the ai.qc with the CheckAnyAttack and the fight.qc with CheckAttack, I tried again with a cleansource.
Proqcc asks where def.qc 699 exp ; found
Ftecqc responds with no error, but on console

The idea was a quake1 Orb, that has a melee missile attack and a jump function like the demonfiend. 

It's a good exercise to try and write a self-contained monster, which only calls the ai functions but doesn't alter them at all. It's also better for making a monster that "feels" like the originals. So stay strong, let's fix the file.

You are calling ai_run in all your attack functions, which isn't always the best plan. The problem with ai_run is that it looks like "this is the function I call to move n steps forward". It's actually more like "this is the function to look for something new to do, and run forward if I can't find anything".

So ai_run is looking for something better to do than just run, and it tries to attack. When it decides it can attack, it runs orb_jump1 to get the attack started. Then trouble: orb_jump1 calls ai_run again! So ai_run looks for something better to do that it was doing, and decides to attack...

...and the loop goes on until you crash.

If you look at demon.qc, you'll see that it doesn't use ai_run anywhere in the attack functions. When it needs to move, it uses ai_charge instead. There are other ways to get round the problem, but replacing ai_run with ai_charge in your attacks is a simple fix to start with.