(You missed a trick with the post icon, btw...)

All we need now is tracetoss, and we have a much more dangerous AI waiting to happen for several monsters... 

you could try to approximate a toss path with a while loop. maybe in just 25% increments as you don't need a ton of precision. 

You can use a similar, but much simpler trick for use with a monster, which would allow it to predict if it can navigate to a certain spot in the future. You again spawn an entity, and we'll call it the pegasus here for ease of comparison. Give the pegasus the same movetype, size and origin as the monster, and make the owner of pegasus the monster.

Then just perform some short distance walkmoves with the pegasus - best to do 4-5 each of a distance around the average walk speed of the monster. Then just see if they succeed or fail. The easiest way is just to see if the walkmoves return true, but you might instead want to test if the pegasus is within a certain distance of a target spot after each step.

You can also substitute walkmove with movetogoal, which attempts to navigate around obstacles. Then the question you're asking is more "will the monster be able to get near the goal if he is given a second to wander about?". I remember using this when coding the scripted death sequence for the final Travail boss, to ensure he could actually walk to a spot where the sequence would make sense(and sneakily teleport him if he was stuck!).

You can actually do this without the need for a proxy entity like the pegasus. Just save the original origin of your monster, and then walkmove it as many times as you need to test whatever it's planning. Once you've decided what the best navigational plan is, reset the monster's origin back to where it started.

(If I have the time tonight, I'll do a little post about making ogres shoot at angles without cheating by changing the overall velocity of the grenades. I'll also put tracetoss for grenades into that.) 

I was more thinking for fiends, so that they won't jump at you if they can't reach you. 

The way a projectile moves in quake can be described by the increment in it's position and velocity per frame.

1. new_velocity = old_velocity + frametime * '0 0 -800'(assuming that sv_gravity is still 800).

2. new_position = old_position + frametime * new_velocity

