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. 

(It's really just coding post 1000, it just feels like it ok...)

New post on the blog, laying the groundwork for a series on displaying text in exciting ways. This one doesn't break any new ground, it just describes the way to display text by sending it character by character. There is some more exciting stuff in the pipeline though.

http://tomeofpreach.wordpress.com/2013/03/28/text-manipulation-in-quake-i-the-basics/

Comments, questions or solutions to the "homework" all welcome. Also is there an up-to-date mirror of the ai cafe site I can link to in the post? 

http://web.archive.org/web/20060213224157/http://www.planetquake.com/minion/index3.html 

you're probably thinking of that map "The Fly" by Markus Klar. 

doesn't nearly get mentioned enough 

Here's a second part hot on the heels of the first.

http://tomeofpreach.wordpress.com/2013/03/29/text-manipulation-in-quake-part-ii-inversion-of-control

This time we've got the exciting idea which gets around the lack of arrays in quake. We don't actually use it to do anything interesting yet...I promise that by part III the example code will produce something cool to look at. 

Here we actually get to the good stuff - how to make text appear like a split-flap board. Just need the sound effect...

http://tomeofpreach.wordpress.com/2013/03/30/text-manipulation-in-quake-part-iii-parameters/

Hopefully the potential of the system shows at this point. I remember seeing how great the end screen for Qonquer was. My hope is by the end something like a menu drawn with a border which animates to open and close is made easy. 

I just played the fly :)
it was a fun map...

I couldn't find any cvar except for wall jumping in FTEQW :( 

just had the chance to read some of your text manip articles, very awesome. I've known about this method for a while since you originally brought it up but this lays it out really well. Thanks! 

I've got loads more ideas lined up (eventually the print functions should be able to draw a box round arbitrary scrollable text) but now I'm back to work posts will be more spaced out. Part IV should be out by the end of the week, it's about creating persistent state.

Credit where it's due: I first saw this idea in Pyrdon Gate by Frikac, which needed lots of menus and dynamic text, and did it like
textout('h', 'a', 'l', 'b', 'e', 'r', 'd', 0);
There was also a phase of creating text based games-within-games in quake mods, like Tetris and Snake. So using WriteByte to build centerprints is not original with me. The function-as-iterator and the dynamic print functions are new ideas though, and I'm pretty excited about them (as you might have guessed!) 

fte features:
give self.gravitydir_z=1 (-1 or 0 to revert)
gravity will now point upwards.
give self.movetype=31 (3 to revert)
gravity will change based upon the angle of the surface below you. you can run up walls by just facing upwards and walking forwards.

they're intended to be used explicitly by mods, but you can force things with the 'give' command, and its ability in fte to poke various qc fields, but note that it only really works in single player.
The current SVN build will rotate the view along with gravity but slightly older ones won't, and this will be needed if you want to run on ceilings properly. 

Didn't Matrix Quake have wall-walking of some description? I'm sure that was why it needed a custom engine...

While I'm posting something almost helpful I might as well link to the next Text post.
http://tomeofpreach.wordpress.com/2013/04/06/text-manipulation-in-quake-part-iv-state/
I swear the next post does all the remaining heavy lifting, and the rest will just be 100 fun things to do with text on a screen.