[crossfire] lighting & LOS redo.

[Mark Wedel]

  Now that I've finished the map2 command, bringing up the idea of lighting 
redo.  As doing part of that, I've thought up some new issues.

  But first, summary of proposed changes - most of these are from discussion 
last summer.  Note that all are not likely to be done at the same time, and this 
list in no way represents that order they will be done in.  In fact, the 
ordering of this list is basically random

1) Increase number of lighting levels from 4 to 12.

2) Calculate light levels as a map attribute, and not part of player LOS (this 
will make things more efficient.)

3) Add ambient light level attribute to map header, which says what basic 
lighting level on all spaces is (dimly lit rooms).

4) Change meaning of darkness map header (should change name - light_threshold?) 
- if space is below that light level, space can not be seen

5) Have walls block light (note that the wall itself will be illuminated, so for 
single thickness wall, this still won't look very good).  The idea was brought 
up of walls being lit base on where the light source is relative to the player - 
if the lightsource was on the opposite side of the wall from the player, it 
doesn't illuminate the wall.  I think this is doable.

6) Add partial blocking to terrain (or other objects) - for example, jungle 
might have a value of 3, so everything beyond the first space is darker, 
everything beyond the second space is darker still, and and some point, can't 
see any further.  This is done basically by darkness.

7) Add colored lighting.  Note that this is opaque to the server - it doesn't 
care what the color of the light is - it just passes that info to the client to 
do with it what it wants.  Note that handling more than 1 light source/space 
adds a bunch of complication, so my thought is the brightest light source on a 
space is the one that is sent.  One question is then what form to use for the 
color - using the crossfire built in colors is pretty limiting (and probably is 
not a good enough representation).  One thought might be 6 bit RGB value, as it 
is compact and probably still provides a good enough resolution (you're unlikely 
to need a dim green value - I'd think that in most cases you want pretty 
saturated values).

8) Light source information is sent to the client, and not actual darkness of 
each space.  The color of the light is also sent.  Light values could be 
negative to denote that the space partially blocks the light.  Out of view light 
sources are sent to the client if they illuminate a space the client can see. 
Also, this will also have to be used to denote spaces that block all light (eg 
walls)