So I drop in a trigger_hurt in front of a health console thing (ala Half-Life) and it successfully gives the player +health (by using a negative numeral damage). But, 2 problems:

- the player reels back in pain (this could be explained, I mean - shots do hurt)
- you can continually eek health past 200!

So how do you stop either of these bits, but mostly - how do you stop it from continually giving you health beyond the set value (say -50 - which would add +50 health to your current health). 

Make the brush an info_notnull with the following fields

think InitTrigger
nextthink 0.5
touch health_touch
healamount 50
noise items/r_item1.wav

If you want regular, non mega-health style healing, ie. capped at 100, that's all you need to do. If you want mega-health style, capped at 250, with tickdown for health over 100, then add

healtype 2

This will only trigger once, but there are ways to reactivate it. If you add

use SUB_regen
targetname blah

then every time you trigger blah it'll restore it for another heal. I'm not sure if any combination of those will do quite what you want, but play about and I'm sure you can get a reasonable healing machine. 

Thanks! That works wonderfully except for 1 minor message/error:

Sv_startsound: items/r_item1.wav not precached 

put a health pack somewhere in your map and it will precache the sound.

This should be the case with any sound you want to use, so if you want to use a fiend grunt sound you need a fiend in the map.

Maybe Preach has a special hack for precaching sounds though :) 

Afraid not, there's no way to precache an arbitary sound or model in the original qc. Which is a bit of a pain as you could do all sorts of interesting things like mapmodels if there was, but all the precaches are explicitly specified. So yeah, that sound is the rotten health pack sound, change it to whichever sound you find suitable. 

Does anybody know how to improve the terribly jerky ending sequence of Dissolution of Eternity?

I've only been able to improve it by reducing camera tracking updates by angle comparisons and a timer. 

As I understand it, the problem is that quake angle updates on entities are only sent out as a single byte, which gives you poor precision, lower precision than a single degree in fact. You might want to speak to the SDA guys, as angle turns seem much smoother in their setpiece demos(like the credits sequence for the easy 100% run they released at Qexpo). So if there's any way around it I guess they know it. 

such protocol limitations too and I'm sure it's correct.

However, I don't think that's the problem here as this is not a demo; the camera entity updates the view in discrete steps (following nextthink 0.1) and it doesn't seem to help to make the steps smaller either.

My hope was that there'd be a way to make the camera pan the scene like a player turns. Otherwise maybe the easiest fix is to just update slower, thus making the camera work steadier.

Btw, what is the formula for calculating where an entity will be shortly according to its current origin and speed/direction? 

I'm pretty sure the problem isn't present so much in demos, and only appears real-time cutscenes such as this, becuase a fixed path for a camera has to be sent out from the server(which has the progs.dat) to the client, and so uses the network protocol. Demos record a client's perspective so maybe they can get higher precision that way. I know that one of the selling points for proquake was that it had "double" precision on aiming, ie two bytes, which makes a noticable difference for aiming rockets etc. I'd expect the same would be true on camera things, so the system would be limited more by update rate(the nextthink).

If you get round the protocol limitations then the way to ensure a smooth update is to use PlayerPreThink or PlayerPostThink as they get called each frame. Have a flag set when the player is watching from a camera that needs to update angles, and call the angle setting function from one of these functions whenever the flag is set. I still don't think it'll help more than a little without the protocol changes though...


The latter is easier to solve, for constant speed you want

entity.origin + (entity.velocity * delta)

where delta is the amount of time into the future you want to predict. If you only have a scalar speed and direction vector, go for

entity.origin + (normalise(ent_dir) * ent_speed * delta)

Use makevectors to get ent_dir if the direction is given as an angle. The first one will probably suffice in most circumstances though. 

suggestions. I actually tried the first variant with velocity, but for this "actor", the velocity was 0 all the time. Several other properties were also 0, I don't know why.

The only thing that seemed to work was to manually save the origin into oldorigin and also previous camera angle and time into global vars. Then use this to calculate direction (yaw) and check for substantial angle (>45) or time (>2) difference and only update view then.

