InsideQC Forums

The sunlight in arghrad bothered me. It was set up so everything that had line of sight to the sky was uniformly lit with an "ambient" value. This ended up causing things to look very bland and incorrect. Reflected light would make areas that should have been darker actually lighter. http:...

There are already checks for that (assuming this is in vanilla q2): if (strstr(dir, "..") || strstr(dir, "/") || strstr(dir, "\\") || strstr(dir, ":")) { Com_Printf("Gamedir should be a single filename, not a path.\n"); return; } I guess I must have ...

It's crazy how the competition has driven engine prices down to nothing!

On a sad note, this means fewer people will be looking at GPL'd idTech engines.

I wonder if it's a rule that /* */ comments are treated as whitespace, or if that behavior could vary from compiler to compiler. Obvious approach is, "Don't do that!"

I noticed a similar issue (horizontal line on a wall) in my test map. Not sure what causes it. Maybe it's at the max edge when the lighting util is forced to chop the geometry? Maybe adding another brush caused qbsp to break the geometry up differently? There are certainly some weird little nuances ...

Well, when I was in the process of converting DeWan's modifications to the GPL codebase, I noticed this bit of code in TexinfoForBrushTexture(): /* Originally: shift[0] = DotProduct (origin, vecs[0]); shift[1] = DotProduct (origin, vecs[1]); */ if (!bt->scale[0]) bt->scale[0] = 1; if (!bt->scale[1])...

Ah-HAH! I see it.
Thanks a bunch!

Cool. I've often wondered if it would be possible to have bots playtest a more traditional shooter map (not with waypoints, but by actually learning/discovering). I hope that one day I'll get some bot AI up to the point where this concept can be tested...

This is what I'm referring to: If I put a sky (or I guess any light emitting surface) flat along the top of a map, I get this (note the dark edges): http://jitspoe.com/images/devel/surflight_blackedge.jpg It's possible to work around this by building the sky up vertically (building walls of sky) and...

So I'm basically rewriting the sun light feature in qrad3, and I need to do a trace that will return true if it hits sky. I'm running into a bit of an issue, though. For some reason, I can't seem to get to the brushes with the trace. Original trace: int TestLine_r (int node, vec3_t set_start, vec3_t...

I'll try to play around with this soon. I would have thought the problem would come from the DotProduct check, as the black edge would be where the dot product is at/near zero. I wonder if adding a small fraction to the DotProduct result would help with this (but might cause light to bleed into area...

I guess the parameter order thing is all a matter of perspective. I always thought it made sense reading left to right, like with VectorCopy(A, B); I'm starting with A, and copying it to B. Consts and better parameter names (like VectorCopy(in, out)) can help with this confusion. It wasn't until I r...

After some Internet sleuthing, I finally got in touch with Geoffrey DeWan, and this was his response: Man, I didn't even know that still existed. I am not sure exactly what I can release it as. The copy of the source code I originally grabbed from id software was released without any license at all ...

Hmm, changing that would effectively change the falloff of light in general to be less accurate, wouldn't it?

I generally return true on success for most functions, unless they can return more than 2 values. The compare functions return 0 for "true" or "equal" because they can return both positive and negative values, which matters when used for sorting. To reduce confusion, I've made my...