My name, preserved in a changelog for all eternity! I'm gonna be so famous! 

Thanks for the update, Eric - and Pritchard :) 

There are 3 .dll's in this release(V0.15.8) that I just downloaded, is that a thing now?

I only ask cause I've never seen anything but .exe's for the build programs until now.

"embree.dll, tbb.dll and tbbmalloc.dll" 

I'm using an external raytracer (embree) in light now, mostly for performance. It's open source (Apache v2) and developed by Intel so it shouldn't be sketchy. The dll's are downloaded from: https://github.com/embree/embree/releases 

Okay, thanks. 

Bounce lighting is a crutch

i blame you for my lazy light work ericw >:( 

I would say exoskeleton rather than crutch. Nice lazy light work, Pritch, I love the chiaroscuro effect. 

Thanks, it's always nice to get compliments with fancy words I have to Google. I'm not really ashamed of how much I'm abusing the feature, it's a wonderful way to get smooth, soft lighting (those jagged edges are with soft and extra4!). I try to rely on visible sources where possible so having them reach as far as possible is a great help in a lot of ways.

I will say though that it's a shame it doesn't work for switchable lights! That's how I ended up with that before and after pic, adding a targetname to the light... Ruined my idea of an ambush in the dark... 

"I try to rely on visible sources where possible so having them reach as far as possible is a great help in a lot of ways."
I haven't reached the point where I try this feature yet, but I bet it indeed saves a lot of time by making the placement of additional ambient lights unnecessary.

"I will say though that it's a shame it doesn't work for switchable lights!"
Hmmm... Eric? Would that be within the realm of possibilities for a future update? 

I'll look into it! It was something I left out initially to keep things simpler. Nice screenshots! 

Any chance of supporting the "brush primitives" map format (like how we support Valve 220) ?

As far as I am aware, the "brush primitives" format was introduced for Quake 3 engine games, and is supported by GTKRadiant-based editors. It's like Valve 220 in that it allows textures to be projected properly on the brush face, instead of just the coordinate axes. I don't know too much about it, but there's an overview of the various map formats here:

http://quark.sourceforge.net/infobase/src.topics.face.html 

Cool! 

Should be doable, I imagine I can just grab the code from q3map2. I'll just need to find q3 map sources that use that format to test it with. 

That would be ace biscuits :) It would allow better texturing possibilities for Radiant users, of which there are quite a few here :) 

Like what? Some examples? 

It's just another .MAP texture alignment format equivalent to Valve 220 and Quark ETP 

I think I got brush primitives working - alpha build!

Hopefully radiant can be configured to use brush primitives and quake 1 textures at the same time. I only really tested the texture alignment with a brush primitives map saved with Quark, although I did check that a map saved with the new netradiant can be parsed, so will be interesting to see if this works. 

misc_models and .ASE models
j/k 

Wow that was quick :)

Here's a test map in the Quake3 BP format: https://dl.dropboxusercontent.com/u/61424391/Quake%20Stuff/testq1q3.map

I compiled it with your new build and it seems to work fine, cheers!

So, here's how you set up NetRadiant to use the BP format:

Edit the q1.game file located somewhere like here:
"C:/NetRadiant/netradiant-custom/netradiant-custom-20160911/games/q1.game"

All you have to do is set brushtypes="quake3" and maptypes="mapq3".

Then in the editor, go to preferences->settings->brush and make sure the "brush primitives" checkbox is turned on.

Restart the editor. Now, when you are in quake 1 mode in NetRadiant, you will be reading and writing maps in the Quake3 BP format. Everything else is still Quake 1 style - wad textures work fine and all that.

I still need to pester the NetRadiant guy a bit more though. In the test map, I have included a crude terrain ceiling to illustrate the main problem with the editor's handling of the BP map format - which is ironic considering the format was created for Radiant in the first place...

When in BP mode there currently seems to be no way of telling a face to use the old axial projection - it's face projection all the time. Face projection is great to avoid the weird skewed textures on certain angled surfaces that you'd get in quake's original map format, but for stuff like gentle terrain you would almost always want axial projection to get seamless texturing.

The terrain in the map looks terrible because of this. But yeah I just need to pester the guy maintaining NetRadiant to add the ability to choose face or axial projection on a surface.

A little bonus thing you could do that is not important, but might be worth doing, would be to read Quake3's "detail" flag on brushes, as an alternative to using func_detail - this might come in handy for people who want to try converting existing Quake 3 maps over to Quake. 

Hmm...not sure this is a bug or not, jpegs below:

Func_wall no _shadow: computer_noshadow
Func_wall with _shadow 1: computer_shadow1

See the hard line where the face changes textures at the trim baseboard?

Tried messing with the brushwork and got these:
uh-oh
and_more_breakiness.jpg

.MAP: asset_library.map (ya you can guess what this is eventually going to be ;) ) 

and_more_breakiness 

I had that happen to me once on a map I was working on, my solution was to reduce the intersection of the brushes as much as possible. So the wall behind would need to be cut to shape around the computer panel rather than having them simply overlap. Try it and see if it helps, I guess. 

I think that bug was fixed in v0.15.7 :) If you're on an older version, updating to the latest should fix it. 

So I was messing about with flashing lights and realised that due to limitations of the engine there are certain things I can't do that are pretty simple. Things like having alternating flashing lights (without needing extra trigger/relay entities). Or having a light that has a fade and a flash sequence.

So I was thinking about custom lightstyles. Here is the idea:

A light entity with the tag "_lightstyle" which allows users to have cusom "id" format lightstyles: string value a-z (example: "aallzzll").

What are your thoughts? 

I think something like that could be done in quakec.