If you want to check out the original code, it's in ending.qc in the doe_qc.zip (any idgames2 mirror). I can also upload my variant if you want to check it out.

I've also checked several engines for different behaviour and they all seem to work the same way, except Tomaz (which crashes on the r2m8 map) and DP (where the actor can't find its way into the timepod and therefore is forever lost in dragon's lair ... ;) 

The differences between the demo format and the network protocol are very mild, and mostly to do with the packaging, not the content (AIUI).

I made the smooth turn in the qd100qlite2 credits just by writing a python script to write a remaic cam file that contained loads (100 per second or something) of move commands and feeding that to remaic -- no magic here (the recam e1m7 was done in the same way too).

Something that's very definitely the case is that the rules are different during normal play and during the intermission -- this is why the credits are centerprinted and not part of a finale text. Applying the above tricks to an demo that had a finale looked very strange -- jerking all over. If someone can explain how to get rid of _that_, I'd be very interested :-) 

The differences between the demo format and the network protocol are very mild, and mostly to do with the packaging, not the content (AIUI).

I made the smooth turn in the qd100qlite2 credits just by writing a python script to write a remaic cam file that contained loads (100 per second or something) of move commands and feeding that to remaic -- no magic here (the recam e1m7 was done in the same way too).

Something that's very definitely the case is that the rules are different during normal play and during the intermission -- this is why the credits are centerprinted and not part of a finale text. Applying the above tricks to an demo that had a finale looked very strange -- jerking all over. If someone can explain how to get rid of _that_, I'd be very interested :-) 

I'm guessing the problem is the actor is like a monster, so it's using walkmove/MOVETYPE_STEP to move instead of velocity. This makes it a lot harder to predict, as basically it can move different amounts each animation frame. Also, in standard engines the entity will literally jump position each time a new frame is called. In engines with motion interpolation, the model itself is interpolated smoothly between points, but I believe that the origin still moves in discrete steps.

Anyhow, I'll take a look at the doe ending.qc and see what can be done, and if you would upload your version I'll examine that too.

mwh, your comments are encouraging, although I had worried that the demo format had the same restrictions. I guess as long as the camera isn't trying to do a fixed position pan, and you keep the movement smooth with velocity code or updates tied to PlayerPreThink you can get something as smooth. Can't help you with the finale problem though, very odd stuff. We need an engine coder in here... 

I've uploaded my variant (progs + ending.qc) here: http://user.tninet.se/~xir870k/doe_bjp.7z . Thanks for looking at it. 

does anyone have a hard copy? Please mail it to me if you do! 

but I have a placeholder at
http://skynet.campus.luth.se/~chosen/bam/curvtutt/
in the mean time. 

I am looking for a decent, or at least different, Boss Monster for my non-base style QSP1 level.

I will need qc source, not just a model. Any suggestions? 

There is one I'm partial too that I have not seen used in a released map yet, the zombie master from Custents. 

in case you don't have the link --

http://www.fileplanet.com/dl.aspx?fatty/custents.zip 

Is it possible to create skill selector buttons like on coagstart in the Coagula contest without QuakeC?

I haven't had any luck having a button target a trigger_setskill that uses a targetname. 

Nevermind, apparently so! 

I'm trying to set up buttons to select a skill level (Easy, Normal, Hard, etc.) and a similar setup in cogstart.bsp functions without the progs.dat, so it seems like it should be possible to do without QuakeC, but it doesn't seem to work for me.

I setup a func_button, set the target name to "skilleasy" and a message of "Skill set to easy". I setup a trigger_setskill, set the skill level (message = {0,1,2,3}) and set the targetname to "skilleasy."

I push the button and it doesn't change the skill level (still is skill "1", the default).

I've checked everything 3 times, I've even dumped the .bsp source and compared to cogstart.bsp.

Is there a secret to this or something obvious I am missing? 

I decompiled cogstart and took a look at it in a map editor. That was hilarious!

Those buttons are merely psychological, they don't actually do anything meaningful (they don't select the skill), the trigger is the proximity. 

Thats what I was thinking. 

Thanks, it looks good and there's quite a lot more in there besides the monsters.

Anyone any other suggestions?