I'll send Hipshot my working folder which, oddly enough, gave me a lot of headache because the compilers wouldn't work. When I started over, with the exact same folder structure, it all of a sudden did work. Weird stuff, but it's sorted thanks to Eric.

Besides Hipshot, you know lots of modern stuff so that's not the reason for skipping Trenchbroom. No, it's that good old Radiant love that brought you here. 

What's a good way to get a func_train to sound like it fits in a base map? "rachet metal" or whatever obviously doesn't fit. I've tried using quoth's custom sounds to use the base plat/door sounds and they are slightly better but still kind of meh. Hipnotic's ambient/humming.wav in an ambient_generalpurpose is not too bad but I'm still not thrilled with it. 

I'm currently making a Q2 map but for some weird reason the skybox doesn't seem to show up. I don't think I've done anything inherently wrong with it.

https://www.dropbox.com/s/hhh00hhjxxngitl/q2map1.map


This is the map file (less than 100kb). I'm kind of lost as to what to do. Anyone have any ideas? 

You could make the train silent and have trigger_relays fire timed doors hidden behind the walls :D

on the same principle but less offensively, you could use the info_notnull use=plat_hit_bottom hack for playing .noise1 when triggered, and have the train trigger those along the way instead. 

You can override the train's sound effects by setting "sounds" to some invalid value and then use some other precached wavs in "noise" and "noise1". 

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)?