"Infinite projection" in 220 format causing light stage to fail. Created by rotating brush without tex lock.
Example map with stretched trim
http://www.mediafire.com/file/b29jjyh2e82r6uo/net220.map 

I'm not sure what to do.. on one hand, that face with an invalid texture projection crashes software quake (at least winquake.exe), so light.exe failing with a hard error isn't too unreasonable.

maybe qbsp should warn about the face, and then save it to the .bsp with default texturing. 

1) the qbsp defines the sizes of surfaces.
2) infinite projection means infinitely sized lightmap.

if the qbsp is generating a lightmapped surface larger than the specified limit then that's the qbsp going wrong, not the light util.
(unless its turb or sky, anyway, in which case the light util shouldn't be trying to light them and thus shouldn't care). 

Just reading about the new misc_external_map feature, and it sounds awesomebiscuits.

Although, I'd have thought it could be even more powerful if it worked like: whatever is in the external map, including multiple entities (e.g. func_door, func_detail, light_*, whatever) would just get copied across, so e.g. you could have a brush torch sconce + a light or two associated with it.

I'm sure there's a damn good reason for the current implementation but just thought i'd mention it :} 

Are you talking about Quinstance style external bsp support? 

I'm talking about the misc_external_map entity in ericw's bsp tool 

I started with "brushes only" as a first step because it simplified things a bit, especially "-onlyents" compiles can ignore the external maps right now, but they'll need to load them when I import entities as well. No special reason it can't be done though. 

Well, I think one of the biggest uses for me would be the aforementioned torch sconces where I'd maintain just a small selection of lighting prefabs; each containing some func_detail_* sconce thingy, plus a torch entity and maybe complimented with a couple of secondary filler lights.

I'm fairly schizophrenic when it comes to lighting, and often decide to change every single light in my map in a certain way, and then some time later, I end up changing them all again, etc. Being able to do this through prefabs would be a "game changer", to coin a phrase :} 

What Kinn said is why I wanted instanced groups in TB so much. You could just stick your light setup (brushes + ents) in an instance group and copy it around the map, thus easy to iterate over time. 

I've avoided directly addressing this, for fear of seeming to shit on eric's efforts in the same vein, but I feel I should clarify that Quinstance is not for external BSP files, but for MAPs, and already does what Kinn's looking for.

It is an external tool, which of course complicates compile setup, and it (along with VMFII, which does all the real work) is written in C#, which demands the .NET Framework in Windows or Mono in Linux and macOS, so I understand the value of doing a similar thing in a native tool, especially one already so widely used. Until entity support arrives in ericw's QBSP, though, you could use Quinstance to have easily tweakable prefab entity configurations. Nesting, entity name fixup, @ syntax, material replacements, most of the Source func_instance features work with Quinstance. The "origin" and "params" entities found in that engine don't, but VMFII doesn't support them either.

If you need example usage, I could pack some of my own maps up for you. The Jam 7 and Retro Jam 5 distributions include source for my entries that separates the main map from the instances, but only in JMF form, which I'm only now realizing I shouldn't have done. For most other Jams I only sent in collapsed versions, i.e. after the instances were resolved, but I've used instances on all but one of my maps going back to Jam 6 (including the "bubbler" ornaments in my Xmas Jam map), so I have plenty of samples if anyone's curious.

Eric, if you're interested, both my wrapper code and Metapyziks' is MIT licensed (really "X11", pardon me), so despite it being a different language you're free to browse it for ideas of how to approach the problem without fear of running afoul of some oddball license terms. Or how not to, if the techniques prove unappealing. I know the VMFII dev has expressed a desire, at one point or another, to redo the project to greater or lesser extent, so how much you'd want to imitate I don't know. 

the super useful _dirt_off_radius / _dirt_on_radius stuff seems to be missing from the website documentation. 

Anyone else seeing buggy behaviour with the "mangle" setting on "_sun" "1" lights? Try setting a few different yaw values on the mangle... 

What does external bsp support offer that would be different from setting the model key on a func_illusionary to a .bsp? (Ignoring precache requiring engines of course) 

its external_map not external_bsp :P 

So it's a simplified quinstance that's editor independent. Cool. 

Any love for quake 2? :) 

Would be awesome. I’m think it could be used for lots of interesting stuff 

Any love for quake 2? :)
Nothing usable right now, but I made some progress a few months ago (light.exe can read q2 bsp's and write them out with working lightmaps). What's missing is mapping the Q2 contents / surface flags to the what the tool can understand. 

Small update, mostly with changes to how invalid valve220 texturing is handled:
https://github.com/ericwa/ericw-tools/releases

I'll do another release soon with _phong_angle_concave which lets you disable / change the phong shading threshold for crevices / concave joints. 

Sounds amazing 

Yeah I've tested it and it's really useful for rocky structures where you want to smooth out the convex areas, but keep the concave parts hard (like where boulders intersect basically).
Also useful on some weird low-poly arch setups with angled trims where you'll only want concave smoothed but not convex. 

https://github.com/ericwa/ericw-tools/releases

Another small update:
- light: tweak phong shading to use area and angle weighting
- light: add "_phong_angle_concave" key
- light: fix -bspx option

full explanation for _phong_angle_concave is in the light manual: http://ericwa.github.io/ericw-tools/doc/light.html

I was going to add a toggle for the new area/angle phong shading weighting, but it's too subtle to notice in most cases, but I can make it optional if needed. 

Thanks again for _phong_angle_concave, it's quite handy!
I have some ideas of stuff to do with the new area weighting that will probably show off better how it helps, need to find some time to do it. 

Silly question, does light still act really strange around certain geometry (example on github here) or is 0.15.9 still the most reliable version? 

I haven't had those kinds of artifacts in a while with the new versions, at least not on sealed maps (sometimes on leaky maps the lighting is a bit weird).