News | Forum | People | FAQ | Links | Search | Register | Log in
Mapping Help
This is the place to ask about mapping problems, techniques, and bug fixing, and pretty much anything else you want to do in the level editor.

For questions about coding, check out the Coding Help thread: https://www.celephais.net/board/view_thread.php?id=60097
First | Previous | Next | Last
'fraid Not 
I've been caught out before declaring things aren't possible by hacks, but no I don't believe this can be done without modifying the qc. 
Func_plat 
Is it possible to move them in non 90� angles like 45� or 33�? Using Quoth. 
No 
use a func_train instead 
Func_rotate_train ? 
.. but not so much information given on Qutoh tutorial.. I guess it is quite similar to func_rotate_dorr techniques.... Ask Kell if you have doubts.. 
Oops 
I should have added that I want it to move not on the xy-plane but "vertically diagonally".
Rotate would be an idea but I really don't want to do that kind of freaky and hard stuff. =) 
Preach 
thanks for the advice, but it doesn't seem to work. Regular triggers still work ok, but nothing happens when I try to load a trigger without a model. The ent is there, but the size has not been set. I'm guessing there is something about if(self.model) that makes it never return negative. Here is the code:


void() InitTrigger =
{
if (self.angles != '0 0 0') SetMovedir ();
self.solid = SOLID_TRIGGER;

if(self.model)
{
setmodel (self, self.model);
self.modelindex = 0;
self.model = "";
}
else
{
//use mangle for the offset from origin that defines the bounding box. origin is MIN, mangle is MAX
if(!self.mangle) self.mangle = '64 64 64';
if(self.mangle_x < 1) self.mangle_x = 1;
if(self.mangle_y < 1) self.mangle_y = 1;
if(self.mangle_z < 1) self.mangle_z = 1;

setsize(self, '0 0 0', self.mangle);
}

self.movetype = MOVETYPE_NONE;
};


The code in the else statement works on its own, because it used to be in a separate function used by separate point triggers that worked just fine. 
Point Triggers 
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. 
A Few Questions 
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 
Opt1c 
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. 
/slaps Myself 
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 :). 
Opt1c 
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. 
Opt1c 
Try snapping all the brushes to the grid. The bugs may be caused by floating point vertices. 
Quake Adaptor 
wooot
this sounds serious :) 
Preach 
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. 
Oops 
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. 
Stripping Out Point 
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. 
Trigger_push 
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 
Spirit 
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. 
Diagonal Trigger_push 
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. 
More Quakec Help... 
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? 
Hmmm 
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... 
It Appears.. 
..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? 
Fast Attack 
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. 
Muchos Gracias! 
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 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.