Just tested it, that code works fine. The problem might be that your editor is attaching a model to the point entity you're using. You can't check whether it had a model set using the edict command since the self.model code resets it. Instead, extract an entity file from the bsp and see if it has a model number there. 

Hey, I'm working on my second map and I'm running into a few problems that I hope someone can help me out with. I'm using Worldcraft 3.3 with the Quake Adaptor, all the progs that came with it and everything is at default.

The lighting on this brush is messed up, I'm not sure what's going on. Here's a pic.
http://img172.imageshack.us/img172/8306/lightsqz9.jpg

I'm having trouble adding powerups to my map, quad, pent, and eyes. They seem to load fine in the editor. But when i load up the map, they aren't there. I'm really stumped here.

I'm also wondering how to trigger stuff to happen when monsters die.

For example. The player walks into a room, bars drop down and block all the exits. After the player kills the mobs, i want to the bars to open. Porting monsters in after a monster dies is something I'd like to do too.

Sorry for the newbie questions, but Google didn't help much :)

Oh is there any good tutorials out there for this kind of stuff?

Thanks 

Are the brushes perfectly aligned? Is there anything behind that brush? Which light tool do you use?

The powerups don't appear because they touch the wall or the ceiling. You have to make sure their bounding box is some units away from any brush solids. Type "developer 1" in the console and run your map, then you'll see the corresponding warning messages.

To trigger stuff when monsters die, simply give them a target. If you want the bars to open only when all monsters are dead, let them target a trigger_counter which then opens the bars if it has been triggered the amount of times set in its 'count' field. 

Well i figured out why i couldn't add powerups. I just had to place it above the brush somewhat. I guess it can't be flush with the surface like all other items. 

Are the brushes perfectly aligned? Is there anything behind that brush? Which light tool do you use?

They look aligned in the editor. But in the game theres a small black line between some of the brushes. It's a 12 sided cylinder. I use the light tool that came with Quake Adapter. Light 1.43 by Bengt Jardrup.

Thanks for the help, I'll have to play around with all these triggers that I've never really used :). 

There are some good tutorials here:-
http://www.bspquakeeditor.com/tutorials.php

Although they use the BspEditor (which I use) in these, I think they are pretty generic in terms of teaching the basics.

If you haven't settled on your editor of choice, I would recommend that you give BspEditor a try - the latest version is a superb tool. 

Try snapping all the brushes to the grid. The bugs may be caused by floating point vertices. 

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.