and give the map file to Than (if he concurs) so he can build Single Player play into it. Your map would then get the audience it deserves. 

if it is a good ffa map then the qw ffa server(s) will probably install it. 

Good idea but haven't spoken to than in ages.
Is he on #terrafusion maybe? 

And I'd say if it can fit 16 players then you can get SP working well inside. With or without SP you should release, don't give up. 

and TCE as YMLL :) I posted in your level design thread a while ago in fact.

Not sure I really have time to work on an sp conversion of your map, but I wouldn't mind having a look if that's alright with you.

If the map is really big it might be a bit daunting to do a good sp conversion. DM3RMX was a good month or two of work, though a lot of that was spent building stuff, so perhaps adding SP to an existing dm wouldn't be so hard. 

Long time no speak Than :-)
let's continue this on email?

B 

h� that vision pak is great!

Must thank that Darin McNeil for his sense of scripting, although it's more then ten years ago. Had to know this earlier, but before it was just spagethi to me. 

I'm currently having a look at triggers in QC and am wondering how to implement a new touch trigger type that doesn't precache any model. I basically want this so that I can have a lot of touch triggers without wasting precache ents on something that can be represented by two position vectors.

The plan for the triggers is that the mapper places a point entity on the floor and then enters a vector that defines a box from that point as an offset in x,y and z. The main problem is that I don't know how to make Quake understand that the player has entered this area. The other problem is that I barely remember how QC works at all :)

Any tips would be awesome. 

. . . where they had exactly what you're describing, a bbox min and max the defined the area as a trigger once / mutliple / whatever.

I seem to remember it had the problem of always being solid, though you could tell it to autokill itself afer triggered.

There's plenty of documentation of the planetquake/lazarus page, don't know if it'll be much help for Q1 though. 

http://www.celephais.net/board/view_thread.php?id=47757&start=742&end=742

The first half of the post is how to do it, but it's missing one very vital line...

"Find the line
setmodel (self, self.model);// set size and link into world
and replace it with this chunk of code"

should also mention that you are looking for that line in the function "InitTrigger" found in subs.qc

If you have any questions on why it works then fire away. 

Seems pretty easy actually. All I need to do is create a new InitTrigger function that uses setsize instead of setmodel and then copy the main trigger functions (e.g. void() trigger_once) and replace the InitTrigger call with a call to my new function. I should have probably waited a little longer before posting a message about this actually :)

If it doesn't work then I'll post again >:) 

It's even easier, you replace the lines in the original InitTrigger, so it now works for both types of trigger. Then you don't need to create any new classnames in theory, just creating a point based entity with classname trigger_multiple will work, and the same goes for any types of trigger. Saves a lot of copy-pasting with the same change over and over.

The added trigger_multiplep class is just a convenience for mappers using worldcraft, which gets confused if you add a point entity with the classname of a brush entity. So you create a new class, which then just calls the exact same code as trigger_multiple. Kinda like how monster_ogre_marksman just gives you the same entity as monster_ogre(except the classname). 

Seems not to be widely known because its easy to miss, but the difference between a marksman and standard Ogre is that the marksman doesn't play his alert snfx - the Ogre roar / growl we all know and love.

But you probably already knew that ;) 

I tried that too, but I wasn't sure how to differentiate the func from the point ents in code. Can I just do
if(self.model) {setmodel(blah);}
else {setsize(blah);}?

I tried using self.mangle as the differentiator last time, which didn't work, though I guess that was a pretty dumb idea anyway.

Are you sure it's safe to meddle with the inittrigger function? 

Yeah, it's because the alert code checks the classname to decide what alert sound to play, and doesn't have an extra check for monster_ogre_marksman. Other places this matters are infighting - monster_ogres will attack monster_ogre_marksman, and obituaries, which are uncredited if the marksman gets the killing blow. Most interestingly, while the monster_ogre uses OgreCheckAttack, the marksman uses the generic CheckAttck function to decide when and how to attack.

The differences between the two are that OgreCheckAttack always melee attacks if at melee range, and always fires grenades if enough time has passed since the last attack and line of sight is not blocked. CheckAttack is more probabilistic, with 20% chance per frame of a missile attack if near, and 5% per frame if mid range. On the upside for the marksman, the minimum time between attacks is shorter, randomly between 0 and 2 instead of 1 and 3 for the ogre. So at short range the expectation is the marksman fires faster, at mid range the regular ogre comes out on top, on average. Pretty much all of the marksman's advantage is gone in nightmare.

