aguirre's txqbsp uses -altaxis and automatically builds transparent water (you can disable this with -nowatervis) 

why he maintained 2 slightly different forks of bsp in parallel. It's not as if there were any obvious reasons given regarding why we should use one over the other. I use Tx, for reasons that I can't actually remember now, but I'm sure were valid at the time. 

tx supports everything tree does, but also supports floating point coordinates. unless there's anything else, there's really no reason to use treeqbsp. 

that Tree supported floating point in exactly the same way that Tx does. That's what it says in the readme files anyway. 

oh maybe it's the 'etp' thing then? enhanced texture precision? 

supported in both, according to the readmes. In fact, going from the readmes, the main features list of both tools appear to be identical. 

geez, maybe they are then? the only difference would be txqbsp supporting -group then and different switch name for old/alt axis... 

More stable, from my experience. 

Tx has better dynamic memory management, which of course is completely irrelevant with today's computers. I think that internally they use different data structures. 

I did find it funny that there is a -kinn command line switch for the light compiler! :P

"Added new option "-kinn" which translates all delay 2 lights into delay 5." 

yeah, the story behind that is this: originally the only inverse square falloff was "delay 2", which I didn't like because the light level went to infinity as you approached the light source. This of course just meant you got a big flat fullbright circle around your light all the time, no matter what the value of the light entity was. I ended up modifying the formula so that it was still inverse square but the light level at the source was equal to the light entity value, not infinity. Aguirre liked this formula, so he included it in his version as "delay 5", but in my own custom version it's still "delay 2". 

thank goodness for that, i love delay 5! :) 

i'm using worldcraft 3.33 w/ quake adapter, and is there away to tell worldcraft not to use a specific color for the brushes? a lot of times they end up black, and its hard to see with the black background.

there is an option for white background, but with the grid being gray, its pretty useless. 

Try 'grouping' the brush. Thats my mid level solution. Always hated that too. 

pretty much whenever i edit a brush, like playing with the vertices or whatever, it changes color.

one thing i do is right click on a brush and go to properties, click ok and it changes color.

i'm guessing the answer is no then. :( 

I have several flying monsters spawning in close proximity. Although they have some delay between them, occassionally one will spawn on top of the other and I get blood-n-guts all over the place. It seems that trigger_push and trigger_monsterjump do not work with flying monsters. Any ideas on how to avoid this kind of issue without resorting to qc, other than not to do it in the first place? 

to say for sure, need to see this place. trigger_monsterjump does have tested. If the monster is already flying, it does not work. Maybe there is an opportunity to put between the trigger pad covered with textured skip? Then he landed on it and no longer flying 

i don't think that will work as the fl_onground flag (which is what is needed to be on in order for monsterjump to worok) is never changed or explicitly set during teleport so if the monster didn't have it set, then it won't have it set after teleporting. 

Yes, now I've looked at the qc I can see why. I had promised myself no more messing with the devil. I seem to be endlessly 'tweaking' just to get one effect, so I will leave it alone now. If the player gets lucky, so be it.

You never know, I might even finish this map. It's four years and counting: architecture was finished not long after I released the first half of FMB-BDG, lighting about a year later, monsters went in end of last year, play-testing and looking for music this year, and I'm getting older by the minute... 

I was fooling around in Worldcraft today trying to align textures on brushes aligned at 45 degree angles when it occurred to me that someone might have already figured out the correct ratio not only for this, but for most angles in general. Has anyone formulated a table to get proper alignment on textures, scale included? 

so I have a map vising that finished today (this is bsp2 tools), and right after it said left 0:00, 100% as if it was done, it then said *********** ERROR portal not done. I haven't come across this before, uhh... does this mean the entire vis time was wasted and there's some kind of vis-killing problem in the map?

(that would only show up after its 100% done after 333 hours? lol). 

...Ouch :/ 

For 12 sided circles etc I think your angles are often 63.5 degrees (to the nearest half a degree) and 27.5 degrees. Scale for the textures on one of the diagonal sides is 1.06

Stuff I remember :) 

~0.71 is correct

0.75 is sometimes better to make edges align to grid. 

I had figured out the rotations for the 12-sided cylinder, but never the scale. Thanks for both, they're going in my own 'Mapping Tips' document.