sounds like he's asking to both add and then remove an item during play.

so you'll need to make your item spawn in and then, you should killtarget them to remove them when their time is up. 

It's not a massive problem. I can make little cages around the item, it's the problem of a fight taking some time to get going.
Feels crap to take it and lose half the time as you wait for the fight to ramp up, and I thought it would be neater to have an empty arena and just drop the powerups in as the particularly nasty monsters start flooding in :)
I guess the cage thing also has the advantage that they'd probably hear it better.

Another way round it would be increasing the duration of the powerup, so they just take it and don't have to worry about them missing the respawn. I guess that'll require code editing though :E 

you could create a variant of the trick i used in ne_tower with getting a quad damage after killing the two death lords.

create a number of of empty rooms with the powerup of your choice in them.
in each room, put a teleport destination on top of the powerups, but make sure the teleport destination is part way into the floor or ceiling so that the player won't fit when they teleport.

now, create a huge trigger_teleport that corresponds to each of the destinations and give them all targetnames.

what you'll do is start off a long train of teleports with delays after picking up the first powerup.

sure give each relay a delay of 30.

give all those trigger_teleports a targetname2 that is the same.

so you pick up the first powerup. that triggers a relay that will trigger the teleport trigger 30 seconds later that teleports you into the first room where you get a new powerup. the engine then pops you back to the old spot because you don't fit in the room. that new powerup starts another relay that, 30 seconds later, will teleport you into the next room. etc etc.

finally, when you kill the boss or whatever, killtarget all the trigger_teleports from the targetname2 which will remove them all and stop the chain. 

That's brilliant :D 

What determines the fixed point of the meteor shower - it is not the position of the not_null? It appears to be 0, 0, 0 

... what is the purpose of the '1' in 'boss_missile1'? 

boss_missile1 is actually chthon's animation (not the missile spawning function).
his attack animation is looped, unlike all other monsters. this is why he just starts firing and never stops.

the lavaballs SHOULD spawn relative to the origin of whatever entity you use.
specifically, one should spawn at 100 units forward, 100 units right and 200 up, relative to the origin and the other 100 units to the left. 

Oh, I didn't think about that.

However, it ignores the origin of the info_notnull and works off 0, 0, 0. Also in practice, it doesn't look right as the source of the lava balls moves i.e. they do not emanate from a fixed point as the player moves, due to the position of the boss (arms) being recalculated.

Changing "use" to "boss_missile" does have the lava balls coming from a fixed point but it is impossible to survive the onslaught.

If you could trigger it on/off and slow it down, it could be a good anti-player device. 

make info_notnull with 'use' 'boss_missile' and 'targetname' 'meteor'

now make a trigger_relay:
'targetname' 'meteor'
'target' 'meteor'
'delay' '1'

should now loop infinitely every second and shoot.

make multiple relays and start them at different times to stagger missile launches for a more natural effect.

if you have access to multiple targetnames, you can give a 'targetname2' that's unique to the relay allowing you to turn it off again without killing all the launchers as well. 

make sure 'delay' is set in the relay otherwise the engine will crash wtih an infinite loop error. 

Just playing with it now and using a trigger_multiple with "wait" set at one second. Three problems:-

1. almost instant death (100 - 120 hit points)
2. the first lavaball does not go anywhere, it just hovers until it disappears (subsequent balls do head for the player)
3. regardless of the position of the info_notnull, the source of the lavaball definitely remains at 0, 0, 0.

So although the position of the not_null is created in the map file, the code for the boss_missile ignores it and uses 0, 0, 0.

Pity, it seemed to have potential as a boss fight - e.g. carry out some task to turn the weapon off whilst whilst avoiding the lavaballs 

you're doing something wrong then. maybe your info_notnull has brushes?
bmodels have origin of '0 0 0' at map start.

the code can't ignore the origin as it's explicitly used when spawning the missile with this line:
org = self.origin + p_x*v_forward + p_y*v_right + p_z*'0 0 1'; 

