do func_groups get ignored or something? I have a map with a func_group in it with ~4k brushes in it, but qbsp finishes in 1 second with the following:

---- LoadMapFile ----
*** WARNING 06: No info_player_deathmatch entities in level
19190 faces
4766 brushes
4 entities
2 unique texnames
38380 texinfo

Opened WAD: ..\..\QE3\gfx\jam6\mapjam666.wad
Opened WAD: ..\..\QE3\gfx\jam6\lavacity1a.wad
Opened WAD: ..\..\QE3\gfx\sock_palc_supp.wad
Processing hull 0...
Processing hull 1...
Processing hull 2...
---- WriteBSPFile ----
0 planes 0
0 vertexes 0
0 nodes 0
6 texinfo 240
0 faces 0
0 clipnodes 0
1 leafs 44
0 marksurfaces 0
0 surfedges 0
1 edges 8
2 textures 391772
lightdata 0
visdata 0
entdata 293

0.152 seconds elapsed
Peak memory usage: 13694572 (13.1M)

looks like it's skipping it? 

one idea, make sure there's at least one ordinary brush in worldspawn that's not in a func_group/func_detail. There's a bug that happens if there are no regular brushes. 

haha yup! thanks!

and while you're here... currently in this qbsp, mixed face contents is a full error that halts compilation, while other compilers (aguirre's in my case) will just give you a warning and convert the brush to a solid.

any chance of doing the same here? mixed face contents really isn't a big deal, at least, not enough to warrant an error. 

re: mixed face contents, sure, I'll look into how bjptools handles it 

One quick suggestion ... when the user doesn't specify "-threads" maybe set the value to "# of cores in this machine" - 1. That leaves one core available for working on the level or checking email or whatever.

I found when I set up my batch file to use one fewer core than I actually have, working on maps became a lot more fluid... 

Your fgd file contains a few integer properties with float default values such as in line 34:

_range(integer) : "Global light range" : 0.5 : "Scales the brightness range of all lights without affecting their fade discance. Values of n more than 0.5 makes lights brighter and n less than 0.5 makes lights less bright. The same effect can be achieved on individual lights by adjusting both the 'light' and 'wait' attributes"


That's technically invalid and I don't know what JackHammer and others would make of it. TB currently crashes at that line. I'll fix it and round such values. 

In line 76, there is this:


@baseclass base(Appearflags) flags(Angle) size(-16 -16 -24, 16 16 32) offset(0 0 24)
color(0 255 0) = PlayerClass []


The flags(Angle) part is syntactically wrong. Check https://developer.valvesoftware.com/wiki/FGD 

While doing n-1 threads by default works, I think I'd prefer auto-setting priority to "below-normal". This way, when the computer is idling, it'll use all cores, but if needed, it can be put into the background while you work on your map. 

That might work too. All I know is that right now, if I don't hand set the thread count, I end up with a machine that can't do much while light runs... 

haha yeah, i know what you mean.

as a workaround, you can start light/vis with the start.exe command:
START /BELOWNORMAL light.exe to manually set thread priority. 

I'll make it do that automatically in the next release 

Sleepwalkr, I'm fixing the fgd but I don't understand a few parts of it.

_range(integer) : "Global light range" : 0.5 : "Scales the brightness range of all lights without affecting their fade discance. Values of n more than 0.5 makes lights brighter and n less than 0.5 makes lights less bright. The same effect can be achieved on individual lights by adjusting both the 'light' and 'wait' attributes"

If I just set the value type to float instead of integer will that fix the error? This value defaults to 0.5 and 1 will change light values in the map.

@baseclass base(Appearflags) flags(Angle) size(-16 -16 -24, 16 16 32) offset(0 0 24)
color(0 255 0) = PlayerClass []

Honestly I just copied this from the fgd that ships with Jackhammer so I don't actually understand it. Can you post the correct syntax and I can update it!

<3 <3 

For float values, just use string! 

The integer vs. float thing: Integers cannot (or at least should not) have non-integer values, so that default value of 0.5 is nonsensical. Either use float or use an integer default value. If non-integer values are supposed to be okay, then do this:

_range(float) : "Global light range" : "0.5" : "yadda yadda"

As necros said, default values for floats should be in quotes.

As for the flags thing, what are these flags actually for? Does that specify additional spawnflags? Maybe it's something only JH understands.

Either way, TB2 now ignores such things (and gives a warning), but it would be cool if that FGD were compatible with all editors.

If you want, I'll make you a TB2 build to test with so that you can make all warnings go away. 

TB1 also doesn't like the "color255" types used by JH. 

It might be JH specific. Thinking about it now it might be the part that tells the editor to show the direction arrow in the 3d view for info_* and monster_* entities.

I will change to a float for those two non integer integers.

Onetruepurple : the color255 brings up the colour wheel for selecting light colours in an rgb 255 format. it's too useful to remove. It would be wonderful if TB supported something like this but for now I guess sleepwalkr can ignore this specific attribute? 

TB has a full fledged color picker but I wasn't sure how to replace color255 with it. 

I can't find it. TB or TB2? 

http://i.imgur.com/eVCefz8.png 

I'm not sure how it's set up internally, but if you add a "_color" key to a light in TB1, a color editor shows up when that row is selected. 

i think it is hardcoded currently? _sunlight_color gives a picker, but _sunlight2_color does not, for example. 

TB2 will at some point. Right now, the special semantics of that property are ignored, but it will load and it will show up in the editor. 

it's not hardcoded, but it tries to guess whether a property is a color property by examining it's name. It's flaky, and the color255 and color1 property definitions in the FGD would surely help. I will support those in TB 2.1 

I just tried out this new light utility. I'm have trouble getting lava to look right, but I'm sure I'll get it figured out. One question. Is there a limit to how many surface lights? Because I'm getting some ideas here. I realize it's just one light per texture name, but if I have 30 different light type textures, each can have a different type of surface light emit? 

no problem having multiple surface lights with the same texture name.

The way to think of it is the "_surface" key causes a light to be deleted, and then copies placed across surfaces with that texture.
There is currently a 65k limit on total number of lights, for no good reason, but the light tool will be really slow if you get anywhere near that number of lights.