Mark Wedel wrote: > > On thinking this over some more, there is also another > complication/issue with lighting. > > As said in the original message, instead of the server communicating > darkness of each space, it communicates the location of the > lightsources and color of those sources. > > However, what do we do when the source of the light is not visible to > the player? One could envision something like long hallway, with > light pouring into the hallway form the rooms that branch off from it, > but one can not see those sources. > > To me, there are really 3 options here: > > 1) Only send info on light sources that are on spaces player can see. > This is safest and isn't hard to do, problem is that it is probably > mostly useless (vast majority of lightsources will not be visible to > player). > > 2) Send info for lightsources that illuminate any spaces player sees. > While this gives information away, one could argue it is a pretty > minor leak (EG, given how current client communicates light levels, > once could potentially figure out where light sources are based on > illumination of different spaces). It does complicate things some, > because we need to record location of light sources that illuminate on > the space - however, that probably isn't actually that hard, since > we'd have to go by 1 by 1 for the light sources and see what they > illuminate anyways - the issue here is that we now need to record that > info (light source and 10,10 is illuminating this space). > > 3) Send all light sources for map area, regardless if visible or not. > Easiest to do, but starts to give away a fair amount of informatin, > especially for non static light sources (hmmm - a lot of light behind > that wall - must be something there) - probably not a good option. Personally I think that option 2 is the best choice, though it's logic would be somewhat more difficult to code and arguably could give some information away. I think that the information given away in this way is rather minimal and unimportant. I think that option 3 would give away too much information, and option 1 would cause rather ugly display issues in many cases. > Likewise, this also means the protocol needs some support for negative > coordinates (player could be approach from west after all). I don't think this would be a major issue, just send a signed integer instead of unsigned. Also, though this is somewhat of a different topic, I think with these changes, would be a good time to try again at implimenting additive lighting: I am thinking the main advantage of additive lighting, is how it fixes display uglieness when a player who is lit up steps on a lamp, causing the overall brightness in the area to drasticly decrease. I think a good solution would be to do additive lighting with this restriction: add all no_pickup objects, and the brightest other object ontop of them. Alex Schultz