ID:1991401
 
BYOND Version:509.1315r2
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 47.0.2526.27
Applies to:Dream Daemon
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
So we have our own lighting system, and long story short, after spending 5 hours trying to figure out what i thought was a bug on our end, I've figured out that view() isn't working right.


/datum/light_source/proc/add_effect()
// only do this if the light is turned on and is on the map
if(!owner || !owner.loc)
return 0
if(radius <= 0 || cap <= 0 || luminosity <= 0)
return 0

effect = list()
var/turf/To = get_turf(owner)
var/range = owner.get_light_range(radius)
for(var/atom/movable/AM in To)
if(AM == owner)
continue
if(AM.opacity)
range = 0
break

for(var/turf/T in view(range, To))
var/delta_lumcount = T.lumen(src)
if (debug_light)
world << "working on turf \ref[T] ([T.x],[T.y],[T.z]) lumen=[delta_lumcount]"
if(delta_lumcount > 0)
effect[T] = delta_lumcount
T.update_lumcount(delta_lumcount)

if(!T.affecting_lights)
T.affecting_lights = list()
T.affecting_lights |= src

return 1


(all changed turfs will then process their new light count numbers the next lighting tick, and set the turf's luminosity to 1 if it's lighting level is high enough, and set the alpha of a bright white blend_mutiply object on every turf based on the lighting level. (with a lumcount of 10 being an alpha of 0))

The key example will have radius be 4, and unchanged by get_light_range(). (get_light_range justs makes sure its not above some number, that changed by type, movables lower, non-movables higher, lowest is 5, highest is 8)

working on turf [0x1006737] (159,104,1) lumen=1.66667 <--- this is the center turf
working on turf [0x1006835] (158,105,1) lumen=1.07741
working on turf [0x1006638] (159,103,1) lumen=1.25
working on turf [0x1006836] (159,105,1) lumen=1.25
working on turf [0x1006639] (160,103,1) lumen=1.07741
working on turf [0x1006738] (160,104,1) lumen=1.25
working on turf [0x1006837] (160,105,1) lumen=1.07741
working on turf [0x1006537] (157,102,1) lumen=0.488155
working on turf [0x1006834] (157,105,1) lumen=0.734972
working on turf [0x1006538] (158,102,1) lumen=0.734972
working on turf [0x1006539] (159,102,1) lumen=0.833333
working on turf [0x100653a] (160,102,1) lumen=0.734972
working on turf [0x100653b] (161,102,1) lumen=0.488155
working on turf [0x100663a] (161,103,1) lumen=0.734972
working on turf [0x1006739] (161,104,1) lumen=0.833333
working on turf [0x1006838] (161,105,1) lumen=0.734972
working on turf [0x1006635] (156,103,1) lumen=0.349051
working on turf [0x1006734] (156,104,1) lumen=0.416667
working on turf [0x100653c] (162,102,1) lumen=0.164354
working on turf [0x100663b] (162,103,1) lumen=0.349051
working on turf [0x100673a] (162,104,1) lumen=0.416667
working on turf [0x1006839] (162,105,1) lumen=0.349051


Visual (center turf is the turf my ghost sprite is in, my ghost has the ability to see turfs that have no luminosity) (lighting levels risen in photoshop to make it more visible):



Basically, the turfs at -1,0 -2,0 -1,-1 -2,-1 should be getting returned by view() and aren't. (158,104, 157,104, 158,103, 157,103) (the 2x2 square of black turfs to the left of my ghost sprite)

These 4 turfs will be called t1 thru t4, in left to right, up to down order from this point on.

This example happens every time, every round, at this spot (as well as other seemingly random spots, that don't change round to round, compile to compile, version to version.)

Happens as well in 509.1312, 509.1313, 508.1299, in the same spots.

None of them or their items have opaque set to anything other than 0

I can't figure out why this is happening,

I do know this: If i start putting 4 radius tile light casters on different tiles of t1 thru t4, the behavior changes round to round. (this is on a test server with me only connected). in one round, t4 would only light up t4, t3 would light up t3 and t4, t1 and t2 would light eachother up,

in another they would only light eachother up.

in one, t4 was the same, but t2 lit up t4, and t1 and t3 lit each other up.

I have an ingame tool i can use to see the variables of an object, and even open the vv for referenced objects.

I went thru t1 thru t4 as well as the turfs right of t4 and t2, checked every turf's opacity, opened up the contents lists of the turf, and checked the opacity of the related turfs.... all 0.

If I manually set the luminosity of a random object to 4, then back down to 0, everything works fine.

If i start deleting items on the related turfs, it fixes, but the item that fixes it changes, and never had opacity. (and some times, it's not fixed by this)

It would seem that view(range, turf) is taking into account luminosity in odd cases, when as far as i know, that should only happen with mobs. Or if certain items are deleted in the area

Versions tested: 509.1312-1315 508.1299 (i'll update this as i test more versions)

Is there any chance of getting this issue to show up in a demo?
doubtful...

When I push my latest branch of changes I'll give you some clear and concise instructions on getting it to happen in ss13, as well as a permalink, then you can run it in a debugger and try to see what's happening. But outside of that, it seems like this would be hard to trigger in a random demo project.

The fact it is looking at or is affected by luminosity at all seems weird. Am I correct that using view() on a turf doesn't attempt to take into account luminosity?
Luminosity is taken into account with view calculations, yes. If an area is not lit, then the spread of light determines if a turf is visible or not. Infravision is different; it uses a form of luminosity that goes through walls, and also you can flag a mob as being able to see in the dark. (The viewer's sight flags are taken into account as well.)