ok, so i've been messing around with code alot this weekend, mostly copying & combining bits from various sources & editing trivial stuff.. i'm still fairly new to it. i've been trying to come up with my own entity though, it's a 'gib fountain', which spawns a bunch of gibs when targetted, as if you'd just twatted a monster with a quad rocket 8)

at the moment i have:


void() SpawnGibs =
{
sound (self, CHAN_VOICE, "player/udeath.wav", 1, ATTN_NORM);
ThrowGib ("progs/gib1.mdl", self.health);
ThrowGib ("progs/gib2.mdl", self.health);
ThrowGib ("progs/gib3.mdl", self.health);
return;
}

void() misc_gibfountain =
{
self.use = SpawnGibs;
}



which works, huzzah. but i'd like to know if there's any way to make it retriggerable? at the moment it only works the once, any additional triggerings will only play the sound. is it something in the throwgib function that needs changing? 

Are you using a wierd source base or something? Having just used that code and a trigger_multiple, I get a gib fountain that spawns gibs every time it is used... 

..that i'm a bit of a tool. i had a 'throwhead' in there as well which i took out when pasting the code on here since i didn't think it'd make a difference.. apparently it does 8) cheers for checking it out though.

there's another thing that's been playing on my mind... where abouts is the code that determines how monsters behave differently on nightmare? (aside from the small bit in combat.qc that reduces pain animations) and is it possible to get a custom monster, say a boss type guy, to always behave as if skill 3 were set? 

The other ai change in nightmare is the continual attacking without delays. I don't have a copy of the quake source on me right now(new hard drive arrived!), but inside3d provides an online copy. There are two bits to this,for the first you're looking for the function SUB_AttackFinished() in subs.qc. Basically all this does is means that attack_finished is never updated in skill 3. Monsters will not consider attacking while time < self.attack_finished, hence the delay in non-nightmare skills. Both the check for attack_finished and the call of SUB_AttackFinished are found in CheckAttack (or the monster specific variants) in fight.qc.

The other important function is SUB_CheckRefire. This function is only called for some monsters, the grunt and enforcer from what I've seen. Basically it sends them right back into firing as long as the enemy is visible. The self.cnt thing makes sure they only fire twice in a row before returning to some decision making. This is because SUB_AttackFinished, which resets self.cnt, is in the ai code(see fight.qc for all that). So they'll fire once, SUB_CheckRefire makes an automatic second shot, then they'll get back to the ai decision making(which almost always makes them shoot straight away again, since it's nightmare and there's no self.attack_finished set).

To make a boss monster that behaves like nightmare, you basically want to make sure it never has attack_finished set to something greater than time. So there are crude ways to do this and nice ways to do this.

Crude way:
In the sequence of "frame functions" that actually makes the monster attack, just stick a line somewhere that does
self.attack_finished = 0;
Since attack_finished is updated in the CheckAttack function, which is called before the first frame function, you can safely change it at any time after that and it'll be obeyed.

Nice way:
Write your own custom CheckAttack function for the boss monster that either doesn't look at attack_finished before firing, or never updates it with SUB_AttackFinished. CheckAnyAttack in ai.qc is the place to add this new CheckAttack type function to, look at the shambler example to see how. This may seem like more work, but it's worth it because you get much more control over how your boss behaves, in ways other than the nightmare difficulty. You can make them that much more intellegent with what attack they choose at each point. 

i didn't think to look in subs. writing a custom CheckAttack function sounds like an idea.. but since i haven't fully planned out this guy's attacking capabilities just yet i'll probably save that one for a later date. in the meantime pasting this bit of code into subs seems to have worked:

void(float normal) SUB_AttackFinished =
{
self.cnt = 0; // refire count for nightmare
if (skill != 3)
self.attack_finished = time + normal;
if (self.classname == "monster_bossname")
self.attack_finished = 0;
};


..as a tempfix at least. perhaps a little less crude than the other way.. just :p 

Is there a hacky way to use trigger_push entities that only work after having been triggered themselves? The standard use/touch "SUB_Null" hack doesn't seem to work, but maybe there's another method.. 

Not got time to test, but I suspect it would if you set movedir manually to the unit vector in the direction you want to move them. Sorry if you've tried that already... 

