Brendan Lally wrote: > This is a limitation the lighting code could do without also. If such a > mechanism were used for the sound code anyway, then it could usefully be > extended to the lighting code to allow coloured lights. I don't know how easy > it would be to implement client side, but it would be a nice way to give > feedback on some levels, or create interesting optical effects. > > The easist thing to do in that case then would be to store RGB values in the > stats for the light object, and then when they overlap have the resulting > colour be the weighted mean in each value. (based on proximity and strength > of source). Having the server figure out the color for each space is a complication it doesn't need. If/when colored lighting is added, it will be handled by the client. The server will still figure out what spaces are actually visible based on lighting, but won't care about the color. Conversely, the client should be able to apply properly lighting techniques by knowing where the light sources are and drawing properly shaded/dimmed circles of the right color. This will just allow for better handling of lighting in any case - right now, all the lighting mechanisms for the client are a bit of hacks and add a lot of complication in trying to figure out light value for all the spaces.