If you look at the OgreCheckAttack code you might see "chance" assigned various values depending on how far the ogre is from the target. This is all totally redundant, as the function then goes ahead and fires anyway without testing chance. Seems most likely this is leftover code from the generic function that should have been deleted, not an intended design that should have been fixed up.

One other thing I thought of about the AI here is that it shows you how the chance function is not a good way to try and make the enemy close the distance, firing occasionally. Even with a low probability like 0.05, we expect a shot every two seconds. If you're designing your own monster, and you want them to occasionally lay off the attacking to get close, a more reliable way of doing it is to set an attack_finished time.

A crude decision process would be to randomly decide with p = 0.7 say to not attack for a while and instead close in on the player. Then set attack_finished to time + 2, and the monster will just run at the player for that wrong, then decide if they need to melee or close in further, or if this time they should attack. It's useful because it allows you to make a command this frame that affects the ai for several frames in the future. Making better decision than random number generators would be the next step, like deciding to close in if the player has a RL out. 

Checking whether the entity has a model is a safe way to decide whether the entity is a brush model or a point entity. The original function just assumes the trigger has a model. Any existing maps will always go down the branch of the if() statement that does setmodel, so its behaviour is identical to the original in this case. This will happen for any brush model you give it, as they must have a model by definition. To the engine, a brush entity is really just a point entity sat at the origin with the model field already set. The brushes themselves are just part of the bsp file.

So it's safe for brush entities, but is it safe for point entities? Well, all brush entities have a model, but some point entities have a model too. The important thing is that you wouldn't set the model field on the new point entity triggers you create. That way you can be sure they are safe, as you have complete control over them.

Of course, the question arises, what happens if you make a point entity, and give it a model? Does the sky fall in? Well, it gets treated as a brush entity would, so it gets the size of the model you assign to it. In fact, it works perfectly well, you get a player sized trigger by setting model to progs/player.mdl.

But didn't we just say that the function works in exactly the same what as the original quake function when the model field is set? Yes, and this means that the same thing happens in regular unmodified quake! So to save brush models for things like monster trigger_teleports in normal quake levels, you can make point entity trigger_teleports, give them a "model" "progs/player.mdl" key, and then set them up as normal. Obviously less useful for other triggers where it usually matters what size they are, but still, it's a very cool hack. I might go post that in the "new tricks" thread, just discovered while I was posting this... 

Setting the model field might be useful for regular teleporters (would it be also possible to set it to, say, the size of a Shambler if the model is precached?), but it's not needed for monster in-teleports as the triggers also work without as long as the monsters touch them at their origin. This works with all triggers btw. 

Any model will do, it's just that the player is the largest model that's always precached. Didn't know that about point sized teleports, but it's good to know. 

Is it possible to disarm a standard Ogre so that it will never fire a grenade and always try to close the distance to the player through a hack of base progs?

From what I understand, no, but then I don't yet know anything about QC. 

I've been caught out before declaring things aren't possible by hacks, but no I don't believe this can be done without modifying the qc. 

Is it possible to move them in non 90� angles like 45� or 33�? Using Quoth. 

use a func_train instead 

.. but not so much information given on Qutoh tutorial.. I guess it is quite similar to func_rotate_dorr techniques.... Ask Kell if you have doubts.. 

I should have added that I want it to move not on the xy-plane but "vertically diagonally".
Rotate would be an idea but I really don't want to do that kind of freaky and hard stuff. =) 

thanks for the advice, but it doesn't seem to work. Regular triggers still work ok, but nothing happens when I try to load a trigger without a model. The ent is there, but the size has not been set. I'm guessing there is something about if(self.model) that makes it never return negative. Here is the code:


void() InitTrigger =
{
if (self.angles != '0 0 0') SetMovedir ();
self.solid = SOLID_TRIGGER;

if(self.model)
{
setmodel (self, self.model);
self.modelindex = 0;
self.model = "";
}
else
{
//use mangle for the offset from origin that defines the bounding box. origin is MIN, mangle is MAX
if(!self.mangle) self.mangle = '64 64 64';
if(self.mangle_x < 1) self.mangle_x = 1;
if(self.mangle_y < 1) self.mangle_y = 1;
if(self.mangle_z < 1) self.mangle_z = 1;

setsize(self, '0 0 0', self.mangle);
}

self.movetype = MOVETYPE_NONE;
};


The code in the else statement works on its own, because it used to be in a separate function used by separate point triggers that worked just fine.