(Maths people may recognise this as the Euler method - it's applied to each section separately though)


So if you want to trace a path up until the first contact with something, then you just need something that iterates traceline in this fashion until one collides. Here's me writing a qc function straight onto func:

void tracetoss(vector posa, vector vel, entity ignore, float nomonsters, float inc)
{
local vector posb;
local float startz;
if(inc <= 0)
inc = frametime;
startz = posa_z;
//cut off if it falls too far, like out of level
while(startz - posa_z < 1024)
{
vel = vel + inc * '0 0 -800';//lazy way to do gravity
posb = posa + vel * inc;
traceline(posa, posb, nomonsters, ignore);
if(trace_fraction != 1)
return;

vel = vel + inc * '0 0 -800';
posa = posb + vel * inc;
traceline(posb, posa, nomonsters, ignore);
if(trace_fraction != 1)
return;

}

}


Notice that you can specify the increment you want to use, with the default being the current frametime. Also, the duplicated code inside the loop is somewhere between double buffering and loop unrolling, and is solely for optimizing what could be an intensive loop. The idea is to look at trace_endpos to find where you hit. The maximum height could be made a function parameter, I was trying to keep the function simple.

Similarly, the proper way to do the gravity would be
local vector g;
g = '0 0 -1' * cvar("sv_gravity");
OUTSIDE OF THE LOOP
To make this simulate grenades best, use nomonsters = 2, this makes the trace more generous with collisions in the same way that flymissile does.


"But I didn't want grenades!" I hear you cry. What can we do about fiends? Well, you need to do something similar to this, but using tracebox. Now, the first thing I would recommend is not to just call tracebox as a function, because that might just cause you to exceed the runaway loop counter. Instead you should duplicate the qc-side tracebox code, and incorporate this new loop into that, so that you're only setting the size of the pegasus once, letting it maintain it's origin from one step to the next etc...

The other trick that I would recommend is to pick the time increment you use very carefully. In fact, I'd recommend that you pick the time increment so that at every step the z_difference you require is exactly 8 units, so that it can be done in a single call to walkmove. You have to swap the order that you do things in for that to work:

FIRST trace the new position based on the old velocity(using the old velocity to calculate the timestep)

THEN update the old velocity with gravity based on that timestep.

So the timestep you seek is abs(8 / old_velocity_z). Check for vel_z = 0 if you like. One final thing to remember is that when the sign of old_velocity_z changes from positive to negative (if it does) then you need to move the carrot from being waaaay above the pegasus to waaaay below it!


Now, here comes the gotcha. What do you do once you've performed the trace? If you hit something, you somehow need to decide whether that was the player or the world, and qc-tracebox can't do that (it's hard being a quake monster and therefore entirely blind, isn't it?). You also have to remember your ending position doesn't include the last step of the trace, as that one failed! The best suggestion I can think of right now is:

* Once you have your end position where you hit something, work out how far the player is from you ignoring the z position

* Try to tracebox horizontally towards the player to end up 64 units away from them (using the distance just calculated), again ignoring the z axis.

* Once that tracebox is ended, check if you're within, say 128 units. If so then the jump probably hits. Otherwise it probably misses.

Some of those numbers may need tweaking. I was basing it on the maximum seperation between a touching fiend and player being ~64 units (corner to corner ignoring z axis). Again, you want to trace as close as you can get, without actually colliding with the player, because then the trace fails - like going bust in blackjack. You could also split the horizontal trace into a few smaller steps, which might protect you from going bust.

And I totally ran out of time(and characters) to do anything about ogre aiming. Maybe tomorrow... 

I was trying to add a gremlin to the standard qcc and of course I got a lot of errors.
When I finally had cleaned them up I started the game and reached:

progs.dat system vars have been modified.
progsdefs.h is out of date.

It might sound familiar, but is there a solution? 

Check the changes you made to defs.qc, you can't add new fields to that file until all of the system fields have been created. 

It means you've added new stuff too high up - put your changes at the bottom of defs. 

I added four strings to the defs.qc as they were the errors I recived after compiling.

float visible_distance;
.float gorging;
.float stoleweapon;
.entity lastvictim;

How can I make addittions to the defs.qc , or should I delete all functions in grem.qc that work with doe.qc 

Like ijed said, just move those lines right to the bottom of defs.qc, and you should be fine. 

that worked.
You earned your pronounciationmark back Ij!ed.

Alhough I don't see it steal my gun, it works fine. 

Alot of times. When you're learning blind a molehill is everest. 

 

Well I trried including a Gremlin in my map without the whole SOA pak. And as I expected was the hipgrem.qc not enough. I had to make a change to the ai.qc and defs.qc as well.
When I was done and could compile without errors the gremlin came in game.

But for some reason the weapon steal trick doesn't seem to go. I did all I thought I need to do changing the needed hipsdef into the normal def.qc but something slipped away. 

it was neg!ke with his pronouncion mark. 

i guess its a dubious question asking where the gremlin has left my weapon. 

i want to be sure i understand these:

Operations:

self.flags = self.flags - (self.flags & FL_ONGROUND);
this will subtract FL_ONGROUND but ONLY if FL_ONGROUND is present in self.flags.

whereas:
self.flags = self.flags - FL_SWIM;
would just blindly subtract the flag and risk breaking self.flags if FL_SWIM wasn't there when you subtracted.

likewise:

self.flags = self.flags | FL_ONGROUND;
would add FL_ONGROUND but only if FL_ONGROUND wasn't present in self.flags.

whereas:
self.flags = self.flags + FL_SWIM;
would add the flag as well, but would break if FL_SWIM was already present in self.flags.


Conditionals:

if (self.flags & FL_ONGROUND)
is the only way to check if FL_ONGROUND is present in self.flags. 

But the safe versions are strongly preferred, because they don't break anything.

Note that you can work with multiple bits if you need to. The code for picking up armor removes all 3 armor flags before adding the correct one.

The only operation I'm not sure how to do is to toggle a flag (if off, set it; if on, clear it). 

The following code will toggle flags:

self.flags = (self.flags | FL_ONGROUND) - (self.flags & FL_ONGROUND);

The right hand side features two halves. In the case that FL_ONGROUND is already set, the first half does nothing, and the second half is equal to FL_ONGROUND, so the flag gets removed.

In the case that FL_ONGROUND is not set, the first half turns it on, and the second half is equal to zero, so has no effect.

There's a nice kind of symmetry going on with this formula. It combines the adding and subtracting flags, but in such a way that only one actually does anything in each case. The whole right hand side is evaluated before the result is assigned to the left hand side, you there is no risk that self.flags changes mid way through.

It's worth knowing that this can be extended to multiple flags:

float IT_TOP3WEAPONS = IT_GRENADE_LAUNCHER | IT_ROCKET_LAUNCHER | IT_LIGHTNING;
self.items = (self.items | IT_TOP3WEAPONS) - (self.items & IT_TOP3WEAPONS);

This code will toggle the most powerful weapons in the player's inventory correctly, regardless of which ones they may possess. In practice, it would be worth following up that line with a call to W_BestWeapon(), in case the player was using one of the weapons you just toggled. 

didn't know about the toggle one. 

You know, the one where you pick up 2 items more-or-less simultaneously, and hear only 1 sound. I was thinking of fixing it engine-side, but then I realized this: often, 1 sound overriding another is the desired behavior.

I know of the null.wav being used to kill a playing sound, but I suspect there are other situations. Can you guys give me some examples? 

It probably makes more sense to look at it from the opposite side, ie. when don't you want one sound to override another?

So, picking up multiple, different items; using a key which causes a door to open; what else? 

"Quad Cancel" sound bug, where you land just after picking up the quad, and the "oof" overrides the quad pickup sound. 

Picking up the MH at DM4 with no sound (picking up the rockets to achieve that) is a deathmatch tactic.

I am all for it anyways. 

It makes sense that anything a monster/player says overrides what they were previously saying - for example a pain sound interrupting some other noise.

If people wanted multiple pickups to sound, the fix is easy to perform in QC. Just remove the channel specification from the sound command - if set to 0, the sound plays from any available channel.