as best as I remember, without going and looking at a map, you also need a trigger to play the Player death scream sound and another to remove the weapon they drop. 

And do it. Come back when you have more solid ideas about what you want to achieve.

If you try to build on the idea too much before putting brushes together you'll get frustrated once you get to that stage.

<smiley face> 

I have a weird lighting issue in my jam map in a single corner... it's a dark shadow along a seam that only occurs when the map is vis'd. If the map is unvis'd, the seam doesn't show.

Any ideas how to clean this up so there is no seam? The light from that light fixture is a upward spotlight, delay 3, and a small delay 2 light. Using the latest tyrlite. All my other corners set up exactly the same don't have this issue :_( 

Try moving the lights extremely slightly. Or if you're using trenchbroom try using snap to grid on the geometry. :P

Tinkering a bit tends to work out for me. I get loads of weird lighting bugs all the time 

 

er... well, I took vis out of the equation completely and it still lights funny... I should've really specified "the seam only appeared when the map was sealed", rather than vis being the culprit, since I'm sure vis itself isn't doing anything to the faces that would effect lighting.

Brushes are absolutely and completely on an 8 unit grid. I use Radiant, so there's no need to guess if I making a mess. I guess I'll poke the light positions a little and see if that helps... but not hopeful there. 

maybe the brushes join in an other way as the others corners?
But i guess you checked, hmmm.
Do you have skybrushes behind that geometry?
i found light sometimes leaks through, when dabbling with commandline parameters :)
Is the texture scaled?

I have no clue. 

"Light After Vis"

What difference does that make? 

I find that I get different results depending on whether the map is sealed or not. I try to work with a sealed map just so I know it's working right. 

"Light After Vis"

What difference does that make?

Shouldn't make any, it seems that Scampie really meant sealed vs. unsealed.

Sealed maps have additional surface splitting/BSP optimizing steps in them, so i can see why it would affect lighting. 

It depends on how the geometry gets flattened to UV to create the light map.

The problem occurs most with diagonals, depending on the resolution of the light map. So setting extra4 will help it a bit, but still leave a shadow.

Either way, only try and fix it once the map is finished, since all additional world brushes will cause the light map to be recoordinated - which is why a leaking map is ok, because then light doesn't try to optimize the UV space. Meaning you also get poorer resolution shadows. 

After eating some dinner and thinking about it, I decided to split the brushes, and shifted their texture alignment 1 pixel horizontally (not noticeable) to force qbsp to make them each different faces.

Here's r_showtris of the bad lighting and the fixed lighting.

Looks like the lesson is "Throw more polygons at it until it looks good" 

ijed: yeah, that sounds about right and why my fix worked.

(as an aside, I was compiling with -extra4 -soft - gate 10... mainly because my compile still is reasonably quick) 

"Light After Vis"

What difference does that make?

I made a switchable light setup once, which was spawnflag 1 (start turned off) , lit and vised the map in that order, and the light was turned on... All the time.

So i lit it again, and the switchable light behaved like it should. 

with some trigger_relays (3), which are all triggered by a trigger_once.
They have different delays (instant, 0.2, 0.1).

When running this map in the rubiconmod from ijed, everythings fine. Even in quoth this works.

But in vanilla progs only the first relay gets activated, the other two not? Is my progs.dat corrupted or what is going on?

Its late.. 

in light after vis? 

What i believe is something else. 

Don't jump ship! I'm sure the other map will be finished soon...

And looking at the code everything seems fine - I can't see any particular thing labelled as a fix.

I didn't apply any changes to the triger system apart from is_waiting, which won't affect SUB_UseTargets. But bear in mind this is code inherited from various sources.

I have seen the bug you describe in 1.06 so I assume someone did make a fix, but didn't comment it as such.

I could do a diff, but I don't have any diff software installed on this machine. 

Can you e-mail a copy of this map to me? I'd like to investigate but it's hard to reproduce the specific issue you're encountering.

I posted a series of blog posts about how Quoth does triggers, but it's certainly very different code to the original, and contains behaviour changes. If you are running into a very specific bug in the original progs there's a good chance it's not present in Quoth simply because the code is so different, rather than a deliberate targetted fix.

If it's a behaviour change which avoids the bug, then I can't see which one it can be. One of the things that's changed is that multiple target, targetname and killtarget fields are supported, but that shouldn't affect a vanilla-built map. Another change is that an entity in Quoth can have a killtarget and still fire targets afterwards - in vanilla the code skips target if killtarget is set. But that doesn't explain why one would fire and not the other two... 

an alternative would be to put a skip texture on the offending world face and make a func_illusionary with the same brush without skip on the face. i've done that a few times and it seems to work fairly well. 

you know how a gap in the floor with a clip brush over it acts like monsterclip?

how do I make it not do that? is that possible? 

try having a skip-textured func_wall that covers the gap. 

answer: a func_wall textured with skip! 

to save an entity