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. 

That's what I was looking for!

I didn't see the ai_charge. I kept changing the ai and fight.qc with the loop result.

Thanks for your clear explanation, after a few days I thought the orb could only crash. 

Darkplaces is the Internet Explorer of custom engines - it has features that nobody else offers, but creates awkward incompatibilities at the same time. Today's bugbear: it changes findradius so that non-solid entities are included in the search results. This makes it possible to create invisible ghost monsters in Quoth with a rocket in the wrong place... 

yeah, i don't try to support it anymore. just too many things broken. 

The one you want to disable in this case is sv_gameplayfix_blowupfallenzombies 

Is there a cvar that says don't do anything present or future which messes with the QC? It wasn't hard to tweak the code to work around this - the cost is in spending the time testing in darkplaces for bugs that don't occur elsewhere, reproducing them reliably and working out what the engine does differently. I'd add "sv_gameplayfix_optout 1" to quake.rc in an instant. 

I have no plans for an "optout" cvar because it's like taking a sledgehammer to a nail, it isn't the right solution to the problem.

The right solution to the problem is one where users don't have to do anything.

I'm still evaluating the right solution. 

Is there a QC compiler that supports arrays? 

fteqcc!

http://fteqw.com/wiki/index.php?title=FTEQCC_FAQ 

fteqcc!

http://fteqw.com/wiki/index.php?title=FTEQCC_FAQ 

Yes, it's great :) 

@Spirit, I am using that already, thanks :) 

I am trying to make an object look directly at another object. I want the v_angle/mangle (Pitch/Yaw/Roll) but I can't work out how to get them.

I know about vectoyaw:
dir_float = vectoyaw(destination.origin - source.origin)
This returns the Yaw angle, but I want the Pitch angle as well.
Any clues? 

For some reason the pitch is reversed. I got the following to work but not sure why the pitch needs to be fixed.

vector vec = destination.origin - source.origin;
vector vec_dir = vectoangles (vec);
vec_dir_x = 360 - vec_dir_x; 

Which maps, mods, or demos use all or most of the fitzquake protocol features? I've added fitzquake support to my demo parsing code and would like to exercise it a bit for the sake of quality. 

Posted a new build of DarkPlaces today with sv_gameplay fix cvars off by default (the disruptive ones, anyway), and some bugfixes for hipnotic (hip2m3 now completable) and other maps.

I have fitzquake protocol support in the works but not the time to finish it right now, I don't understand why fitzquake uses a protocol different than the QUAKEDP protocol that it clearly borrowed several bits of code from... 

thank you very much!