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

Alex Schultz alex_sch at telus.net
Tue Apr 5 07:38:47 CDT 2005


Mark Wedel wrote:

>
     
      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.
     
     
Ok.

>>
     
      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.
     
     
Ok. So should I just build the 'conversion' into the main formula?

Also, should I implement a lookup table (generated at server load) right 
now, or should I leave it as is and add the lookup table eventually 
later as a separate patch?

          --Alex Schultz (aka Rednaxela)



    
    


More information about the crossfire mailing list