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; 

 

 

In theory other engines might implement checkextension at some point, so you should probably be testing for features in darkplaces, rather than for darkplaces itself. It's like "feature detection" as opposed to "browser detection" in web design - that IE analogy is working overtime today (which I'd like to add was too unfair on DP, especially given how responsive LordHavoc has been to our needs!)

I've wanted for a while to be able to detect .alpha support on engines, to create entities which fall back to safer models on engines without it. At the moment it would only be darkplaces which gets the alpha-supported version, which makes the feature a bit too niche. 

Can't get more DPish than that, I suppose.