It was a Windows 7 issue.

Windows 7 is saving my maps to a second location apart from the saving Worldcrafdt does, in c:\users\myusername\appdata\local\virtualstore\program files\worldcraft\, apart from c:\program files\worldcraft\maps\ that Worldcraft saves to by default.

This doesn't happen all the time, so there is two different versions, and sometimes it loads the WC version and others the second version, leading to me thinking that it wasn't saving them half the time.

This never happened to me in Windows 95/98 SE/2000/XP sp2 and sp3 and in Ubuntu, Fedora and Red Hat distros. 

Not a justification mind...just what's happening there!

The "Program Files" folder is regarded by the microsoft team as a place you should fear to tread. The average user shouldn't need to ever look in the folders there, and because all the stuff in there is executable, it's security sensitive and unprivileged processes aren't allowed to make changes. Previous versions of windows did not enforce this, but Windows 7 (and vista maybe) make the folders protected.

Now, lots of old programs regard their program files folder as something they can write to at will, which causes a compatibility problem when you try in a newer OS. What Windows 7 attempts is to detect when that's happening, and redirect all the file activity elsewhere - to a lower security folder where you have permission to write things but can't do damage. This redirection is meant to be transparent to the program receiving the workaround.

Worldcraft is a pretty old program, certainly not designed at a time when these rules were enforced in this way. So saving maps in the program directory triggers the compatibility stuff, but evidently it's not working 100%. My advice is to move the folder out of Program Files, to it's own folder off the hard drive. You might also need to reset the permissions on the folder once it arrive. This also lets you have a shorter path without spaces, which can be helpful at the compiling stages : -) 

Did not know about the folder redirection. Very interesting and good to know. 

to the big list of those i use regularly that work badly on Windows xp sp3/vista/7/8. At least it hasn't gone to the also big list of those that i have to tweak to deactivate Windows unfounded complains (mainly at installing) or those that directly don't work at all.

Thanks a lot for the info, Preach, very instructive, and thanks to you i can now map a bit in this computer. Never suspected something like that happened, even though that now that i think it well, Windows 7 is full of occasions where it tries to restrict what you do. I hope that i won't be forced to switch to Windows 7 in a loooong time. 

How can this happen? Left side..

There is no misalignment, no duplicate whatsoever..
I tried to cut the concerning brush in 2, i�ve rebuild the brushwork(twice!!), i have put light sources all over the place and tweaked them.
Nothing helps, atm there is a light (300) right in front of it..

I�m gonna smash some smartphones now, can anybody explain me what is going on there in the meantime? 

I'm sure i've seen some lighting artifacts like that caused by coloured lighting in maps. Didn't someone have problems like this with a jam 2 map entry?

Can't be any more specific, sorry. 

 

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.