you can say FUCKING here. we're not that easily offended :D 

...I know you've said ...[t]hese arches are added just to break some uniform huge grey areas... but it's probably best to keep angular irregularity quarantined from other spaces in the level, so smaller vestibules rather than huge grey areas. Mind you, nowadays at least, you might just as easily say "fuck the CutNodePortals_r warnings" as long as r_speeds are within limits. 

... it's rather a design aesthetic issue than an real QBSP compilation problem... I have a huge places where all walls and ceiling are grey (like reinforce concrete bunker walls...), and I just would like to break this uniformity....
Anyway... I have a little idea to avoid this kind of FUCKING "troubleshootings"...
(I said it, yesssss.... ) 

...will set you free! Occasionally... for a while... perhaps... then comes the vacuum... and the need... then the drugs... etc. 

i personally wouldn't rotate anything that had multiple brushes that had to line up. I'd build it from scratch at the angle i wanted it. 

Rotating doors consisting of multiple brushes 90 degrees has never caused me any issues. 

Well, (unless that was sarcasm), obviously you won't have any issues when rotating objects in increments of 90, due to the symmetry of the coordinate system.

Rotating a brush any other amount is generally a bad idea, in my experience. Like metlslime said, build from scratch and use vertex manip. to get it at the angle you require. 

Rotating by anything other than 90� is a recipe for disaster. Do what metlkinn said. 

anyone know of a a radiant tutorial for worldcraft/hammer users?

or does such a creature exist? 

I agree, some rotation angles are more tricky to manage than others, I've experienced it... But I think it's rather difficult to build (for example) arches with more than 8 sections with the same precision the "shape-builder" tool do, with or without roation ! This due to the arche's intersections that can be off-grid ... and this is a real problem to polish correctly a design... 

Just take a look at http://ugg.codealliance.ca/tutorials/ , perhaps you will find what you are looking for.. 

Tried this briefly last night, and the editor smacks me in the face with an error message saying it "failed to initialise DirectX9 renderer" and won't start. Just wondering if anyone else has tried this out yet, and whether it worked for you or not, before I start mucking about with drivers etc. 

at http://user.tninet.se/~xir870k . Main features are hardware gamma support in GLQuake, increased capacity in both engines, support for Q2/Q3 map format (from e.g. GtkRadiant) in compilers and many fixes/improvements. Please also see readmes for details.

Any comments are welcome. 

...are closely related to God. 

. 

...we are but the children, BJ is something else. 

Does your version of Q3 map support include terrain alpha mapping? 

what that is, so probably not ...

It's not actually any specific Q3 support, it's only automatically converting from the Q2/Q3 map format into Q1, translating some and ignoring some of the info.

Nothing new, qbsp is just doing what SleepwalkR's MapConv and my ConvMap otherwise does in a pre-compile step.

distrans: I take it that there was something in this release that appealed to you? 

Does anyone use this to check their maps and if so, can you tell me if the output from running a Quake1 map through it gives accurate information.

In other words is it exclusively a Q2 utility? 

Yes, I do use it for Q1 on occasion. And only part of the info is useful for Q1 maps (e.g. bad brush output). 

aguirRe, you are, without a doubt, THE MAN. 

Although if you added coloured light you would be THE MAN x2 

 

kind words guys! Although I'm still a bit unsure of what it is in this release that you seem to like so much ... 

I think it's just the overall support and improvements that you have made over time, and not just this release. I think the auto converting from Q2/Q3 format to Quake is very nice. just takes that extra step/prog out and makes it a more complete package