http://negative.net.tc/images/fitz0000.jpg
The left trigger lowers the lift (toggle door), the four small ones are fake buttons on the lift itself. Is there a way to trigger them so they'll wait until the lift has made its move (so it doesn't go down again immediately when touching the upper triggers while moving up)?
Simply triggering them restults in a crash. I couldn't think of a workaround (maybe there is none). Of course, if everything else fails, I'll resort to a regular button solution, but I wanted to try the fancy way first. 

There's a hacky way to do it. Basically mimic the usual logic gate setup, so each of the four small triggers fires a trap_shooter at a trigger_multiple with health somewhere away from the main map. You'd need one shooter for the top pair of buttons and a different one for the lower buttons. The trigger with health targets the lift.

You then have another toggle door with the same targetname as the lift which blocks the shots appropriately. So while the lift is moving up, this door must block shots from both shooters. When the lift has reached the upper position, only the shooter linked to the top 'buttons' can see the trigger with health, and vice versa.

You can probably simplify the setup a bit by thinking about how long the trigger with health takes to reset after it takes damage. If you make this amount of time the duration of one movement of the lift, then it doesn't matter whether the shooters can see the trigger with health while the lift is in motion.

As a final nice touch, you can make the 4 mini triggers silent, and have the button sounds played by another entity, triggered with the same name as the lift. That way the feedback to the player is better, as they'll only hear trigger sounds when the button has actually worked. 

Works perfectly, thanks. 

I'm checking out Quoth at the moment, and combined Necros' bunch of .def files into a unified Quake/Quoth .def for me to use (there were a lot of duplicates, and some missing entities, and no references to models, so Quest suddenly didn't draw the models anymore.) I think I got most of it right, but there are some blank spots.

The missing ones:

monster_vermis
weapon_bomb
weapon_plasmagun
weapon_hammer

I think that's all.

Could one of the Quoth guys post the .def entries for those entities? Especially the bounding box stuff.

I know your time is limited, but I could safely use Quoth for my project then. 

But why not copy another weapon and rename it - they're all the same apart from name.

The Vermis is

(-64 -64 -448, 64 64 256)

with the 'bulb' being in the centre of that box. It's pretty good at clipping the player with its throw attack, so give it around 256 units in each direction to throw the player; or stick it in the middle of a pit.

Also try and make sure it clips as little as possible with the floor; there's a bug where it can throw the player through walls. 

Thanks :-) 

I got the following message while loading my map:

"Error: Too many static entites"

What am I suppose to remove from the map in order to solve it ?

Thanks in advance... 

torches/flames, illusionaries, globes/bubbles 

Thanks, I loaded the map with aguirRe's engine, and it shown that I exceeded by the limits by 3... I just made a test removing 4 lights: I hope it will work now ;)
In anyway, thanks for the reply: you rock ! 

If you want, you can quite easily modify the qc so that torches have a spawnflag for not being static entities, if you want those three torches back, and have the dynamic entities to spare. 

Bubbles are not static, I think. 

Even simpler: use the info_notnull modelindex hack for dynamic torch models along with three independent light entities. 

.. it's not my cup of tea... and maybe I will have to split the map in order to avoid such problems... I'll see...
Anyway, thanks a lot for helping ;) 

what advantage does an entity actually gain from being static?

i've had the problem before and have noticed the 'makestatic' function in qc.. thinking how simple it would be to remove it altogether. but would that cause problems further down the line? 

They don't ever get sent over the network once the client receives them, which saves bandwidth and protects a little from packet overflow, although since the entities don't change it's not much good. The main advantage is that it saves you a conventional entity slot, and there are only 600 of them. 

Well, the whole thing is academic, since these limits were put in place for PC's made ten years ago.

It's why I prefer to work in AguirRe's engines. 

Windows was put in place for PCs made 10 years ago :-D

It's not good if OS-specific code is introduced into originally multiplatform software, or if projects (including their dependencies) depend on specific OSs. Windows development environments seem to have a tendency to automatically introduce Windows dependencies in the code...

I don't think that is an academic question at all because you can't assume that everybody on the globe uses Windows in the year 2007.

Platform independency == User friendliness! 

Fair enough, I suppose its far from academic if you can't run the stuff yourself.

I've always used windows (Mac a few times) mainly because it's what everyone else has ie. few compatability problems.