does "ShalMissile" work? it's homing, but a lot less damage. 

So this is one of those pointsize entities eh?

I have just checked the Entity.qc file and for some reason both 'notnulls' are wrong:-

/*QUAKED info_notnull (0 0.5 0) ?
/*QUAKED info_notnull2 (0 0.5 0) ?

should be:-

/*QUAKED info_notnull (0 0.5 0) (-4 -4 -4) (4 4 4)
/*QUAKED info_notnull2 (0 0.5 0) (-4 -4 -4) (4 4 4)

Just shows how often I use the info_notnull tricks.

Thanks, I'll look at this a bit more know. 

there are times when the info_notnull requires a brush to work. maybe you changed it to do one trick? 

Yes, possibly. Fourteen years of intermittent mapping... oh my word, is it really that long? 

You were right. I used it as a special trigger where it was in a frequently used cross roads but must not be activated as a trigger until certain other events had taken place, hence the need for a brush.

It pays to keep notes even if they take days to sort through! 

I have tidied up the ents.qc so everything is now as it should be within the editor: info_notnull is the point-size entity and info_notnull2 is the brush-size one.

I have also been playing with several 'missiles' and seem to have two distinct scenarios. The boss_missile works as you would expect with the player being bombarded with the lava balls. However, ShalMissile and LaunchLaser both go from the not_null origin to 0 0 0.

What is it that allows the boss_missile do do what we want but stops the other two from doing it. It seems as though boss_missile has the player as its 'enemy' all the time as it reacts as the player moves but the others are fixed. Is this something to do with what the 'activator' is? Are we able to do anything about this from the editor?

Incidentally, the LaunchLaser gives a great effect even like this - if you have the not_null close to 0 0 0 and operate the entity via a trigger_multiple, you have a build-up of an intense orange yellow glow that fades in to maximum and then fades out to nothing when you move out of the trigger's area. Looks neat and I am sure it could be used somehow. 

LaunchLaser will not work because it requires data to be sent to the function:
LaunchLaser(vector org, vector vec);

so you'd need to send 'org' as the point to spawn the laser at and 'vec' as the direction you want it to fly to, which is why it doesn't work.

ShalMissile SHOULD work.
in the function, the line:
missile.origin = self.origin + '0 0 10';
while incorrect from a qc standpoint, should still work. (or maybe you don't need setorigin when you're spawning an entity in the same frame??).
are you sure use used a point entity when you tried ShalMissile? 

in case it's not clear, there's no way to send the required data to LaunchLaser.

when you run a function via 'think' or 'use' it's the equivalent of just typing LaunchLaser(); in code, so while it works, it sends, the engine fills in the missing variables with 0. (or '0 0 0' in the case of vectors, 'world' in the case of entity and so on). 

Not really a sophisticated hack, but a nice little trick I just came across in an old map.
It's possible to simulate a crude ice sliding effect by putting a flat shootable trigger_multiple with a high wait value on the floor (possibly target it on mapstart to avoid the bleeding) - basically the old invisible wall trick. The player will slide over it like he does when landing on top of a monster; he can change the direction but he won't come to a stop until he reaches solid ground.

There probably aren't many situations where this might come in handy, except maybe in winter-themed maps or for certain traps. 

on the idea of the killable cthon frikac made long ago, is it possible to make, for instance, an enforcer that shoots player rockets? and if not an enforcer or other monster, perhaps a monster that appears like the player model? 

Couldn't you change the skin on the grunt? I thought it had more than one skin, the other being the players. I'm not 100% sure on that though. 

have monsters shooting non-standard missiles? 

scampie: yeah, you basically build a monster out of an info_notnull, filling in th_missile and such with whatever attack function you'd like.
as nitin said, neg's map lower forecourt has things like lightning dogs.

jt: nope, only one skin on grunts.