It's possible in some sense, but it's not all that easy, and you need some custom code to do it. You might want to check out zerstorer for an example of what can be done, pushing a button in the second level(among the dead) gives you an in-game cutscene of what the button did(in a different part of the map to the player). The main restriction is that you can't actually play demo files as such, without disconnecting the player. So instead you need to recreate whatever you want to demo "live", which might require a lot of custom qc code.

You might also want to look at the "custents" mod, which has some cutscene code supplied already.
http://wartrench.telefragged.com/custents.html
This will allow you to change the player's view to a camera when they press a button, and do some scripted sequences. You might need extra code depending on what you want to happen in the cutscene. 

Does it fairly neatly - but its a big download for your end users. 

Would help if I linked to a download site you could actually download it from, try:
http://hosted.planetquake.gamespy.com/fatty/default.asp?file=custents 

supports an in game camera mode that can be used for scene like actions, (close up of Chthon: "Quakeguy we meet again, but this time I have the
upper hand! See. No lightning rods anywhere!), but as far as demos -- I haven't realy experimented but there is a QuakeC patch somewhere in here:
http://www.gamers.org/pub/idgames2/quakec/
(sorry, having a brain fart over its name)
that lets you trigger cvars so maybe a setup like this would work:
trigger_cvar(entityfield savegame) --> trigger_relay ---> trigger_cvar(entityfield playdemo) ---> trigger_relay ----> trigger_cvar(entityfield loadgame) 

 

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.