http://imgs.xkcd.com/comics/ballmer_peak.png 

https://www.youtube.com/watch?v=wvsboPUjrGc 

It can sometimes feel convoluted to communicate with CSQC and the server, sending entity data back and forth. I'm going to summarize some things here to help people out, but also so that I can help myself learn about them. When you can teach something, you understand it and have to learn more about it than those you teach.
There are currently three methods that I'm aware of to send data to CSQC:
Console variables, AddStats, and CSQC_Ent_Update

There are currently these methods that I'm aware of to send data from CSQC to the server:
Console variables, SV_ParseClientCommand

Console variables seems fairly straightforward. Advantages: Able to be keymapped, Able to be accessed by the player via the console or config file, simple to code, two way street
Disadvantage: Able to be accessed by the player (cheats!), Only useful for a single variable (floats, strings, vectors)

AddStats is basically the same as a console variable but only visible to CSQC, and automatically updated whenever the variable in server QC is changed. This is great for ammo and health since these are simple float values.
Advantages: Simple to code, auto-updating
Disadvantages: Only useful for a single variable, One-way sending of data to CSQC (CSQC can't change it, only read it)

SV_ParseClientCommand is a beautiful thing. This function is what is called anytime someone types in text into the console and hits [ENTER]. CSQC can call it by using a localcmd ("cmd ",yourvariable.here,yourvariable.here2,"n"); You can actually override all cheats by having void (string cmd) SV_ParseClientCommand = {/*clientcommand(self, cmd);*/};, (note the /**/ commenting out the important part, if you forgot to add this line at the end of your client command function, you may be wondering why all your cheats aren't working...oops! learned that the hard way)
Advantages: Powerful and can be used to send multiple data variables at once from CSQC to server QC
Disadvantages: A bit complicated to set up, one-way from CSQC to server QC.

Finally, CSQC_Ent_Update is the most confusing one of all, but potentially the most powerful way to send data to CSQC. Updating an entity requires the server entity to have float() .SendEntity function that is called by the engine everytime that entity's .Version field is changed. Typically, like this: entity.Version++; The SendEntity function needs to WriteByte (or String or whatever) for each variable it sends. This needs to match each ReadByte (or Readwhatever) in the CSQC_Ent_Update function.
Advantages: Powerful, can send multiple variables at once to CSQC (practically sending an entire entity to CSQC)
Disadvantages: Complicated, confusing, easy to break or make buggy.

The most confusing thing for me is that CSQC_Ent_Update is called...um...shoot. I dunno when it's called. Immediately when the entity's .Version is modified in server QC, i.e. mid-frame? at the end of the server frame does the engine check all entity's versions and then call CSQC_Ent_Updates sequentially? Is Darkplaces's implementation different than FTEQW's?

What is the order anyways? In one frame, is server code carried out first, then CSQC code? Or CSQC first?

Who knows...CSQC isn't that popular so the all the basic concepts for it communicates with QC isn't defined anywherer in so explicit an article. There are snippets here and there but no one place has all the data. Hopefully this brief summary can help someone. 

A couple of things to note.
1: .Version is outdated, you shouldn't use it, instead set self.SendFlags |= 1; or whatever and the engine will tell you what flags were set since the client last received a copy of the entity.
2: CSQC_Ent_Update is called 'whenever'. There is no specific time documented because an update can be lost or queued. Network latency is also a factor. If you depend upon ordering then you loose. If the entity gets removed in ssqc before the message was sent (due to packetloss triggering constant resends) then it can be lost entirely, otherwise packetloss will merely trigger a resend. Not every version is guarenteed to be sent, the server sends when it knows there's something pending and when it feels like it. It has lower latency than reliable messages (as it doesn't depend upon previous reliables to be acked first), but does not guarentee anything but the most recent update (like stats).
3: it is possible to send messages directly to csqc. either via temp entities (dp), or via svc 83 (fte, must be multicast). Beware of illegible server messages, you can try sv_csqcdebug in fte to diagnose these, assuming they're caused by QC.
4: fte has a sendevent builtin that can send csqc->ssqc messages.
5: deltalisten(fte) or getentity(dp or fte) can be used to read various bits of an entity without needing special sending/parsing.
6: using cvars to send stuff to csqc is horrible, and is impossible for csqc->ssqc (no server exploits please).
7: csqc can directly parse centerprints(CSQC_Parse_CenterPrint), stuffcmds(CSQC_Parse_StuffCmd), or sprints/bprints(CSQC_Parse_Print). its the equivelent to SV_ParseClientCommand, but the the other way around. 

Now if someone had time to update: http://quakewiki.org/wiki/EXT_CSQC#Sending_Data_to_the_Client

:) Maybe when I'm finished with my project in a couple months I'll update that page. 

