@Spike: Nice! New version has some nice bug fixes (like not being able to minimize a fullscreen window).

The new version though is giving me a bunch of similar wierd warnings though:

client.qc:761: warning F307: type mismatch: void() to void(entity attacker, float damage) entity.th_pain

It's this line in client.qc under
void () PutClientInServer = {
...
...
self.th_pain = player_pain;
...
...
}

Uh...what?
Since when did assigning a function to a .func need a type to match?

Anyways, compiles nicely. Also, I think it's a tad bit faster. 

Functions not matching field types quickly leads to functions being called with the wrong number of paramters. Please see:

http://www.celephais.net/board/view_thread.php?id=1&start=23053&end=23102

...and...

http://www.celephais.net/board/view_thread.php?id=60398&start=185&end=200

...for the kind of fucking-awful-to-debug issues that this warning protects you from.

Now, in one direction you're probably quite safe: if you assign functions without parameters to fields which expect parameters then the engine is doing benign busy-work for no good reason. On the other hand, assigning functions with parameters to fields which aren't going to set them will send you to bug city in entirely unpredictable ways. 

> Since when did assigning a function to a .func need a type to match?

Since people tried stuff like:
string(.void(),float,string) ohnoeswtf;
void() foo =
{
self.th_pain = ohnoeswtf;
};

you get the idea... 

I had no idea that could happen Preach. That makes so much sense now. I suppose the only reason the PARMs don't get 'scrubbed' was to be more optimized? Anyways I'll definitely check these warnings out now. 

The warning lies in the original code's usage of the th_pain function. Calls to a th_pain without sending any arguments (e.g. void () player_pain... ) are generating warnings all over the place in untouched progs.dat vs 1.06. Attempting to correct this by making all instances of a pain function include "(entity attacker, float damage)" as per defs.qc's definition would still generate some warnings, for instance in the case of func_door_secret assigning .use to the pain function for shootable secrets.

Perhaps a future update could suppress these particular instances. Just FYI, I don't know how yall are ignoring these warnings, they're kinda annoying. Anyways, I'll try to ignore them. 

They are the more difficult ones to fix. I can see one way to do it, but I'm still deciding if this the best way to go about it. Keep the fd_secret_use function as it is, but create a new function as follows:

void(entity attacker, float damage) fd_secret_pain =
{
fd_secret_use();
}

This certainly fixes the warning, although it is using an extra stack frame to resolve a benign warning. In the secret door case you could get rid of the need for a pain function if you made the health of the door 1, so it dies to every attach. However, I've had the same problem on monsters which I can't afford to rewrite in that way. 

Should be able to cast it.
self.th_pain = (void(entity,float))fd_secret_use;

Essentually an 'I know, now please shut up' option. 

What's the difference between checking other.takedamage and other.health in a projectile touch function?

When a monster dies, there's a short period when it's still solid. Hitting it while it's in such condition is pretty much like hitting a regular wall. It's very hard to notice in normal circumstances, but I have a weapon that shoots ricocheting nails, and on more than one occasion nails bounced from dying monsters right into my face.

Laser touch function in hipnotic QC uses other.health rather than other.takedamage to detect a damageable entity. I tried that and it helped. What I don't understand is why. 

cthon has health (3 on hard, woo) but is not shootable.
monsters that have been killed will have a lingering <1 health value, despite no longer being shootable.
if you're paranoid about players doing exactly enough damage to drop a monster to 0 health exactly, then you might want to test for a longering th_die instead. 

Thanks. I think I'll just add an additional check for a classname (Chthon shouldn't really bleed from a nail) and call it a day. 

Monsters become DAMAGE_NO in Killed(), but each monster has 'self.solid = SOLID_NOT' somewhere a couple frames into each death anim.

You could check 'self.flags & FL_MONSTER' in your nail ricochet touch. 

I went with FL_MONSTER check after takedamage check returns false. Thanks for replies! 

I promised last week I'd put up an attempt to explain the way the origin key works for brush-based entities. Here's that post:

http://tomeofpreach.wordpress.com/2014/06/18/origin-of-the-entities/

Coming up next: using a nosave variable to (among other things) detect when the engine loads a saved game and run some custom QC. 

Here's the guide to using nosave to create a LoadGame function that runs only when the player loads a saved game.

http://tomeofpreach.wordpress.com/2014/06/19/save-game-detection/

Also bonus content on how you can create CheckExtension friendly code which allows for cross-engine save file compatibility (hint: it uses nosave again, that's the theme of the blog...) 

the noload feature:
float _foo;
will be saved, but not loaded. works with any qcc. this quirk may be useful if you wish to write the extensions the saved game previously expected, for debugging, without causing any issues later. 

So it's like the counterpart to the "private fields" trick, which creates a field mappers can't set on your entities by naming the field with a leading underscore... 

Quoth for instance uses it to sort out the screen tints for the custom powerups, restore stuffcmds the mapper has applied, and warn you if you load an incompatible save from an earlier version of the mod.

Really?

I've spent a long time thrashing around in qc trying to figure out how to do all of those things.

A big thank you, once again, for keeping the Quoth source closed, so that nobody can learn anything from it until revealed years later on Preach's blog. 

Got it working, but I had to use "nosave float" and not "float nosave" like your post says. This is with the latest fteqcc downloaded from the super-secret triptohell moodles directory above. 

There aren't any trade secrets in Quoth, if there's any other features people want to understand just shout and I'll put it on the tutorial list. Thanks for the pointer on the keyword order, I'll fix that in the text. 

There aren't any trade secrets in Quoth, if there's any other features people want to understand just shout

I think you are completely wrong! I have seen CZG, necro, Kinn and metlslime QC files and all of them were amazing sets of code which has made my understanding of QC better. I think you seriously under estimate the value of letting people see a working codebase. Cherry picking examples is all well and good but seeing the whole picture is damn right educational.

For example I would love to see the AI code for a bob from Quoth, I love how they move, shoot and even their crazy death is cool. Another gem I would love to see is the working code for the ladders in Quoth, not text descriptions but actually working QC files.

There are tons of things about Quoth QC that would be awesome to look at and I personally believe the greatest thing you could ever do for this community is let people see what QC tricks you have done. 

I should probably post the RMQ qc somewhere.

<Most hated project ever yadda yadda go fuck yourself>

Would any of the people the above didn't apply to be interested in seeing it?

There are some gems in there, like Supa's NPC code and the Shambler lightning attack visual improvement.

Exploding zombies and fast zombies were mine, and pretty cool if I do say so myself :>

I think next map (after I release the current one) will have the exploders in it. 

For all its faults, RMQ had some wonderful things in the qc. 

Map were also incredibly epic... 

 

https://www.youtube.com/watch?v=xnOLhXmhkyA&t=4m8s