[crossfire] Lighting changes.

[Mark Wedel]

  After working on the opengl draw client and seeing the circular lighting 
patch, this brings up the discussion of more wholesale lighting changes.

  The current lighting with max brightness of 4 is woefully outdated.  It made 
sense back when the max map size was 11x11, and we only cared if a space was lit 
or not (and not how well lit).

  With 25x25 map sizes and graduated lighting, this doesn't work nearly so well.

  I'd personally like to see lighting reworked with many more levels.  Perhaps 
32 (0->31) as that fits nicely in 5 bits for client/server protocol purposes.

  This is where one of my concerns (additive light) with the patch comes in. 
Right now, not a big deal.  But a player shouldn't be able to light 3 torches 
and be as well illuminated as something really really bright (which is what 
you'd need for a lighting of 9).

  Doing this from a basic level isn't hard (change a few defines, change a few 
archs and maps).  The problem is existing maps with 'darkness' set.  if the 
number of lightlevels is changed, all those values are perhaps meaningless.

  I'd also like to see some changes on how darkness is handled/calculated.

  Right now, darkness levels is calculated for each player.  This doesn't make a 
lot of sense.  Imagine scorn at night - the darkness/brightness for all the 
spaces are the same for all players, so there is no reason that how dark/bright 
the square is should be calculated for all the players.  So rather, just like 
there is a 'light' value for each map space, a darkness field would be added, 
and the server woudl fill in those values universally.

  This, the logic to determine if the player can see a space would be checking 
the players blocked line of sight, and checking the darkness of the space.

  This also helps out the case of know if a creature is in a lighted space - 
simply can check the light level of the space - don't need to find light sources 
and calculate, etc.

  There are a couple oddities that would have to be handled:
1) players currently can see at least a few spaces on outdoor maps - this would 
need a little special handling.
2) Players that have see in dark effecively see everything as a little less dark 
- this could presumably be fairly easily handled
3) current darkness levels basically determine how much the players can see 
about them without any lightsource.  A low darkness means you can see a few 
spaces around you without any light source.  Trying to maintain compatibility 
with this gets tricky.  Perhaps easiest is to add a new map header value, 
something like brightness which represents your default viewable area very 
clearly.  Maps with darkness are converted to this brightness value at load.


  One wish also was for light not to go through walls.  This is perhaps doable, 
more so if light is calculated on a per map basis, as extra cost of doing this 
is not quite so bad.  But you get cases like this (pardon my ascii art):


-----------------
   A
--------------
           B
-----------------

  B is holding a lightsource, A is other player.  PRoblem is that light is a per 
space thing, so A will see the wall down the corrider illuminated (note this 
happens right now).  The only solution I can think to this is to make sure walls 
are 2 spaces wide.

  However, related to these changes would be changing how the client is notified 
of light changes.  Better effects can be done if the client knows where the 
light sources are - that'd actually use less bandwidth.

  But the case above gets compounded in this example - how does the client for 
player A know that B's light shouldn't go through the wall (suppose B has a 
really bright light that will reach spaces that A can see).  Is this a case we 
just shouldn't worry about (its only cosmetic)?  Notify client of what spaces 
block view (light) so client can adjust accordingly?