because lights can be inside solid entities.

:D 

#### ####
###> <###
#### #### <---- A door

#### ####
#x#> <#x#
#### #### <---- The two x's are lights inside the doors 

electrifying something on a moving thing is much harder and more prone to error. 

note to self: read context. 

And now I am gonna electrify megaman's moving butt. 

I dont think thats even possible, is it?

I just mean put the light inside the door in the .map file so that it casts light onto the "inner faces" of the door opposite. :-)

AFAIK you can put light entities inside any solid entity, because the inside of a solid entity is not in the void, and because solid entities dont cast shadows. 

I didn't even think of that, nice tip Ricky. Makes perfect sense now that you mention it... 

I am having trouble with a func_wall to kill. A monster has "killtarget" "killwall", the func_wall has "targetname" "killwall". Nothing happens when the monster dies, what is wrong? 

If monsters don't have the target field set, then they skip the part of the code that calls SUB_UseTargets - which is the function that handles killtargets. So give the monster a "target" key which doesn't correspond to any targetname in your map, and it should work fine. 

now that is down right evil. 

I roll with the toolbar objects undocked. Thusly: http://www.grayheaven.net/unfucked.jpg

After a while the toolwindows flicker out, as if the renderorder is reversed or something. Behold: http://www.grayheaven.net/fucked.jpg

If I mouseover them, the titlebars flicker back on top, and I can sometimes unfuck it back by resizing them or minimizing the hammer window and maximizing - and after a while they fuck off again. Mothercockgobbling bullshit. It started a few days ago, either when I tried the latest geforce driver or when valve released the latest source SDK update, I'm not sure which, but rolling back the drivers haven't helped.

It's bloodfucking annoying. Anyone know of a fix?

---

Also, Willem, wtf? Why've you dropped off the PC radar? 

The PC radar? 

the crap 

Any1 has idea why could UV mapping be lost on .ase in radiant?

pictures there http://www.splashdamage.com/forums/showthread.php?t=16693 

wrath

Ahh right. I dunno, I just got tired of it I guess. 

or uv channel that isn't set to 0? all i got, sorry. 

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