Thats because you are not compiling with the light phase on.
The normal compile consists of 3 phases one call the meta or chopping phase this is the time when your computer forms geometry by whats called chopping the world up and filtering it (read up on it its actually quite amazing). Next is the Vis phase this is when your pc works out who can see who and what parts of the level can be seen at other parts of the level so the whole level does not load all the time when your playing it (otherwise massive lags), thier are sevarel ways of editing how the world loads which would effect the vis phase, for example area portals and hint brushs. The last phase is the light phase this is when the BSP made in the meta phase gets (its lightmap edited) lit acording to how you how lit it ( and compile switchs). Now i dont no much about other compilers apart from the inbuild gtk one as thats fine for me, but i suggest looking for the compile option/switch called light or fast light. You should also include vis (vis is nothing to do with light) compile otherwise unless your level is very small it will get very laggy very quicky.

Also you wont need to compile with anything that says the bounce switch as it takes ages and is normally used within final compiles for giving shadows extra realism (as far as i can see it makes them abit softer (same with filtering)

The reason your level looks light is because you have no lightmap so everything is just default which is like having \r_fullbright.

May i ask what version of gtkradient are you using. the newest is 1.5 but i use 1.4 as i find it less buggy you may find the same.

Some useful commands when testing your map are

\noclip
\r_showtris (ables you to see how the level loads to put bluntly)
\r_lockpvs (locks the area of the level currently loaded so you can fly around and get a better idea of thing which you cant do in showtris)
\r_speeds (like the two above but displayed as a stats value. normally i look at verts value i try to keep it below 8000 (not that i always do )
also as i said before their is the \r_fullbright command i find this highlights z-fighting (crossing over brushes with competing textures (a waste of space))

To enable the use of these commands instead of loadin the map with \map "mapname"
use \devmap "mapname".

also epsi might be able to help you with the compiler i'm sure he uses a diffarent one than gtks inbuilt.

There is no way to see and edit light in real time ( you have you use good judgement)
also you have to compile the light phase otherwise your lightmap wont exist so everything will look bright and boring.

There is no way to make light in your level work if you have not compiled them to start off with. however you could also of accidentally left them \r_fullbright command on this would give the same impression.

Other light settings include toggling the vertex lighting to either well vertex.. or lightmap.
also picmip will make lights if their on lightmap look really horrible .

edit: what OS are you using. thier should be no patch problem useless i dunno maybe your quake 3 client is not upto date. the first thing gtk will want you do is point it in the direction of your quake install so it can know where to save/get its textures from.

i found on win7 gtk 1.5 crashed "alot" but 1.4 is more stable so i would recommend that one for that OS. funnily enough i've never used xp before for any long amounts of time as i came straight from win98 so i dunno

ken can you make trininty map for quake 3 from quake live?

wrote:

lol ok,

i just know i can't edit light in game:), on q3radiant lights are represented by small diamond. and i just want to know if i can see them in game.

Thx for help meteor

Hi kenshi. i think its not possible in game but with the editor, configure on options: "show lights radius" to on. gl