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? 

There's a single central function which handles how all entities get triggered - and that has a check for an empty target before it runs. The trigger_teleport_touch function also searches for a target, but the trigger_teleport spawn function throws an error if target is not set. Note that you could use a map-hack to get around the latter check, but it's a fairly useless effect. 

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).

...oh my god... all these years, I just assumed that that functionality was broken! that's why I added the wait -1 into quoth! I never saw the correlation between find matching an empty string.

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.

This is also important to remember if you are using find when starting in the middle of the list. You need to remember to loop back around to the start of the list to cover all the entities you've missed by starting in the middle. 

So a new article for the blog, this time dealing with map hacks. I look at why one dodgy-looking part of a common map-hack technique is actually not so dodgy. It's also a chance to look at how floating point works. It's deceptively titled "Infinite ammo"
http://tomeofpreach.wordpress.com/2013/05/10/infinite-ammo/

For some more interesting reading on the issues of floating point maths I recommend Raymond Chan's recent post http://blogs.msdn.com/b/oldnewthing/archive/2013/05/08/10416823.aspx 

For what it's worth, I've published my demo parsing code (a c library) at github:

git clone http://github.com/mandelmassa/libdemo

Libdemo passes my test suite on x86 win32 and linux, arm, and mips, so it's theoretically endian safe. It should support standard and Fitzquake protocols but there has been minimal testing on fitz. I will accept patches but I'm new to github so I don't know for sure how it works. License is MIT - basically, do what you want with the code. I hope someone finds it useful.

The purpose of the code is to read a Quake .dem file from your file system into a linked list in memory. You can edit the linked list as you wish, and then use functions in the library to write the demo data to a file.

I've used older versions of this code to write numerous tools for Quake demo editing, mainly for QdQ movies. 

Can I give nextthink a value of (time + FALSE); ? 

in qc (and c), 0 is false and all other numbers are true, so time + FALSE just means time + 0 or just time.
You can do this and it means that the think function will run on the very next frame. 

On a normal entity you can do that, and even stuff like nextthink = 0.05 works as well. As long as nextthink is positive and before the server time + the current frame length, the function runs.

But since this comes after your posts about func_train, I'm guessing you want to do this on a MOVETYPE_PUSH/SOLID_BSP entity. The rules are much more complicated for them, you can read some of the detail from earlier in the thread:
http://celephais.net/board/view_thread.php?id=60097&start=325&end=354

The most important thing is to always do self.think = self.ltime + delta, never compare to time directly, or you won't get the correct behaviour when your entity is blocked. delta must be strictly greater than zero, or the think function won't run.

If you need reliable, frame by frame functions to run on your MOVETYPE_PUSH entities, I'd recommend adding a function to startframe which finds all the relevant entities by classname and run your function on them there. You get the added bonus of getting to run the "think" function before they get physics run this frame.