wait, i thought each entity could only fire a target OR a killtarget, and not both?

So it's the opposite for monsters? 

..target a trigger_relay which in turn fires the killtarget. job done! 

You're right that in the basic quake progs, only one out of killtarget and target will work for any given entity. Specifically if an entity has "killtarget" set, then whatever name is in the "target" field will not be triggered when the "killtarget" is fired.

But it is still necessary to have a "target" for the monster to start the whole process, because the check for "target" happens in some monster specific code, which doesn't consider the case of "killtarget". (I get the feeling from these kinds of bugs that the killtarget was a late addition to the code).

I suppose that because it won't ever get used, it doesn't really matter what you put in the "target" field. You do run the risk of triggering something out of turn in fixed/altered progs if you don't make the target a safe name(for example quoth and possibly hipnotic too). 

currently, there's something in my hl2 map that's causing the engine to just quit. but the stupid thing doesn't give me any kind of error messages to help me understand what's going on.

does anyone know if there's like some kind of log i can look over or something of the type? it's impossible to fix a problem if i can't even find out what it is. -_- 

hl2 is crap delete the all map and remake it for Q1 

I had a hard job on using the killtarget in an end monster pit.

I gave a trigger_once to activate the monster, but because the monster itself opened a space in the pit it had to be closed again. So I used a train with a wait function.

In that way I couldn't use the time it took to kill the monster to open the door again.
Later I found with a trigger relay target to the monsters death could killtarget the trigger_once. The func_train just disapeared.

It took quiet some time before I understood it was the trigger_once I had to killtarget and not the func_train.

But I saw some monsters in the map also just disapear and reapear, so I think it has something to do with mismatching parameters. 

OK, here's a question. I've seen this in several id maps now and I don't get it. Look at E3M4 - from the player start position, there is an exit slipgate on the floor above. On top of that slipgate is a little trigger_teleport brush that will warp the player back to the start position - why? 

 

Maybe related to betatesting and forgotten to remove?

I just stumbled on this yesterday: http://www.inside3d.com/qip/q1/qcwa.htm#trigger_teleport 

Since a teleport ambient sound does not exist as a seperate entity, a real teleport has to be used to create the sound. No bugs here. 

Huh, OK. Seems they should have made trigger_changelevel emit the sound then. 

Such as the beginning of e4m8, there is a real teleporter that goes nowhere above the blocked portal structure. It too, is there to emulate the teleporter sound. 

Nice trick, thanks. 

I am learning a lot with my rmx map.


Any idea with QuArK's Digger thing sometimes stops working? Eg I just used it to try some window positions (faster than doing the actual brushwork) and then added some brush and boom, three diggers don't work anymore. This happened with another one earlier. 

Don't use digger: it is baaaaaaad ;)
Ask rather on QuArK forum here: http://quark.planetquake.gamespy.com/forums/ as it sounds to be more related to QuArK use than mapping issue itself :P 

The digger is only bad if you're excessively anal about your brushes and need to control every single cut yourself.

Oh wait, right, nevermind. Forgot what site I was on for a moment there. :) 

I said I just used it to try some window positions, ok!
It's not too important as I can simply put a normal brush there, the digger just looks nicer until I properly brush it. Just thought I would ask.

Did anyone manage to setup those fancy templates that were added recently? The process is simply retarted anmd for me it once half worked but never usable: http://quark.planetquake.gamespy.com/infobase/intro.mapeditor.misctools.html#templates 

The problem with digger is that it generates HOM most of the times, and also it basically a hole creator that sucks... just due to texturing difficulty...
Well, I tried to use it in my first map, and I've been adviced by Vondur to not use it anymore, so I did...and it was not a bad advice.. Anyway, perhaps I have to test a little bit more the feature :P but I really doubt it will improve my stuff.... 

Where do I look in order to fix the killtarget / target bug?

- a la Quoth1.

If its not a bug then I'll have to create a new function to handle the extra target? 

Can anyone point me to source code for a QBSP compiler that supports SKIP textures? I'm interested in learning about them... 

its a post full-compile tool, and it works just fine, Metlslime made it!! I used it for the fuse part of Slave. you just run:

newskip -mapname

all there is to it (just texture skip-able faces with a texture called "skip")

The old skip tool (can't remember who made it) doesn't like light tools, and the light tools dont like it)

I've got it at home, I can post it later but I'm sure if you google "newskip.exe Quake" you'll probably find it somewhere... 

Well, thanks, but I'd rather implement it at the QBSP level so it writes out a BSP file that is ready to rock. 

when they hit a skipped face. You see it basically removes the faces completely, and from my experience light and vis tools throw fatal errors at you every time :-( , so it can only be done after the process I'm afraid.

Although I can only speak from my level, if you know what I mean ;-P

but if you dont need to vis/light then I guess you could write it into a QBSP tool (?) 

Right. I know the Quest source code is available and they claim to support SKIP textures in QBSP but I was wondering if there were any others. 

Do you mean the one where a monster needs a target in order to fire it's killtarget, or the one where having a killtarget prevents target from firing?

For the former, the code you need to change lies in monster_death_use in monsters.qc. The line that reads

if (!self.target)
return;

should be changed to

if (!self.target && !self.killtarget)
return;

or just commented out, SUB_UseTargets can handle empty strings properly just fine.


The latter problem is a bit harder. The problem is in SUB_UseTargets in subs.qc, find the portion of code that begins
if (self.killtarget)
{
...
}

The do...while bit loops over all the entities, until a return is hit when t is the world entity - which in quake terms means we've gone through the whole list. The problem is we'd like to have it just break out of the loop, rather than return from the whole function - as currently it makes it skip the last portion that checks for targets. Solution 1 is to turn that little loop, everything I cut out from the quote above, into it's own function. Then just call your new function from the same point in the code the loop used to occupy.


Solution 2 is to rewrite the loop so the while condition actually breaks you out of the loop at the right time, without ever removing the world. That would look like:

t = find (world, targetname, self.killtarget);;
while(t)
{
remove (t);
t = find (t, targetname, self.killtarget);
}


Notice how we initialise t to the first found item, and put the while(t) at the front of the loop. This is so that if there are no entities with that targetname, the find returns world, and we skip the first iteration of the loop. Removing world crashes the server, so we really want to avoid that.