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 

The Q3 support.

I've been wanting to use your BSP compilers for a while now, for the better error reporting etc... but since they did not import Q3 map files directly, I used DuBSP instead. (Got to thank Riot for his tools, too!)

I could have used a map converter before, of course, but you know how it is (ohm's law.. path of least resistance... )

Now that your BSP(s) have the same q2/3 importing as DuBSP, I can have the best of both worlds. 

I'm building a map for quake 1. After adding some new monsters and brushes I get error after launching the map in quake (winquake, joequake). The error is "SZ_GetSpace: 8024 is > full buffer size". I get this error only after switching skill to 2 (means more monsters). Please help! Do I have to remove some entities? I wouldn't like to. 

Take a look at my engines and the readmegl at http://user.tninet.se/~xir870k , they're specifically modified to fix this issue (and others).

AFAIK, the error is caused by having too many entities and events happening which cause the protocol between the server and client parts to overflow.

Typically this happens on higher skill levels since there are more action going on. The recently released Menkalinan had a similar problem.

I believe that either you'll have to cut down on entities or require a custom engine that has a higher limit. 

Found a serious bug in Light 1.36 that invalidated light data when using -onlyents option.

I've uploaded a new version 1.37 to http://user.tninet.se/~xir870k that hopefully fixes this.

Sorry for the inconvenience. 

Ok chaps, I'm having a spot of bother when it comes to deciding whether or not to scale up my terrain textures for performance reasons.

I'm aware that the whole issue of scaled textures is a bit of a salty subject around here. Should I go with the aesthetic and keep the rock textures at 1:1; or should I use *gasp* double scale and maybe squeeze a bit of juice out of the old nag? 

i really depends how carp it looks at 2x scaling... some textures scale better than others... best bet would be to experiment a bit...