where the light tool and engine calculate different sizes for that face's lightmap.

are you by chance compiling with OS X compile utils? maybe try a different 'light' util if possible? 

It never gets bigger, no matter how big your map is. Meaning resolution is lost and these types of errors begin creeping in.

You'd have to rebuild the area as different shapes; it seems angular ones, especially 45 degree ones, are very good for provoking this issue.

I can suggest two possible fixes.

Use -extra4 this might reduce the black bleeding onto what should be a lit brush. Probably a waste of time.

Make that particular surface a func_wall and give it _minlight 100 (using Tyrann's tools) so it is forced to be lit to a minimum level, but any light from the level that should affect it still will.

Maybe a third option would be an external bsp meaning you'd copy the lights over to a small piece of map which would effectively have it's own light map included, then spawn it through qc. But that's probably a lot of pissing about and I don't think .lit is supported if you'd want to use it on that piece later. 

EricW's post is based on fact, mine on trial and error and guesswork XD 

well, ijed, you might be lightmap king of Q1 going by most lightmaps in a bsp ;-)

mfx, I can have a peek at it if you want, i'm still on the telefragged dropbox folder; just let me know where to look. 

i cannot be asked to change all the light values again. There�s roughly 3000 lights in the map. I even got rid of colored lights, its a shame:( Compiling it on OSX doesn�t help either.

So, a func wall with _minlight is my only option there it seems.

The map is done, you all know i�m polishing a bit:) And such things come creeping by everyday. Like doors won�t react to triggers anymore, obscure mid air clipping and all that jazz..

Its pure joy! 

what I meant to say was, if you've been compiling with an OS X build of tyrlight, to try using the windows version instead; there's a chance the mac one could cause issues like this. I sent a patch to tyrann which should make the mac one totally safe to use, but it's not in the current 0.15 version. 

You've come across a much greater variety of weird errors than myself building at this scale.

Be sure to upload the map as well as the bsp for the test pack version - maybe there is a quick fix somewhere. 

Hit that same wall. It's a Tyrelite thing. I think that _sunlight triggers it for whatever reason. 

Using TrenchBroom 1.2 on Linux and for some reason I keep finding duplicate brushes in my map -- I would e.g. move a brush and then notice there's an exact copy (sometimes two or even three!) of the brush sitting underneath, which I did not deliberately create (I never use Ctrl+D).

Does anyone have any idea why this keeps happening? Has anyone had the same problem? Am I doing something wrong?

And is there any way of tracking down duplicates, short of moving and checking every single brush by hand? I was sort of hoping I could Ctrl+A the whole map and then just move it a few units to the side, but that of course selects the duplicates and triplicates too, thus solving nothing. I've got well over 3000 brushes so far, so checking each one manually would drive me insane. I mean more so. 

It must be something that you're doing because it's the first I'm hearing of this. 

That happened to me a bunch of times but I always assumed I doubled the action by accident. 

Pressing control while trying to move something?

You can easily create a duplicate in the same place if you try to move something when the axis is locked. 

ijed, I guess that's possible. I often Cntrl + click a few brushes in a row to select them together, and then move the entire selection. Hmm, I guess being new and inexperienced I'm just still very clumsy at mapping, but it does seem overly easy to create duplicates unintentionally in TB (seeing as it has happened to otp and mfx as well).

Any suggestions on how to track down duplicates & triplicates? Or does one just have to do it the hard way (manually, one by one)? 

They won't cause any problems since they are a duplicate - there won't be a visible error.

It will increase your bsp compile time marginally.

I come across this problem a fair bit as well. 

They only get in the way when you need to retouch the texturing right?, else those duplicates are harmless as the guy above said.. 

Good to know it's not a serious problem, but that adds yet another mapper (ijed) who's had the same experience ... so maybe that qualifies as a TB usability issue then? SleepwalkR, maybe it is something you could tweak in TB2? Should I post this in the TB thread or the github issue tracker -- or is it rather a non-issue? Don't want to seem as if I'm finding fault for no good reason...

mfx: Yes, a few times in the past they caused problems with textures, which was how I first noticed that I had duplicates (thanks to the tip you gave me in this thread a few weeks ago -- thanks again for that). 

I wonder if there's a way of adding some feature to TB that is able to match up duplicate brush info and delete one of the entries? After all a .map file is simply text and you could do a simple "find and replace" using notepad anyway.

I'm no coder and I haven't experienced this duplicating bug. There's been instances when using the clip tool that it wont split the face properly and it just duplicates the brush instead, is this what you guys are experiencing? 

0....1....2....3....4....5....6....7....8....9..\
WARNING: Too many light styles on a face
lightmap point near (-4156 -1780 -117)
WARNING: Too many light styles on a face
lightmap point near (-4156 -1780 -117)
0....1....2....3....4....5....6....7....8....9....

Look at the coordinates.
I have stripped all lightstyles , still getting this warning :( And the bad lightmap.
I think i just leave it like this for now. 

The plot thickens. It's very likely that the duplicates are a result of misinterpreted ctrl+drag operations. I'll fix that for TB2. 

I am searching for this guys excellent texture packs for Quake 2 and 3, beginning with the originals of those that Fern modified for his map Return to Dust (Fern doesn't want people to use his version), which got the Quake2 versions in here and also found this ones for Quake1.

So the question is, have i missed other Quake 1 versions of his textures or have i to rip the rest from his maps and convert what i have for Quake1?
If there is a Quake 1 version already is better, i don't mind learning to do that, but they would have been better converted to Quake 1 palette than what i would have done myself. 

Hey everyone, I've been working on a quoth map on trenchbroom since last month and since yesterday I can't compile the fucker.
Now, before that error I could comple it fine, but I had to make some adjustments because not only was the lightning terrible (ambient shadows were fullbright, colored lightning were absolute pitch-black, sky lightnings produce misplaced shadows and lights as spotlight using mangle doesn't do shit. Also notice the sky lightning was the only light that was colored.)

I changed the general skylight with local lights located around open areas and those spotlights, I made them target a personal info_null entity while making "style = 4" to really be sure I'd get spotlights, and since then I get that dreadful "Inverted min/max" error while starting the map. 

 

Darkplaces latest build, Tyrutils as compilers (used BengtLightColouredR2 as light.exe recently for the colored lights, hoping for something better but no dice) 

removing "light" from the worldspawn and see what that does. Recently seen a lot of people have trouble using a minimum light level, myself included. To be honest using a min light is generally frowned upon anyway.