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. 

Have there been any attempts to make a more modular/extensible qc engine? Like extending a known mod's (compiled) progs.dat with some of your own stuff (for mappers, mostly new point entities or monsters)? Is it even feasible? 

like modifying an existing mod?
or allowing modification of existing progs without source through the engine? 

Actually, that wouldn't be so bad. It would be cool if a compiler was integrated into the engine so you would just distribute qc files and when the engine starts it would compile it on the fly similar to Doom3/Quake4. 

Yeah, without modifying the existing progs. 

same as with the mapping help thread, should a link to the wiki or the coding section of the wiki be added to the start of this thread? 

Yeah, you've had enough of a rest now, time for more blogging!

http://tomeofpreach.wordpress.com/2013/04/27/text-manipulation-in-quake-part-v-coroutines/

This is the last of the heavy-lifting, high-concept bit of messing around with text in quake articles. At the end of this one all the messy stuff to do with printing text is moved into the helper functions we've defined, and code that wants to print text looks uncluttered and simple.

Future articles will just be cool things you can do with this, like how to combine this printing with conventional strings, how to compare streamed text with a quake string, printing floats to the screen, automatically creating boxes for variable text. It's gonna be fun... 

How can I get my enemies to do nothing on reaching the last path_corner?

Right now they begin walking towards the player (notarget or not) after ending the path.

I know I can just clean movetogoal or force idle instead of walk, but I'm pretty sure this has been fixed in other code bases, and by map hackery.

I've tried various ways of ending the path in editor, and nothing seems to work. 

��self.goalentity = self.movetarget = find (world, targetname,
�����other.target);
��self.ideal_yaw = vectoyaw(self.goalentity.origin - self.origin);
��if (!self.movetarget)
��{
����self.pausetime = time + 999999;
����self.th_stand ();
����return;
��}

So to get to the bit which makes the monster stop we need the find call to return world. The obvious move of not setting a target on the waypoint fails, because it's almost certain that the player's targetname is also "" (the empty string). This is why the monster instead starts walking towards the player.

So how can we make sure that find returns world instead? Well, find returns world if nothing matches. So what we do is choose a target is not equal to any targetname on the map, like "this is a made up targetname which nobody in their right mind would use".

Alternatively use Quoth and "wait" "-1".

I have to admit that before the post I had an misapprehension about find. I thought that the function looped around, so when it reached the last entity it would wrap around to world and back until it reached the start entity again. It doesn't do this - once it reach the end of the entity list it just stops and returns world. 

Thanks.

Does the player not having a null string targetname affect anything else like this?