Lighting changes, was Re: [crossfire] Circular lighting & negetive glow_radiuses

[Mark Wedel]

Alex Schultz wrote:>
>
     
      The reason you might be confused is because I was sort of asking two 
     
     >
     
      things:
     
     >
     
      -Should I remove additive lighting from my circular lighting patch and 
     
     >
     
      make it a separate patch for after a greater number of lighting levels 
     
     >
     
      in implemented?
     
     
  Probably best.

>
     
      -Or should I change glow_radius to a float and give bright cone spells a 
     
     >
     
      smaller glow_radius that way?
     
     
  I'm a bit reluctant to make such a change, which means changing a bunch of 
archs, when we sort of know that lighting will be changing (the light levels may 
be less an issue at that point)

>
     
     
     >
     
      Each of those is a solution to this cone spell problem, but I'm 
     
     >
     
      currently leaning to making glow_radius a float at the moment. A 
     
     >
     
      glow_radius 0.2 object wouldn't have any affect on it's own due to 
     
     >
     
      rounding, however a stack of 0.2 glow_radius objects would due to this 
     
     >
     
      additive behavior and it would be ideal to fix the additive lighting for 
     
     >
     
      cone spells.
     
     >
     
     
     >
     
      (btw. I don't see why glow_radius would need a new name after I put the 
     
     >
     
      conversion code in.)
     
     
  A new name is needed because you'd never easily know if the values in the map 
have in fact been converted.  This could easily result in the same map being 
converted multiple times, resulting in ever increasing glow_radius.  A possible 
solution is to then unconvert it at map save.  But if the value being used 
doesn't match the proper behaviour, the more proper approach would be to modify 
the behaviour of the formula/whatever to do the right thing, and not try to 
adjust the values.  One case I can see this being a potential problem in general 
cases is if the dm creates an item - the brigthness they set won't match the one 
converted at load time, and thus be different.  Script actions could be another 
case of this diferent behaviour.

  The other point is map makers must be allowed some variable they can set that 
won't be adjusted.  This is a lesson that has been learned in the past - what 
inevitably happens is values that are auto adjusted cause more problems and 
confusion for map makers.