This method has potential, but there's a problem with the way you describe it. At the moment, once you load that savegame, the first thing the progs will do is load the cutscene again, as you saved just before that command. So you need another cvar like scratch1 as a check to whether the cutscene has run. Something like

cvar_set(scratch1 1)
trigger_cvar(entityfield savegame)
if(scratch1 == 1)
trigger_cvar(entityfield playdemo)

at the end of the demo stuffcmd "scratch1 0;loadgame"

Then when it loads, the cvar has changed so the cutscene isn't run. 

In the unreleased portion of FMB-bdg (The Imp's Castle) I had used the cut-scene module from Vision by Darin McNeil.

The scenario is that just as the player picks up one of the keys, the view is switched to a camera showing a reinforcemnt troupe of Ogres rushing across the castle courtyard towards the player. So, the player has been warned but he doesn't know exactly when they will arrive.

I works quite well and was very easy to incorporate into the progs.dat. 

Yes, I'd also suggest to take a look at that:

http://www.quaddicted.com/idgames2/levels/v-z/vision.zip 

Thanks for your answers! I asked it on the Quakeplanetforum to check if the dates were changing (they didn't) and got rather cheered off.

I don't care about some coding, but I remember this question being asked earlier. The main reason was demo's need to be loaded in the quake engine before the game starts.
And working with camera's is already a big count on my knowledge.

As for the hexen2 exampel, I thought it was made with the Quake2 engine(?) which has other capabilities. Although I thought Quake and Hexen could go through one slipgate.

I'll check the custom ent mod, and try the others also. I ain't have a straight idea for it yet, but as I found myself at some strange mapping ends I was intrigued by the way it was done in The Portal Of Praevus. 

So errmm.. I have this q1 dm map, a sequal to my old map "Shall I compare thee to a summer's day" (Summer.bsp) which is 99% finished. it seems however that I just can't get the time to finalise it. It is enormous, fits 16 players easily, and I am not sure what to do with it. What do you guys think? Keep at it or dump through lack of dm interest?

B 

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.