Good stuff so far! It's a shame that lighting in general is so blocky - a rounded effect would be so much better, though I expect that's what you mean by using a bunch of sexy tables. I expect Laplace transforms come in somewhere (they usually do )<sup>1

1</sup>No, I never got to learn about them either.

Yeah exactly.

The lighting above is purely server-side (the numbers, not the visuals of course). It needs to be for light-sensitive spawns, etc. to work.

As Tehill suggests, to get it looking nice we need to translate the squares into a circular gradient client-side, although I'm not sure how hard that will be -- anything from quite to bloody I'd guess. Hopefully not impossible.

Before that, I want to get the server-side stuff sorted out, get doors working properly. I think I figured out what was tripping me up, but I'm still getting the crashes I posted about earlier. Not entirely sure what's going on there yet.

I need a formula to convert a 0-255 value to a 0-n range, so that if the the higher the in number, the lower the out number. Does that make sense? This sort of thing makes my head hurt. Stoopid maths.

Put in 255, get out 0. Put in 0, get out n.

what?

so you need to invert the number?

like (X-255)*-1

That would give you the inverted value on a 0-255 scale...

if you mean to cut 255 into chunks of 20 or so...

I don't know what your going for...

Yes - that was just to keep you on your toes. You'd probably get away with just the right hand half of the ?: conditional - depends how big n is. Maybe it should be 256 - x. Error would be virtually zero for small n, since you're converting the 255 -> 0 number to n-scale by multiplying by n /256 which is what the shift right 8 does, instead of n/255.

And this has to be integers of course, not float.

This is what I am doing:

2. There could be a greater range from light to dark (are there 7 current shades?  I'd like about 20...)

I'm not entirely sure what it's doing or why it's doing whatever it;s doing the way I think it's doing it. One or two of the comments don't seem to match the actual code, so I suspect the code has been changed but the comments have not.

But it is hardwired (in theory it's flexible, but in practice it's not) to 7 light levels. I've changed this so its a client option how many you have.

In itself this works well. ATM it looks the same whether you have 7 or 21, I am not sure why. I know you only have 7 darkness settiings in the server, plus 0 for true dark but in fact the actual brightness per square is 0-1280 or 0-255. It's very strange. It seems the server uses a 0-1280 value, which is then reduced to 0-255 range by the time it gets to the client which then reduces it to 0-7 only to use this value to look up in a table a 0-255 value again!

Something funny's going. on I need to sleep on it, but in theory we should be able to have each client displaying n light levels according to the user's settings, where increasing n looks nicer/'smoother' but costs more memory.

well for one thing, you only want 0-255 light values, because that is the technical limitation of RGB.  any more than that would be pointless, unless you are going for specific color light values.

The other thing is it might be limited to 8 values for transfer because of bandwidth.  If this is the case, making it 16 would be acceptable (to me) from an artistic point of view (I would add about 6-7 of those extra shade from current 0-3 because of the disparity between the darkness values).  If that means two byes?  (so 64 options? 16/64=4 different colors of lights usable in the game)

255 shades of light might be overkill, and i can see why it would be limited from a bandwidth point of view.  Even increasing it from 8 to any value would be at least doubling the bandwidth per tile.  I'm fairly confident when i looked at the code a while ago, i thought the server actually reduces it to 8 values...  Maybe I'm wrong.

Edit: you edited your post!