wooot
this sounds serious :) 

Yeah, you are right about worldcraft screwing up trigger_multiples when they are created as a point entity.

To get them to work properly you have to first create the trigger, then go into smartedit and finally add both mangle and ORIGIN values manually.

The alternative method (and my preferred option) is to create a trigger_multiple_point entity in Worldcraft and then strip the _point part from the classname in a text editor before compile.

Perhaps there is a way around this by modifying the entry for triggers in the WC FGD file, but that seems like more hassle than it's worth, and there are probably command line programs that can strip text from files that can just be added to the compile batch file or whatever.

This sucks, but I guess this type of trigger is only used in maps that are going to push the precache model limits, so it isn't really something most people will have to deal with. 

Preach, I finally noticed the link to an earlier post you made (http://www.celephais.net/board/view_thread.php?id=47757&start=742&end=742) and have just realised I basically said exactly what you did again. Sorry for the wasted time. I'll see if I can track down a util to strip out the _point part of "classname" "trigger_multiple_point" lines from the .map file and make a useful post shortly :)

By the way, what qcc compiler do you recommend? The size of the progs.dat that Kell sent along with the code is around 100kb smaller than the one I compiled with FrikQCC, and it won't even compile using proQCC.

Necros, if you are reading, please let me know what QC compiler you use along with any special options. I'll probably send you an email about this shortly. 

That's the idea for worldcraft, although there's a way you can do it in the code rather than have to edit the bsp(in the case that you're using the custom code - when using the player.mdl hack you need to go entity bashing). What you do is add a function to the code:

void() trigger_multiple_point =
{
self.classname = "trigger_multiple";
trigger_multiple();
};

This basically just creates a new entity class that's identical to trigger_multiple. It's better to do it this way rather than copy-paste the trigger_multiple code for three reasons:
1. It's quicker
2. It saves space in the progs
3. If you change the trigger_multiple code at any point, you don't need to remember to make the changes again for trigger_mutliple_point.

The reason for the line self.classname = "trigger_mutliple" follows from all that discussion about monster_ogre_marksman behaving differently to monster_ogre. In fact I was meant to mention this in that post, but got carried away with the AI changes. I don't think there's anything in standard QC that checks classnames of triggers, but best to be safe, it's easy to imagine a use for a check like that.

For compiling I use FTEqcc - http://www.fteqw.com/ - at the moment, it's got a lot of options for optimisations, plus a few advanced features like macros and a precompiler that I never use, but it's nice to know that they're there. FrikQCC is also a popular compiler, and the different sizes might just be the number of optimisations you're applying. So try out FTE and see if it works better. 

For vanilla Quake or Quoth:

a) Is there a way to push the player "vertical-diagonally"? Like / or \.

b) Is there a way to make the trigger_push behave like the great Q3 jumppads?

If no, then someone should really make the code for this I think. :D 

Set an "angles" key in the trigger_push with a value of x y z, where x y z are numbers determining the angles of where the trigger pushes you.

I don't know exactly which angle is which, or if it will always work, but I have managed to create a similar diagnol push like you mentioned.

Play around with the angles a bit and see what you come up with. 

Yes, it can be done with the "angles" field like Orl said. Tip: The viewpos command (e.g. in Fitzquake and aguirRe's engines) makes it alot easier to get the proper values when you're not sure how to change the x y z ones. This is also helpful for the intermission mangle.

Q3-like jumppads work the same way. Small trigger_push on the floor with "angles" and a proper speed value. 

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.