I hate using features of anything that I don't understand how work. So:

What exactly does the -gate # switch do? It's barely mentioned in the changelog in the readme, so I have no idea what it does. It says default is 0.0, reccomended value is 1. Does it accept 0.5? 1.5? What would it do then? Please explain more about this.

The second sunlight; Does this mean that if the check for a sky surface in the direction of the sunlight angle from a point fails, it will check in several directions in a cone around the sunlight angle and see if it hits a sky surface that way?

Are checks for sunlight performed on every surface in the map?

Light currently says it will perform "8G casts" on my map. Is there a limit ever to how many casts can be performed?

Otherwise thanks for the nice tools. I was toying around one day on converting them to Java, but then I decided not to. 

Long Post! First a small dictionary:

oversampling the -extra/-extra4 options that make shadows more smooth. -extra means 2x2 grid (four times slower) and -extra4 is 4x4 (16 times slower)

surface point: each face has a discreet grid of these points where the light levels are calculated, oversampling means more points

raytracing: testing if a straight line can be drawn between the current surf point and light source without any brushwork in between

cast: one of the straight lines between the surf point and light source

The Fade Gate is used to reduce the often enormous amount of raytracing that is done for all casts. It's done by first checking how much light that will actually reach one surf point with regards to distance attenuation etc for the current cast.

If the amount is smaller than the gate level (default 1.0 light units when enabled, any float will do), the raytracing for this cast will be omitted. This can (and often does) save huge amounts of processing time.

The visible effects are extremely hard to spot, I actually haven't found any case yet. The difference is measurable as a faint random noise pattern, but not visible. It's e.g. nothing like the digital distortion of jagged shadow edges.

Of course, if you increase the gate level, more light will be missing and finally you'll be able to see it. The default level of 1 is usually good. One of the few maps I can remember that needed a lower gate value (0.25) was pushcoag.

The 2nd sunlight just checks if any skybrush is visible in any direction from the current surf point. If so, it will get the sunlight2/3 level if not already bright enough. Sunlight3 is recommended as it also uses a vertical angular attenuation, i.e. the light is omnidirectional, but still comes from above.

The raytracing for sunlight is done for all surf points in the map (as it's non-attenuated), so its impact can be severe in higher oversampling levels. Higher level also means more suns for 2nd sunlight.

The # casts is basically a product of the total amount of surf points and the total amount of light sources. The surf points depend on the total size of all faces and the current oversampling level.

Since it's usually a very big number, the final calculation is made in 32-bit float precision to avoid overflow. The biggest value I've seen in a released map was about 25G casts, I think it was gmsp3.

The # of casts or even the size of light data in a map is probably more restricted by other bsp limits. It's e.g. relatively easy to produce a map with 10-20 MB vis data, but having more than 1 MB light data is unusual. The current limit is 4 MB.

Java eh? I wonder how RVis would perform then ... ;) 

then I could run your lovely tools on random non-windows platforms. 

That clears up some things, especially the fade gate thing.

I was thinking about porting Light to java purely because I suck at writing C, and it'd be cool if I could add my own functionality (read: bloat) to it. 

I have tried to use the vermis from lost chapters in one of my maps.
It looks like the vermis dosn't respond to the flags 'delay spawn'. Since it is a void map the vermis is visible all over the map.
Is this a bug or haven't you given the vermis the spawn- delay/silent/alert flags?

Hi, sorry for taking ridiculously long to respond... the WoW bug still has a hold of me these day. :P

anyway, to answer your question there is no spawning functions for the vermis. the orignal coiling thing was made for the situation you're describing, but we never really planned on having the monster be totally exposed and not hidden away in a little pit or somesuch before activation.

i'm planning on uploading a small 'update' to the chapters pak for qexpo and if you still want the feature, i can attempt to code in some type of spawning stuff for it in the update. 

the orignal coiling thing was made for the situation you're describing,

