ID:113219
 
BYOND Version:482
Operating System:Windows XP Pro
Web Browser:Internet Explorer 9.0
Applies to:Dream Daemon
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Descriptive Problem Summary:
I originally posted this http://www.byond.com/members/ BYONDHelp?command=view_tracker_issue&tracker_issue=3014
But they told me I gave too much information. So I'll give less.

Steps to Reproduce Problem:
Copy and paste the code below and use the verb. In a few hours, it'll crash. The verb, not Dream Daemon. DD won't even report an error. I gave code that crashed much, much sooner than that, but you didn't like it because it wasn't what I actually used, even though it does do what I described, and I tested it to make sure it did. So here's what I actually use. At the moment. I've switched between like six different ways of doing it and they all crashed and I mentioned that, but you only wanted the one I use right exactly now. So compile it, run it, hit the verb, and find something else to do until it crashes. The command is called "Restart" because the proc is initially called by a loop in world/New(), but it crashes after I restart it with the verb, too.

Code Snippet (if applicable) to Reproduce Problem:
mob/var/status

mob/verb/RestartStatusThing()
set hidden = 1
spawn() while(1)
sleep(20)
StatusUpdater()

proc/StatusUpdater()
for(var/mob/M in world) if(M.client)
var/bar = winget(M, "MainWindow.input", "text")
if(bar == "" || bar == "Say \"" || bar == "Emote \"") M.status = ""
else if(findtext(bar,"Say",1,4) || findtext(bar,"Emote",1,6) ) M.status = "Typing..."
else M.status = ""
if(M.client.inactivity >= 6000) M.status = "Idle"


Expected Results:
It loops forever.

Actual Results:
It loops for a few hours and then crashes silently. Dream Daemon does not crash or report the error, but the proc stops getting called.

Does the problem occur:
Every time.
In other games?
I can't back this up because you won't let me use the code that I've tested in other places.
In other user accounts?
I imagine, but untested.
On other computers?
I imagine, but untested.

When does the problem NOT occur?
It always occurs.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
I'd say it's been doing this for at least five versions.

Workarounds:
What I posted is my workaround: A hidden admin verb to restart the loops after they crash.
How did you determine it crashed? Is it because the status variable stopped updating? I'll see if this thing crashed on my end when I wake up.
Didn't crash, but I did notice something. In that example the only verb is "RestartStatusThing()" Which means that unless you know about the other hidden commands, The inactivity will not go back down unless you click "RestartStatusThing()". So when status gets stuck on Idle, It might appear as if it is no longer running. I have my profile running, and the procedure is still being called. I'll leave it on for a bit, and see if it does anything else.
Tell me if this resolves your problem.
I made it just for you. :3
world/New()
..()
spawn() while(1)
sleep(10)
StatusUpdater()

mob/var/status=""
client/var/typeCounter=0
client/var/lastSaid=""

proc/StatusUpdater()
for(var/client/C)
var/bar = winget(C, "MainWindow.input", "text")
if(bar==C.lastSaid)
if(C.inactivity >= 600 && C.typeCounter)
C.mob.status = "Idle"
C.typeCounter+=10
else
C.lastSaid=bar
if(findtext(bar,"Say",1,4) || findtext(bar,"Emote",1,6) )
C.mob.status = "Typing..."
continue
C.mob.status = "Active"
C.typeCounter=0

mob
Stat()
stat("Status",status)
For some reason my two loops are crashing a lot less often. I dunno why. I haven't updated BYOND on my server for a while, and all I did was add a spawn to one of the loops (after "for(var/mob/M in world) if(M.client)" in the loop given in the report), but both of them are lasting longer.

Also, the two ways I check to see if the loops has crashed are the profiler, and whether or not the statuses stop updating. In the example, I guess you can't stop being idle without using the hidden verb, but I haven't tested it outside of my project. I had other loops that I did test outside of my project that did crash, but I was told three or four times to only post the code I'm using in my project, so sure.

Your code might help, but I don't really see why it would fix it. It seems more efficient, but this is a really ugly bug for a user to test out, since when the loop crashes it doesn't give any errors at all, and in most cases the loop iterates for two weeks before it finally crashes. I may try it, but it'll be a while before I know if it crashes or not.