.. you should directly contact aguirRe for this. He will certainly be really happy to help you ;)

It has indeed something to do with precision in clipping Hull (Hull 1 ?).. I've seen several test map compiled with different epsilon, and the lower it is, the better the rendering is (i.e smoother planes, less "corners").. though... it seems to not be valid for all maps..

Some quotes from aguirRe's TxQBSP readme file give a little bit more details


Improved handling of complex maps such terrain. This is done by increasing precision when identifying unique planes (faces) and modifying hull expansion logic. This reduces the risk of clipping errors and creates much smoother clipping hulls which can help player/monster movements.

All maps don't benefit from this, therefore two new options have been introduced; "-oldexpand" which just disables the new expansion logic and "-epsilon x" (default 0.01) which sets the plane identifying tolerance. To revert to previous compiler behaviour, just add options "-oldexpand" and "-epsilon 0.05".

The default settings have been chosen for overall best results. If you have a big map that still doesn't build correctly, you can try lowering the epsilon even more, e.g. 0.001. In most maps the default settings have little effect on # clipnodes, but some maps can see either a significant increase or decrease. Thanks to Tyrann for this one.

I hope it clarifies the stuff ;) 

you just cnped the text from his website. that's how i found out about -epsilon. :P 

... hence I suggested since the beginning of my post to directly contact aguirRe ;) 

If the -epsilon factor has to do with with monster/player clipping hull adjustment, then JPL's post makes sense. I think I now know why sometimes a player gets stuck on some brushwork ingame. It's sometimes not bad brush alignment, but maybe odd hull expansion the player gets caught up on. 

Personally I think what you're trying to do is overkill, to be completely honest. How many people are going to appreciate the little subleties of the corridor floor, especially when it's all plastered over by a low-res rock texture?

Maybe there's an easier way to get the same effect that uses less brushes and generates less splits.

Ideally you'd do this in a model editor and then import it into the map and fake collision somehow. 

You could make the floor-trim into a func_illusionary. This would make the floor a lot less complex, but there would be little or no visual difference because the floor trim cannot cast a shadow anyway. 

i experimented with -epsilon more and the original change i saw didn't have anything to do with it, but rather some change in geometry in another place that affected the spot i was looking at.

from what i can tell, -epsilon does absolutely nothing! i tried with settings of 0.5 and 0.0001 with absolutely no change in geometry.

i think the changes are very subtle and will only show up on a large, completed map.

hence I suggested since the beginning of my post to directly contact aguirRe ;)

yeah, i think i will now that i've had more time to look at it. :)

Personally I think what you're trying to do is overkill, to be completely honest. How many people are going to appreciate the little subleties of the corridor floor, especially when it's all plastered over by a low-res rock texture?

/shrug this is what i appreciate in maps, so it's natural that i'd do it in my own mapping process. subtleties, for me, is what makes a map great. if you walk up to a cliff and you see the edge has been beveled and there are chips taken out of it, that, to me, is far far more impressive than someone just making a flat cliff with a 1024x1024 texture. 

Is there a command to force VIS to cut off at a certain distance (which would be hidden by fog)? Can't find my copy of the tools readme :( 

hmap2 has -farplane 

tuna's fixed version of willem's modified version of aguirre's vis has -visdist #.

yeah, i totally just wanted to type out that line. ^_^ 

And everything seems to be going well except for the old "no textures in game" crap. Yes, I've got a worldspawn key for the texture wad, and I've put the damn wad in the id1 directory, the id1/tools directory (with the compile tools) and in the /id1/maps directory (with the maps) -- no dice. Any flashes of wisdom would be appreciated. 

Which compilers are you using? 

Using Tyrann's stuff at the moment. 

Turns out I just didn't have the entries to the used textures in the wad. Feel free to throw stones or other heavy objects. 

not stones or heavy objects, and not to belittle tyrann's tools, but there's really no reason not to use aguirre's stuff.
they are the most up to date.

http://user.tninet.se/~xir870k/txqbspbjp.zip
i have yet to see a more robust bsp compiler.

http://www.quaddicted.com/tools/wvis_20100119.7z
it has multi threaded vis thanks to willem's and tuna's tweaks.

http://www.quaddicted.com/tools/BengtLightColouredR2.zip
mh tweaked aguirre's light to have colour and multi threading while still keeping all the things that made it great like sunlight2, _anglesense, _softangle and delay 5. 

 

I'm glad you solved the issue because I think I was going to be useless in this case. 

_anglesense controls how much light lights up a surface depending on the angle it is hitting it.

for example, if you have an omni directional light placed 16 units away from a flat surface, only a small area around the light will be lit up with the light intensity attenuating quickly as you get further away.

reducing _anglesense will make the light care less about the shallow angle it's hitting the face on and light up the surface farther out.

conversely, bringing _anglesense up will make it affect surfaces less unless the light is almost hitting perpendicular to the surface.

this is useful if you have, for example, a spot light that you want to make look 'fatter' but need to keep close to a wall. setting _anglesense low will make it light up a lot more area.

it also makes faking nice ambient occlusion shadows easier.

_softangle is a spotlight setting. essentially, you get more control over spots.
'angle' sets the max cone angle of the light, but _softangle sets the area that will be 100% light (not counting distance).
so you set 'angle' to 90 and '_softangle' to 30 and you get a spot that's very wide, but with only a small bright area in the center with a nice smooth gradient, as opposed to completely blanketing everything in light.

these two settings alone make it impossible not to use the tool for me. i find them way too useful! :) 

Hopefully somebody can clear this up. I am familiar with how the event_lightning entity works, as explained on the forge here http://www.quakewiki.net/archives/worldcraft/entity/standard/std2.shtm#1

What I want however, is to have four lightning bolts go off at the same time. So I simply tried setting it up the same way as the first one I made which works fine, however only the first lightning bolt goes off, the other 3 that are triggered to go off, do not.

What am I doing wrong, or what is the trick with the event_lightning entity that I can have four go off at the same time? 

The chthon lightning is hard coded for one use only. If you want multiple bolts you might have to use the hack detailed here:

http://www.celephais.net/board/view_thread.php?id=37116&start=11&end=11 

Did a map awhile back to show some tricks from the Teaching Old Progs.dat New Tricks thread.
http://www.celephais.net/board/view_thread.php?id=37116&end=100

Screen
http://www.quaketastic.com/upload/files/screen_shots/progref.jpg

Map
http://www.quaketastic.com/upload/files/single_player/maps/progref.zip
.map, rmf and wad file.
Hope it helps 

Thank you Preach, I knew there was going to be some complicated hack involved, but you explained it well. And thanks Mechtech for showing me that progs.dat reference map, I'm certain that will come in handy in the future.

Unfortunately, the lightning bolt hack does not have the effect I was hoping for. The bolt only lasts for less than a second, and one of the bolts I set up goes in a completely different direction then what I set its v_angle to.

Regardless, having these bolts appear is just for detail in my map, and in no way affects the gameplay, it was merely just for looks, but I can do without. 

I ended up using lazers instead. 

to make the bolt last longer, make a bunch of relays each triggering the lightning, and being triggered by the actual trigger.
then set incremental delays on each, so the first has 0, the next 0.2, 0.4, 0.6, etc... for as long as you want.

if the bolt needs to last a long time, you could try using a nail shooter logic gate and opening and closing the logic gate func_door to turn on and off the lightning. 

Using the trigger relays, I have managed to get the result I want, close enough anyway. Only problem is the clutter of relay and trigger entities everywhere, but I guess its necessary. :)