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! 

Everything has to be something.

Pushing the limits of future ideas is not something to be apologized for. Especially if you are doing it for free.

Mental exercises of the future are something anyone can do. You express these in code, something few to no one can do.

You've done it, do continue to do it and everyone sensible is inspired by it, everyone talented draws insight from your work.

Everything has to be something.

More importantly, BUT ** everything has to be something. **

DarkPlaces cannot both be an engine of the re-imagined future and a conservative engine of the past.

If you try to go there, you'll fail on both fronts and lose your identity in the process.

Everything has to be something. If DarkPlaces tries to be everything to everyone --- it is going to fail more spectacularly than any engine Quake has ever seen.

It is ok to be an engine that thinks of ONLY how things should be and never of how they are.

If you try to change that thought process, it will not lead to happiness. Your head is in the idea of a yet unwritten better future.

Give that up and it will most certainly break your heart. And make the world a worse place.

Bear the slings of arrows of re-imagining how perfect QuakeC and a perfect Quake engine might look EVEN if it breaks expectations.

Every engine author can do the conservative engine thing. This isn't why DarkPlaces is interesting. Just don't expect everyone to like "interesting" --- that isn't in human nature.

/End tl;dr post 

How did you go about your particle field controls in ITS?

I've got an emission system implemented that can throw sprites, bsps and models, but was wondering about better particle controls.

The main thing I'm wondering about is movement - I can just attach particles to an otherwise invisible emission, but was wondering what method you used, and if it'd be cheaper / better / faster.

Cheers :) 

Posted reply in ITS mod thread. If you have anymore questions let me know, will be glad to help. 

 

Is there any way to detect if DP is active from QC? Is there a function I can test exists and then supply different fog parameters?

Fitz engine fog
<density> <red> <blue> <green>

DP engine fog
<density> <red> <blue> <green> <alpha> <mindist> <maxdist> <top> <fadedepth>

I can't add the extra parameters to fitz it produces an error, while in DP the DEFAULT parameters fog out the sky. /sigh
Any ideas? 

Does anyone know of a specific DP Cvar value I can check? (I tried version but it is a string which is impossible to check) 

Found the answer, QC example below:

float dpactive;
if ( cvar( "pr_checkextension" ) ) {
dpactive = TRUE;
}
else dpactive = FALSE;