I appreciate languages like Python and Erlang that allow you to naturally return arbitrary tuples from functions. Or that are dynamically typed so that you can just return a special error token from a function that would normally return some other type.

I'd probably go with solution 3, since another gotcha with method #1 is that there's a race window between checking and fetching the data (if the data is mutable). 

But yeah, that's true. 

Interesting bit...

if you forward declare a class, you can use a pointer.
if you don't include the header for that class, when you call delete on the object, it silently fails to run the destructor.

that had me stumped for a while... 

Be sure to enable all compiler warnings you can. It will safe you a lot of headaches. 

I made a zombie friend, that does escort the player and, as long as the player doesn't shoot it, only attacks other.

One thing that strikes me is, that when the zombie has killed a monster, it won't return to the player to follow.
It just stand with the killed corps, and as long here are no enemies, it stays there.

How do I make it follow the player again after killing?

zomby_friend 

But it will probably require some messing about to get it to work. You could drop this in a repeating function you call in the run and stand frames.

if (self.enemy.health < 0)
{
self.movetarget = "";
};

Basically, if my enemy is dead then set my movetarget (walk destination) to null, which will mean the first entity in the list - the player.

Won't follow other players in coop. 

Out of the blue to ask this perculiar thing without explaining the changed qc.
In ai.qc in Found_Target I placed this part:

/*
Zomby_friend starts fight
*/

// ------------------------------------------------
float() FindMonster =
// ------------------------------------------------
{
local entity beast;

if (self.attack_state != ESCORTING)
return FALSE;

if (self.enemy)
return FALSE;

beast = findradius(self.origin, 1500);

while(beast)
{
if ( (beast.flags & FL_MONSTER) && visible(beast) && beast != self && beast.health > 0)
self.enemy = beast;
beast = beast.chain;
}

if (!self.enemy)
return FALSE;

FoundTarget();
return TRUE;

};


So I think it's the best place, now only puzzling. 

Been a while since I've had a chance to write something up to completion, here's a write-up on the parms mechanism, after the posts in the Mapping Help thread on that topic.

http://tomeofpreach.wordpress.com/2014/12/28/sending-values-between-levels/

To necros: I think that since the article manages to compress the player data into 3 parms values, it should be feasible to use cvars to smuggle that info - scratch1-3 would be enough. So as long as you accept you aren't getting anything like half-life's transition zones that can take other entities with them, a hub system should be feasible.

I guess the other practical things are to use some of the space in the third parameter as an index to select which spawn point the player should transfer to, and working out exactly how to send the command. Probably the best way would be as a single semicolon separated string, setting the scratch variables, then a "map" command in case we haven't visited this map yet, then the "load" command to attempt to load the save game for the map in progress. Probably overlooking something but it sounds solid enough... 

oh wow, that's crazy... you are a mad genius. :)

