[crossfire] Circular lighting & negetive glow_radiuses

[Alex Schultz]

>
     
      General: Never use // comment style.
     
     
I know, I just used some for temporary tests, I thought I took them all 
out but I guess I might have missed a few. I'll grep for that and fix that.

>
     
     
     >
     
      common/living.c: Making the glow radius additive is probably a bad 
     
     >
     
      thing.  A player shouldn't be able to light a few torches and get an 
     
     >
     
      effect to see everything about them (plus in real life, given the 
     
     >
     
      (pi)r³ of real lighting, doesn't much up very well.).  Same note 
     
     >
     
      applies for map.c and server/spell_attack.c
     
     
As I understand the additive lighting does accurately act like in real 
life due to to the formulas I used in los.c which is essentially a 
condensation of the pythagorean theorem and the inverse square law 
(except with different constants to make up for the different units). 
Like the old comment said,  2 lights doesn't go twice as far as one, but 
the new formulas in los.c do actually account for that and each 
successive light is less and less important to the range. However, due 
to gameplay balance issues, it may be best to take additive lighting 
out. Perhaps additive lighting should happen everywhere except in the 
player's inventory, that way the player couldn't just get a ton of 
lanterns and use them all at once for such. Also spell effects with 
negative glow_radiuses that could be made in the future would work much 
better with additive lighting on the ground anyways.

>
     
      common/object.c: op->glow_radius !=0 would be clearer checks that >0 
     
     >
     
      and <0
     
     
I would have done that in many places, except the old check in many 
places was just "if (op->glow_radius)" which would return false upon 
glow_radius being null, which as I understand glow_radius != 0 would 
return true upon null, which wouldn't be good.

>
     
      server/monster.c: while seeing how well lighted the creatuer is may 
     
     >
     
      make sense, until we do something with that, I'd much rather just 
     
     >
     
      return once we know if the creatuer is illuminated or not for 
     
     >
     
      performance reason - checking for all the spaces for all the monsters 
     
     >
     
      could prove to be a pretty big cpu hog.
     
     
My tests showed that it had very very little effect even with all the 
monsters in the goblin TC, but yeah, I'll take that out of this patch as 
it's cpu usage that doesn't need to be used at this point, but keep a 
copy of that code in case we do want to do something with this in the 
future.

I'll make these fixes to my patch at post here when I update it on the 
SF tracker.

       --Alex Schultz (aka Rednaxela)