ohh yeah, actually that makes way more sense.
checkclient is pretty quick since it's a built in and uses pvs. 

you'll have to filter newly awakened monsters, because they count as clients for one frame to propagate aggro through crowds, but that's simple enough. 

sounds like a pretty good solution. 

I have finished the mr.big model, a rocket jumping, and heavy weapon entity.
Looking in the hknight.qc for the magic to give the gun a "spread" fire action, and in the dog_leap routine for the rocket jump.

The heavy weapon now results in such a damage that even its own entities get killed when placed in the same surounding.
I thought there was a line of code in the ogre.qc that provided this behaviour, not killing own enemy.

Also
SV_startsound:not precached.
How to avoid it? 

SV_startsound:not precached.
you forgot to precache a sound you're using, check all the sound() function calls for any you missed.

not sure about the self damaging, that could be many things. the most obvious thing to check for me would be that you are passing the right entity for the ignore argument in t_radiusdamage. For example, usually it's self.owner, so make sure you set the missile's .owner field correctly. 

thanks necros. I did check the sounds, but strangly only the second monster's call gives the warning.

For convienence, here 's a testmap for MrBig. The qc is included. 

it's the sight sound. that's the only sound that is played outside of the monster's qc file... check ai.qc for the SightSound() method to see which sound is being played. 

Searched the qc.file, but what I find is in void() FoundTarget, what I believe as local float rsnd;.

Is that the spot for SV_StartSound<q/>? 

madfox, ogre grenades can totally kill nearby monsters, it just has such a small weak explosion compared to player explosives that it rarely ever does (dmg is 40, radius is dmg+20). It's not even strong enough to kill a zombie. 

Ah, here's where the confusion is

SV_StartSound is in the engine, don't go looking for that in the QC. The part of the message you need for debugging is where it tells you which sound wasn't precached. If you like, you can then look through the QC for that sound to find out which bit of code is trying to play it. Really though, you don't have to know who wants to play the sound, just precache it in your monster's spawn function so it stops being an error. 

@Lun - sure, but this is no ordinary ogre, it is carying an old fashion 8-loop gun and can flush a spread shot of 20 spikes within 20frames.
I lowered it to 8 on 20fr.
That's a lot of damage, see the test file.

@Preach - can't find it in the qc file, precached all sounds. It might be the player's sound is missing but that's loaded in world.qc.
Is there a console command for this tracing not precached? 

Is it possible in quakec for a client to set temp1 via a console command or alias, and have the server see that and act on it? Not having much luck so far.

I have a function that watches temp1 for change and echoes a simple message, and the call for that function is in StartFrame() in world.qc but it isn't picking anything up. 

use impulses or krimzon_sv_parseclientcommand. 

Thanks a lot. krimzon_sv_parseclientcommand is exactly what I need :) 

So in FTEQCC you can use var to make a global function pointer which can be changed, which is very cool. I was worried earlier on when poking around in the text of a save file that I couldn't actually see an entry for this variable. Now I've managed to actually hit a point where loading a save game causes a "null function" crash to console (hitting the same trigger without loading a save first worked fine).

At the moment the variable in question is storing state which can't be deduced from the rest of the world when the save game loads. This rules out a fix using the LoadGame function to repair the damage. So far I've not managed to think of a better workaround than allocating an entity and storing the function in there. Is this a fundamental limitation of the save game parser - that it's not built to read functions into globals? Is there anything smarter I can try? 

Posted that late at night, in the morning I realised that there was one thing I could test...

The test involves my favourite trick of late, editing the save game that lead to the bug in your text editor. If you add a line "default_monster_spawn" "monster_shambler", the game parses it correctly and the bug goes away. So it's not the loading of the save game that lacks the support. I'll revise my guess that it's the saving of the save game that doesn't support this... 

found in vanillaish pr_edict.c ED_WriteGlobals:
if (type != ev_string
&& type != ev_float
&& type != ev_entity)
continue;
Blame the engine. 

Well, I think I've thought of a not-terrible way to fix up the missing data when a game is saved in this particular case. Must write all this up into a blog post or something though. 

Just in time to make it so that there are blog posts for this month, a new coding article. This week: the Factory Pattern.

http://tomeofpreach.wordpress.com/2014/09/28/the-factory-pattern/

Use it to spawn clones of entities, reset your map cleanly between rounds and ...prevent map hacks? What blasphemy! 

Preach got me interested in Python so I spent time learning how it works and converted my OBJ2MAP C# utility to it. Python is probably going to be my utility language going forward - so nice to work with!

https://dl.dropboxusercontent.com/u/161473/SeptQuake/PythonVictory.jpg 

 

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.