[crossfire] Circular lighting & negetive glow_radiuses

[Alex Schultz]

Mark Wedel wrote:

>
     
      Well, that fixes the lantern problem.  But I also wonder how it will 
     
     >
     
      work with spell effects, like say a firebolt or some others.  While 
     
     >
     
      this is one logical spell effect, oftentimes, the way merging code and 
     
     >
     
      whatever happens, there may be in fact be many spell effects objects 
     
     >
     
      on the same space (certainly true with cone and ball type spells). 
     
     >
     
      This change could make those spells very very bright.
     
     
Well, I think that would be rather realistic, for example if to 
firebolts are intersecting the same spot at once, then they should emit 
the total combined light of both from where they intersect. However this 
may mean that some spells might need their effects glow_radius tweaked.

>
     
        Also, I'm not 100% convinced of your changes.  The various code sets 
     
     >
     
      the total light level for a space, and the LOS code then figures out 
     
     >
     
      effective lighting on each space.  The LOS code doesn't know about 
     
     >
     
      stacked light effects.
     
     >
     
     
     >
     
       So this seems to me that if there are 2 brightness 2 objects on the 
     
     >
     
      space, for all purposes, that is indistinguishable from a 1 brightness 
     
     >
     
      4 object.
     
     
Exactly, and assuming the lights aren't directional then I don't see how 
it's not realistic.

>
     
        So it seems that either the code would be additive, or objects are 
     
     >
     
      effectively dimmer than they were before because a more realistic 
     
     >
     
      distance calcuation is used.  To me, that could create its own 
     
     >
     
      problems (I'm thinking that some maps were designed with light sources 
     
     >
     
      placed at various distances to illuminate the right things).
     
     
Yeah, a brightness 4 object would have previously added 1 lightness at 
distance 4, but with the current formula, it would add 0.35 which would 
round to 0. However I could adjust the 1.5 multiplier in the code to 
make a streetlight just as bright as normal at distance 4... which would 
mean that the multiplier would need to be changed to 4.25 however I 
think that then, many things might be too bright, perhaps 2.2 would be 
better as it would make a streetlight about 0.5 and distance 4 which 
would round to 1.

>
     
        Although breaking the maps probably isn't that much an issue 
     
     >
     
      (biggest issue in all this is the rounding errors that are happening)
     
     
Yeah, as you proposed in a separate topic, adding more lighting levels 
would be very nice; It's what we really need for the above problem.

>
     
       So that said, the updated check in common/object.c is still not right 
     
     >
     
      - checking for non zero against an integer field is not proper code.  
     
     >
     
      The line should really just be:
     
     >
     
     
     >
     
      if(QUERY_FLAG(op,FLAG_BLOCKSVIEW)|| (op->glow_radius!=0))
     
     >
     
       ...
     
     >
     
     
     >
     
       so all places where you are comparing glow_radius against NULL are 
     
     >
     
      incorrect (it is effectively the same as comparing against 0, which 
     
     >
     
      you are already doing).  However, most compilers will warn against 
     
     >
     
      such a structure, because NULL is usually defined as (void*)0, so you 
     
     >
     
      are comparing an integer against a pointer which most compilers don't 
     
     >
     
      like.
     
     
Ok. I'll correct that.

       --Alex Schultz (aka Rednaxela)