the savegame as hub system does have some other flaws though, for example, say a fiend leaps at you as you go through a hub save/load transition. when you return to the map, that fiend will still be floating in mid air to hit you. :(

I suppose you could designate transition zones as off limits so any monster in the zone when the a hub savegame is loaded would be move away or something.

ehhh, maybe it's better to use that scripting extension that lets you read/write to text files... 

that scripting extension that lets you read/write to text files...

whoa - what's this and what engines support it? 

Preach that is an excellent post. 

I think once you accept that the monsters aren't gonna transition with you through a loading zone, you'd have to start with a recommendation to mappers that loading zones be designed to be isolated, free of items and largely inaccessible to monsters. You could enforce this somewhat on the mod side using code that runs with save game detection. When you notice that the player just loaded a saved game, findradius all the monsters near the player, and reset them back to their spawn location, optionally non-alert too.

That might be a neat idea to do with some of the further away monsters too, perhaps just the ones with patrol routes so that there's a limit to how much a sneaky player can exploit it. That would make it a bit more like Metal Gear Solid style zone transitions, which I think is a better model to have in mind than the Half-Life level continuity which is too hard to achieve. Mimicking the fade-to-black cutscene entering the loading zone and fade up on the other side would mask some of these "defensive moves"... 

http://quakewiki.org/wiki/FRIK_FILE

i don't know much about it, but i think it was used in that top-down RPG mod... which I am blanking on the name right now. 

well googling "frik file" gives me almost no more information other than that page you linked, and that Darkplaces supports it, so I'm guessing it's probably something that was supported in that one engine? 

well, yeah, in theory, any engine that supports the FRIK_FILE extension, but afaik, it's just DP.

it is a powerful system though, you could, in theory, transfer player info with a text file between savegame loading as well as use it to transfer over monsters in the trigger zone so that it behaved like half life. (although you might run into trouble if you brought over monsters that were not precached in the map originally). 

You might have to work really hard to get monsters which weren't present before loaded in the level, but I think it might be possible. The thing you have going for you is that you can notice early enough that you need to run extra precaches, as the transfer data is available on the initial frame.

The thing you have to contend with is the modelindex field in the saved game you're loading (assuming the player has already visited the level) - if you precache extra models you'll probably invalidate the existing modelindex values, especially since you'd likely have to do all of this extra precaching during worldspawn. Given the choice we would prefer to do all the precaches after the other spawn-functions, where they couldn't wreck things.

So what we'd have to do is lots of clean-up when we get our onload function running. We could start with the idea that we need to do setmodel(self, self.model) on all the entities at this stage, and then try and work out all the exceptions we need to flag. Should be possible to get that working on anything that isn't a modelindex entity hack, and you know, you can't always save that kind of thing in a mod.

I did get excited for a little bit when I thought about how much storage you'd need for a monster, and figured I could get it down to 34 bits a monster. For a second I was excited as the parms provide enough space for 9 such monsters plus a player! Then I remembered we didn't have the parms and was saddened... 

Is it possible to remove (or at least, hide) the "Saving to..." line that appears as a console message on top left of the screen which displays the full path to .sav file, by modifying the progs file? Lately I noticed that longish message distracts me greatly. 

It's something that the engine does so in general you can't modify it away from the progs. If you had game saves which were being triggered from inside the progs (like an autosave feature or a hub system thing) you could mask it by appending ";echo \n\n\n\n" to the command string, but it's a bit hacky, you're wiping the whole notification area like that and making a bit of a mess of the console log.

If you wanted to adapt your favourite engine to not do it then it's a pretty easy change. Grab the source code for the engine, open host_cmd.c and comment out the following line:

Con_Printf ("Saving game to %s...\n", name);
 

Bind your save key to "con_notifylines 0; save quick.sav; con_notifylines 4" 

Like anyone can grab the source code for an engine, pop it into an IDE and hit compile and not get a gajillion errors.

fteqccgui.exe = easy QuakeC
<insert typical IDE here> = ERRORS!! The C++ Lord laughs at you and says "You're not supposed to be here!" 

That only works in JoeQuake-like engines.

I don't think Quakespasm supports it nor FitzQuake. DarkPlaces uses "con_notify". 

@qmaster
that's more of a dependancy thingm combined with thesystem header files cahanging significantly with every single new ide version (especially between vendors).
qc just has NO dependancies - just compiler and vm. many qc mods still break to engine incompatabilities or compiler bugs. :P

@spirit
con_notifytime 0
set it back to 3 after 3 seconds have elapsed, or increase it over time.
there's a more portable solution for you. :) 

The con_notifytime 0 does appear for a split second. Probably 1 frame.

(Which is why the non-standard con_notifylines 0 is nice) 

Somewhere on func_ recently there was discussion on 20fps animation in Quake, and one of the obstacles was that the QC might cope badly with them if the engine dropped below that framerate. Here in partial answer to that problem is a blog post:

https://tomeofpreach.wordpress.com/2015/03/28/thinking-fast/

It's also me trying to rewrite a much older post I made on func_ trying to describe exactly how the Quake engine deals with time and think functions. I hope the new approach taken makes it a bit easier to understand. 

aka sv_gameplayfix_multiplethinks (exists as a cvar in both fte+dp)
vanilla quakeworld already performs multiple thinks per second if the real framerate drops too low somehow.
it'll just keep running think functions until it catches up with the actual time.
(yes, this means that really low think intervals is just wasteful).