a proc level var (that holds a client) is getting set to null when no sleeps or calls to non-byond procs (that could be sleeping) between the null check at the top of the proc and when this error happens.
-
runtime error: Cannot read null.sending
proc name: send asset (/proc/send_asset)
source file: asset_cache.dm,34
Code:
/proc/send_asset(var/client/client, var/asset_name, var/verify = TRUE)
if(!istype(client))
if(ismob(client))
var/mob/M = client
if(M.client)
client = M.client
else
return 0
else
return 0
if(client.cache.Find(asset_name) || client.sending.Find(asset_name))
return 0
client << browse_rsc(asset_cache[asset_name], asset_name)
if(!verify || !winexists(client, "asset_cache_browser")) // Can't access the asset cache browser, rip.
client.cache += asset_name
return 1
client.sending |= asset_name //line 34
That last line is triggering a null reference error randomly..
There is NO non-byond in procs getting called from start to here. (so no random code that could be sleeping in other procs)
There are no sleeps, no calls to procs that could sleep, so i'm fucking confused.
the client var is properly checked, it can't become null unless something sleeps.
It's always that line too, meaning browse_rsc either sleeping but not listed as such on the reference.
or (more likely) << is checking for disconnected clients and del()ing them, which is not expected behavior at all, and it's not reasonable to expect people to put if(client) lines after every <<
Edit: testing has shown that winexists is sleeping.
i had assumed the server knew info about the existing windows in a client, since they can't change from the client side after connection, but that proved to be wrong.
i had assumed the server knew info about the existing windows in a client, since they can't change from the client side after connection, but that proved to be wrong