Sorry ;-) 

I imagine the reliance on MFC is part of the problem. Talk about an albatross. :) 

Dunno if it helps, but tyrutils qbsp can apparently read q2 mao format, so that could save an extra conversion step 

MFC is just a wrapper for the windows API, I thought? What makes it so awful to use?

EDIT

googled "MFC sucks," 632,000 results
http://www.jvoegele.com/software/mfcbeef.html 

Haha, yeah. Also, it's dead (as in Micrsoft is no longer supporting it) so newer versions of Windows are going to have shittier and shittier support for it. 

You can grab the latest NetRadiant here: http://www.icculus.org/netradiant/files/netradiant-1.5.0-20120301-win32-7z.exe

I have no problems using it in windows 8.1 

Get it from here: http://ingar.satgnu.net/gtkradiant/index.html#download 

ok fair enough 

 

Well, the actual newest netradiant version (posted by negke) also seems to work fine on my windows 8.1

However they still haven't fixed the fucking clipper (it doesn't draw the 1,2,3 numbers on clip points) since it broke years ago. 

The linked version (http://www.icculus.org/netradiant/files/netradiant-1.5.0-20120301-win32-7z.exe) doesn't work for me.
I still get this: https://i.imgur.com/DwU4XQr.jpg
Usually nothing happens afterwards.
Sometimes it starts but crashes after a short while. 

I think it hangs like that for a long time when you start it up for the first time.

Have you tried just letting it sit like that for a bit?

After the first time, it should start up normally. 

well, if you do wait until it starts, but it then crashes, then I dunno. 

Sometimes it seems to work but the 3D viewport and some hotkeys keep glitching.
I can't find the problem... 

Any of the LIGHT.exe tool developers planning on adding "smooth" "phong" shading support to their compilers? Light smoothing / samples and widening angle doe do a lot but I would like to have a little more control in that regard. Smooth shading 8 sided pipes for example would be nice :)

Please correct me if this is TOTALY in the wrong thread. Apologies ahead of time if it is.

Thanks! 

How would you control it? If you just set a level-wide smoothing angle you'd get smoothing all over the place and not just on your pipes. It was easy for Arghrad in Quake2 because you could set per-surface light values, and the hack was that if you set a value but didn't check the 'emits light' flag it would treat the number like a smoothing group. Since Quake has no such thing, that would basically mean using either texture prefixes or something like func_smooth, which both sound kind of awful. 

I was thinking not a seperate func, but a key/value that works on any func - like a _smooth property

To use on world geo, you'd put your chunk of world geo in a func_group, or a func_detail I guess. 

actually specifying per-surface values was pretty awful so i wouldn't mind having using a func_group (or func_smooth) instead. Sure it would be less flexible (can't mix smooth and hard on the same brush) but it would be much faster to set/verify which brushes will be smoothed. 

I would be curious to try that approach since the per surface value is missing in Q1. 

just increase side count to 32?
And r_speeds be damned! 

(can't mix smooth and hard on the same brush)

Maybe you meant something else, but if the smoothing is governed by a "smooth angle" key, then you could get hard and smooth on the same brush surely.

Anyway, a complication with the func_ approach is that the lighting has to be done once BSP has had its way. At this point you'd have lost your func_group data surely? And really, we'd need this to work on world geometry or it would be pretty pointless. 

And if you want hard and smooth shading mixed on a brush then you will just have to use multiple ones.... Then again having a range on the smooth key could still work.

A pipe that is 8 sided but with a cap would shade smooth on the 8 sides and flat shaded on the cap if you set the smoothing threshold to 50.

Those 8 sides wont go past 45 and the cap is a 90 degree angle.

I would include 2 values though. one for the degree threshold and another for groups simply controlled by another number. That way you can have brushes smooth next to each other but if they don't share the same group they smooth on their own and ignore their neighbor.

its basic and does not allow for more elaborate mixing though. 

Anyway, a complication with the func_ approach is that the lighting has to be done once BSP has had its way. At this point you'd have lost your func_group data surely? And really, we'd need this to work on world geometry or it would be pretty pointless.

Yeah, you couldn't do it in the traditional way. Possible workaround 1: emit some kind of e1m5rmx.smo file in the bsp pass which contains the relevant smoothing data for the lighting pass, no smoothing if it's absent. Possible workaround 2: Create what might be the first hybrid bsp and light compiler which could remember the smoothing info...

Since you can't really process any lights until the bsp is complete, I'm not sure that option 2 would really be simpler than option 1. 

I'm surprised nobody has done a monolithic compiler app ... one that does it all in one shot - with the possible benefit being what you mentioned, each process being able to have knowledge of what the earlier ones did. Although I guess there's little benefit so why bother? 

AO baked into the lightmaps AKA the way CS:GO does it. AO would look awesome with brush architecture but the few engines I've tried to force it "on" in doesn't work.