The difference in texinfo counts looks suspicious to me, I might start looking there. 

Marksurfaces being 5% higher seems like a lot and it's odd that there's much difference at all, but I think I'm probably the only one here that even cares how high they are. I'll be fine with txqbsp_xt for this map. 

Rick, the increase of marksurfaces can often fluctuate because of the map file. Some editors reverse the saving order of brushes, entities and groups each time they save. Marksurfaces is extremely sensitive to the order in the map file.

I used 0.14 for my latest map zendar and I could not get goodtree or onlyents to work properly. Whenever I tried to compile with the goodtree option I would get endless leaks through solid brushes throughout the map. These tools are not 100% reliable just yet. 

That's the same exact map file, just two different qbsp exes, no editor touched it or re-saved it between compiles. That's why I found it strange.

Netradiant seems to be pretty good about not screwing up things from one save to another. Usually, just changing brushes doesn't affect the marksurfaces too much. Only when adding or deleting brushes do I see large differences. 

Brush order in the actual map file seems to have big influence on msf count.

Cutting out parts of the geometry and pasting them back in after saving the file, can effect in some reduction of the numbers, if this is done "room by room".

Problems occur when maps are not made totally out of connnected boxes or "rooms", zendar or my latest map comes to mind. Forcegoodtree did not work for me too:) 

Why restrict yourself to 1996 limitations?

I get it, but from the screens you've been posting Rick I suspect you're procrastinating over your level too much. I'm all in favour of making YOUR level, but, hopefully without being a cunt, I think you've gone into tweaking overdrive.

If you love it, let it go.

And then learn from it. 

Has been since probably November. I was just trying the new utils. All I've really done in the last few months is lighting and monster placement and a couple of new textures. Marksurfaces are fine now with txqbsp_xt, a little lower than they were in November actually.

I long ago came to the conclusion that I was never going to be completely happy with it, even if I worked on it for another two years (which isn't gonna happen).

I was hoping to release it sometime in December, but ran into a minor issue and was delayed by the Holidays. I've actually been ignoring it for the last week or so. There's one more thing I want to try, but after that... 

I can't understand how func_detail work. Change someting if I will transform some brushes into func_detail?
Do it reduce time for vis process? 

Basically func detail brushwork is ignored by everything apart from the vis tool. So almost everything which isn't sealing the void or subdividing your level should probably be detail brushes - unless it's a func of course. 

And when the vis tool detects detail brushwork it doesn't include it in the vis calculation. 

And when the vis tool detects detail brushwork it doesn't include it in the vis calculation. 

Thanks 

 

A new version is out! 

1. The BSP compiler ignores func_detail brushes when calculating the BSP tree for the VIS compiler to use, then it removes the entity information from the brush(es) making just another solid brush.

2. The LIGHT compiler sees it as a solid, end of story.

3. The VIS compiler doesn't see it because the BSP compiler never included it in the BSP tree calculations that vis uses to do its thing.

Try using the skip texture on it just to see something "Special" (or rather not see it). You will get an invisible brush that will cast a shadow. 

light with _color property not lit. Why? 

try color without the underscore. 

No, it turned out a different format from 0 to 255. I used to use from 0 to 1 

light format "_color" "255 255 255" worked, but not compatible with NetRadiant. Light entity looks like white light. 

255 255 255 IS white. try 255 0 0, does that display red? 

I mean the format of the parameter. No, "255 0 0" display as white. NetRadiant worked for format "_color" "0-1 0-1 0-1" 

nt 

in documentation with underscore 

No joke. 

I am using Tyrutils-0.15 and both properties work for me to give colored light. That is, I can either write the word color with or without an underscore and the results look identical to me. The numbers have to be in range from 0 to 255.

I just tested this with this example line inside a light entity declaration:

"color" "255 10 10" // it's a red light now

The light program produces a .lit file when I use the color properties in a map file, and I need to copy the .lit file alongside the .bsp file into the same directory for loading into a Quake engine. If I omit the .lit file I still get the lights in the map, but they are always white.

I'm using the most recent release version of Darkplaces to test the map & the lighting. I hope this clarified things for anyone having issues.