OK! Just as I thought.
I was planning to use the void map as a 'boss map' with the Lost Chapter map I'm releasing tomorrow, so it will be a little to late to do anything about it now.

I don't know if I will use the void map in a Lost Chapter pack in the future, so thanks for the offer but I'm not sure I need it anymore! 

I tried your suggested default settings for sunlight as recommended to inertia, I must've done it right (light entity with 0 brightness and the keys/values added). Does it look decent?

- http://www.phait-accompli.com/q/s4/pre/sun1.jpg
- http://www.phait-accompli.com/q/s4/pre/sun2.jpg 

the pics are very dark ... 

The joys of different gammas. Eh nevermind about it ;) 

I might have found the cause and fix for the synchronized flame animations. After checking in DP how it's handled there, the problem seems to be that lights are static ents and therefore aren't affected by the mdl sync flag.

I've just put in a simple hack to randomize the starting pose and it seems to work in both Win/GLQuake. Now Mike's and Chapter's torch rows look better. 

since the flag is in the model data and not in the quakec, it seems that from the beginning they intended it to be handled on the client-side. So this is just one of those cases where id screwed up? 

they didn't have separate static ents from the beginning and then forgot about it. It's pretty hard to notice if the torches aren't lined up close. 

I am sure some of you have mapped for RtCW so I have some questions to all of you:

1) I have unpacked models/mapobjects from pak0.pk3 and sp_pak1.pk3 and can now load the models inside Radiant. However, some of the dirs for the objects (mapobjects/bush, mapobjects/clipboard, mapobjects/lion to name a few) only contain textures and no model file, where are they?

2) Say I added a mapobjects/bodyparts/helbody.mdc into my map as a misc/model, how can I choose which skin is used on the model? By default, hel_body1.jpg is being used, how do I make the model use lop_body1.jpg instead? 

As of right now, my models/mapobjects dir is 27.5 mb in size, I am thinking this is too small and I am missing something? 

I need this answered ASAP:

how do i make 45 degree angles on walls in which the player does NOT get stuck on the edges??

im talking something like this:
www.qwplayers.org/inertia/problem1.jpg
www.qwplayers.org/inertia/problem2.jpg 

http://www.qwplayers.org/inertia/problem1.jpg
http://www.qwplayers.org/inertia/problem2.jpg 

1) Make sure you're using aguiRre's latest QBSP.

2) If that doesn't solve the problem, merge the angled wall and its supporting right-angled walls into a single brush.

The problem occurs when QBSP grows the brushes to create the clipping hulls, and QBSP grows the angled brush incorreclty so it extends past the right-angled wall and creates an invisible wall that players get caught on. There's a command in Tyrann's engine that lets you see the clipping hulls, and there's also a command in aguiRre's QBSP that lets you view this clipping hull in normal Quake.

Hopefully this makes sense since I just had some gin and a Sam Adams. 

my picture was wrong in shot #1

here's a corrected version (repalced the old file):

http://www.qwplayers.org/inertia/problem1.jpg

and am using aguire's latest treeqbsp and txqbsps, each gives me these results 

Not sure, but - is the player going to be able to go behind that wall? I mean as you have it built, you can go on the outside and the inside. If that isn't the case, why not just make a brush and clip it at 45 degree angle? Poor example but you may get the idea (# = solid)

___
|##\
|###| 

I don't think this can be solved in qbsp, I think it's an engine bug. I think they had a fix in QuakeForge for a short while, but it had other side effects which made some levels unplayable. I don't understand the engine side of it fully. 

i see that it is a rediculously complex issue! anyway i found workarounds using external clip brushes and other humdickery, but i aprpeciate all the help i got anyway. 

inert: clip clip it 

I enjoyed inert's unhappy guy immensely. 

clarify? 

I have found a whole lot more map models in WolfToolsSDK.zip so this part is getting better. However, there are still many mapobject dirs that have only the model file (textures missing) or only have the texture and not the model. I am puzzled.