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. 

I honestly wish ALL engine developer would decide on a standard way of implementing features. Like for example fog, engine detection etc. As much as it is cool that everyone wants to do different things, trying to make content that works on multiple engine is just frustrating.

I don't want to create a preferred list of engines that work with my Quake content but engine coders really are shooting themselves in to the foot over this.

I choose "pr_checkextension" because it is highlighted at the top of the dpextensions.qc file (had to download a 220mb DP mod to get the file) as something to detect DP by. Maybe LordHavoc can say which variable we should all check by. 

at least all normal engines have the same syntax but wait until you find out that the rendering of the fog itself differs... :/ 

The pr_checkextension cvar only indicates that the checkextension builtin (#99) is available, which then lets you query engine capabilities.

pr_checkextension exists in TomazQuake, DarkPlaces, FTEQW, I think FitzQuake, and I'd bet a few others too.

What I recommend adding this to defs.qc at the end:
float ext_dp_gfx_fog;

void() InitExtensions =
{
if (!cvar("pr_checkextension"))
return;
ext_dp_gfx_fog= checkextension("DP_GFX_FOG");
};

Then add this to the top of worldspawn():
InitExtensions();

Now you can check the ext_dp_gfx_fog variable at any time to see if the DP_GFX_FOG extension is supported, which describes how that fog command behaves.

This is not a general catch-all way to detect DP however as any engine can implement that extension, there is not any special way to detect a particular engine (nor any plans for one). 

Awesome, thanks for the extra information. I only plan to check for the basic DP engine from your site, I am not interested in supporting any other version.

I plan to use the following QC:

(in defs.qc)
float dpactive;
float dpextrafog;
float(string s) checkextension = #99;

(world.qc, function - worldspawn)
dpactive = cvar( "pr_checkextension" );
if (dpactive) dpextrafog = checkextension( "DP_GFX_FOG" ); 

Several attempts to agree on anything failed. You could probably still find threads from like 15 and 10 years ago... 

The other engines I listed are *not* darkplaces, they are completely unrelated popular engines written by Tomaz (TomazQuake), Spoike (FTEQW), metlslime (FitzQuake), and so on.

They support the same extension mechanism to detect capabilities, they offer different sets of capabilities but with significant overlap.

Again this is not detecting an engine, this is detecting a capability, it just happens that DP_GFX_FOG is supported only by darkplaces currently.

I checked TomazQuake 1.481, Fitzquake 0.85, and FTEQW svn 4255 (current as of this moment) and it is possible for other engines to add support for this same extension depending on the whims of their maintainers, but currently only DarkPlaces offers this extension, it was added back in 2001-04-05, been there a long long time. 

I know about the other engines (Fitz/FTE) my problem was with DP because of the fog parameters being different. I thought if I made my MOD work with Fitz it would work with anything, but it seems DP has gone in a different direction, hence the QC hack for engine detection. 

feature detection only works if the features behave identically in each engine. since they do not, there should be a way to identify engines instead. 

fitzquake does not actually support the quakec extension system. I support some extensions (e.g. worldspawn fog, worldspawn sky, entity alpha), but there's no quakec mechanism to detect them.

Most of the features I added in fitzquake are mapper-centric rather than modder-centric, which is why the extension system is missing (maps can't check it anyway, they can just add keys to entities or worldspawn and hope for the best.) 

quite some maps do come with, or require, mods, though. The line is quite blurred tbh. 

Hey guys,

Are you aware if there are any (engine or quakec) mods out there that allow the player to walk on walls / ceiling?

I'm interested as I'm thinking that MC Escher-esque architecture would be fun to map.

-Ben 

FTEQW supports that with some cvar but don't ask me which one.

There is also a map by Markus Klar I believe.