in c++

So, in java, you might do something like this:

class Foo
{
��int a;
��int b;
��Foo(int x)
��{
����a = x;
����b = x;
��}
}

Foo getFoo(boolean z)
{
��if (z)
����return Foo(5);
��else
����return null;
}

So you'd get a pointer to a new Foo object or not depending on the argument z.��This is nice.

But what about in c++?��The Foo class is tiny, and it would be best to return it by value.��But if we wanted to return null, this isn't possible anymore.

Is the only solution to that really this:

bool getFoo(boolean z, Foo& f)
{
��if (z)
��{
����f = Foo(5)
����return true;
��}
��else
��{
����return false;
��}
} 

granted, you could return pointers to new objects on the heap, but then you've got to delete them after which is a pain. 

I shall preface this with a quote by Tony Hoare:

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Don't abuse null as a special return value indicating that nothing could be returned. It's really bad style (I do it all the time though because it's easy - go figure).

There are several ways to avoid null in this scenario:

1. Provide a method that checks whether a result will be available before you invoke your get method. There is a name for this idiom, but I can't remember it right now. It's basically like this:


bool canFoo(int x);
Foo getFoo(int x);


In getFoo, write an assertion that canFoo is true to detect bugs in debug mode.

However, this has the disadvantage that any logic that determines whether a return value is available may have to be executed twice: Once in canFoo and once in getFoo when the value is computed.

2) Create a default instance of Foo that is always returned when no value is available. This instance might even be able to behave in a sensible way, maybe displaying an error message when some of its methods are called.

3) Return a std::pair<boolean, Foo> where the first element indicates whether a result was available or not. This is basically the same as returning NULL from the method when you use pointers, but it makes the calling code a bit uglier because the syntax to access the elements of std::pair is a bit awkward. I sometimes write my own wrappers instead of std::pair for this.

Personally, I will use of these options in the order I presented them, so 3 is a catch-all that I'll use if 1 and 2 are not feasible. In either case, you put the burden of checking whether a result exists on the caller, but that's no worse than using NULL.

Side note: Some languages such as LUA allow you to return more than one value from a function. I consider this the best solution because you can write something along the lines of


bool valid, Foo foo = bar.getFoo(5);
if (valid) { ... }
 

I notice you didn't have my own suggestion in your list above... Is there something wrong with passing a reference that you will store the actual result in to the function? I figure, as long as you're careful with your const declarations, there shouldn't be any danger of accidentally mangling anything important. 

And I try to avoid them where I can. That's why. Also if you know that your Foo need not be changed, you should make it const, but you can't with your approach because getFoo cannot take a const reference. 

Ah ok, I would use it more for short live temporary things anyway.

Something you'd create on the stack before calling the method, then read what you got back if the method returned true (and ignore it if it was false).

using a pair seems like the least hacky and most efficient way of doing it otherwise.

method #2 means you either need dummy values which you need to know mean the object is garbage or you need to include a boolean value into the class that you can check to see if the data is good or not, but that boolean may not always be relevant.

method #1 is good, but you might be doing a check twice, or some steps needed to check in canFoo() might be used to do the work in getFoo() so at the least you can be repeating some steps.

Anyway, thanks for your input. I am starting to really warm to this language! 

I am a total const nazi. Every variable / parameter that can be const, should be. The same goes for member functions. This is the best feature that C++ has over Java, in my opinion. I would really suggest that you become a const nazi too, because it leads to cleaner code if you give some thought about whether a function can have side effects or not, and functions without side effects are much safer!

You're right about option #2 - it's seldomly applicable, but when it is, it works very well and leads to cleaner code because the caller doesn't have to worry about whether the return value is valid or not. 

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.