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 

detail brush is bad, as qbsp would cull the 'hidden faces' of the bit of the gap you want to see. detail brushes in q1 are not like q3 where they won't cut surrounding surfaces, they are like q2 where they are only 'structural brushes that vis does not consider' 

You'd need to make it an upside-down pyramid or something, so that none of the faces touch any surrounding geometry, apart from the floor plane.
Ideally, you'd make the func_wall the same way, to avoid creating unnecessary epolys. 

http://tomeofpreach.wordpress.com/2013/03/31/windows-in-quake/

Remember that skip will also block grenades and rockets, while clip doesn't, so make sure the gap is small enough for this not to matter. 

Does anyone have this? I need it because Hammer doesn't accept comandline parameters for compiling.

The problem is that latest one asks me to install NET. framework 4.0, which i cannot install. As far as i know, v1.0 and v1.1 only ask for net. framework 2.0, which i have. Does any of you have any of this older versions?