Alex Schultz wrote: >> >> Right now, darkness levels is calculated for each player. This >> doesn't make a lot of sense. Imagine scorn at night - the >> darkness/brightness for all the spaces are the same for all players, >> so there is no reason that how dark/bright the square is should be >> calculated for all the players. So rather, just like there is a >> 'light' value for each map space, a darkness field would be added, and >> the server woudl fill in those values universally. >> > Makes sense, and I think I know how to implement such. It wouldn't > involve much more than moving some of the algorithms that are normally > in los.c into map.c. I think I might be able to integrate this part of > what you mention here into my lighting patch if you think that's a good > idea. I'd consider you're current patch and what I describe here as seperate projects - there is no reason you're current patch shouldn't go in, and then work on this, since I think it is a bit bigger change, and there isn't any real dependency on the other patch. I'd also suggest addition of a field in the map header to something like 'update_darkness'. When something happens on the map that would change lighting/darkness, it sets that. When update los is called and that is set on a map, then it goes and updates the map - this is almost certainly going to be more efficient than doing it everything when the object is inserted/removed. > >> >> There are a couple oddities that would have to be handled: >> 1) players currently can see at least a few spaces on outdoor maps - >> this would need a little special handling. > > > I don't think that will be too hard to just adapt the existing los.c > logic with very little changes to all of this in such a way that this > part would be kept intact. yeah - it may make the most sense for LOS to calculate true LOS issues, and then look at the darkness levels on the map and copy those into the LOS array as needed - then, special customizations based on the players attribute could be done at that time. >> >> However, related to these changes would be changing how the client is >> notified of light changes. Better effects can be done if the client >> knows where the light sources are - that'd actually use less bandwidth. > > > Very true, but that would require rather widespread changes to all of > the lighting code, and we would still have to not sent the client data > for that which that can't see at all which would depend on calculating > lighting data on the server end. Also, we would still have to worry > about monsters knowing about such lighting. yes - the biggest issue is light sources the player can't see. The hardest part is those light sources the player can't see but which they can see the effects off. Since they see some of the light emanating, might not be bad to send the player location of that (it is something that could be inferred), but gets hard to handle. I'd have to think about this more on the best way to deal with handling this data, and figuring out a fast way to calculate that information.