ID:1605307
 
(See the best response by DarkCampainger.)
Hello everyone,

I've been testing various things within the code and came up to an unusual problem which I'm unsure of the exact cause or nature of it to really know if it's just byond not handling it well or perhaps it's the way I coded it that may be causing the real issue here.

Basically I've created a rather large loop, but the loop is fairly delayed and doesn't cause any major issues... at least initially.

I define a variable as 0 and count to 255. When it reaches 255 it'll reset back to 0. While it's counting it'll do various things like flick an icon etc. Each time the loop is counted it sleeps by about 2 byond ticks, so sleep(2) is typically used.

An example of the above would be like...


proc

setup()

counter ++
if(counter == 10) flick("something",src)
if(counter >= 255) counter = 0
spawn(2) setup()



Now running this in single mode causes no crashing or anything, but hosting it does eventually crash the clients computer but not the server.

The above is just a simple breakdown of the type of thing i'm trying to do. There are other flicks and general variable changes that do occur such as setting something from 1 to 0 or vice versa. Nothing serious and each setting individually has caused no errors or crashes to the server itself. It's seems to be related to the counting itself or maybe the flicks are overloading the clients computer i have no clue.

Anyone have any thoughts on this?
I think you should be using a loop instead of using spawn to do what a loop would do better. Try that and see if there is a difference.
Well I was messing with it more turning off the flicks and such and it didn't seem to help but something did occur when I had more people log in... the crashing appears to only occur once then when they relog and keep trying it doesn't do it anymore.
proc
setup() // mine
set background = 1
var/counter = 0
var/shouldcount = 1
while(shouldcount)
counter ++
if(counter == 10)
flick("something", src)
else
if(counter >= 255)
counter = 0
sleep(2)

var
counter = 0

proc
setup2() // yours
counter ++
if(counter == 10)
flick("something",src)
if(counter >= 255)
counter = 0
spawn(2)
setup2()

mob
verb
ActivateSetup()
global.setup()

ActivateSetup2()
global.setup2()


I tested both of these and neither caused a crash when hosted in Dream Daemon for me. Perhaps it's something else in your code?
How did you post a code snippet like that? I was trying to do that in my example...

That being said though... i didn't set background = 1 so maybe that could've been my undoing. I forgot about it admittedly. Also I made a mistake and had set sleep(1) instead of 2

Edit

Actually I did set background = 1 ... this is so strange to duplicate the world.fps is also 40 would that make a difference?
In response to Cecil81067
You need to make it in dm tags. <"dm"> <"/dm"> without the quotes.

As for the FPS, not really. Whether the FPS is 10 or 60 spawn(2) is always 2 tenths of a second. Just in case you're wondering, I did my test in a 30 FPS environment.
I looked it over and also realized i was doing something slightly different.

example:

proc

setup()

Start

counter ++

if(counter == 128) flick("something",src)

if(counter == 255) counter = 0

spawn(1) goto(Start)


I know i'm being a bit vague sorry about that... I'd post the whole code directly but i feel it might be too much info as a lot isn't defined innately.
goto most definitely isn't needed here, but there's nothing else wrong with it. We're going to need more info in order to see what could possibly be going wrong.
Alright, hopefully it's not too big of a mess.

        Start

while(length(TurnList) <= 0)
battleatb()
for(var/mob/M in view(src)) if(!M.takeaction && M.ATB >= 255) TurnList.Add(M)
sleep(2)

for(var/mob/M in TurnList)
if(!M.takeaction && !M.btl_action && !M.btl_target)
M.battle_ready()

else
M.battle_action()

TurnList.Remove(M)

if(M.client))
var/delay = 0
while(M && M.takeaction && delay < battle_delay) {delay += 0.2;sleep(2)}

spawn()
if(endbattle) {battle_reset(src);return}
else goto(Start)


Don't judge me >_>
That won't compile, as you have an unmatched parenthesis:

if(M.client))


Also, you want to avoid using goto.
I don't really want to avoid goto just cause it's bad though unless you have very specific reasons for me not to. Also that won't compile cause it was edited.
In response to Cecil81067
Because what was edited?

I wouldn't say there's a specific reason not to use goto. But I will say it has the potential (will) to make your code jumble-y in the long-run.
istype(M,/mob/player) figured it was easier to use client then istype

I'm not too concerned about the jumblyness as I have a set reason for doing it this way in the long run. I understand some things should be avoided but using goto in this way shouldn't be bad unless you believe it is. And by bad i mean it's what's causing my game to crash.
Best response
If your players' clients are crashing, and not your server, then that's potentially a BYOND bug. Unless you're somehow spamming the client with hundreds of winset()/flick()/ect calls, it shouldn't crash.

When you say the client crashes, do you mean it
A) silently exits
B) exits with an error
C) freezes/hangs and does not respond
D) disconnects from the server
C) Freezes/Hangs and does not respond.

Once they disconnect and reconnect however it seems to be fine and no longer causes a crash. So once I see the error happen it doesn't seem to come back it's very mysterious and i'm still trying to get it to both come back so I can be certain of what I did wrong heh.

Also the worst I really do atm is flick the icon, everything else is just subtly changing variables, editing a list, or resetting the counter. Nothing too serious or strenuous. I was doing this as a stress test and happened to notice it crashing on the clients side and not the servers so I was unsure of how to actually report it.