I FINALLY get the difference between sleep() and spawn() procs

ID:1400083
 
Oct 16 2013, 5:53 pm (Edited on Oct 21 2013, 6:36 pm)
I didn't get this one for like years. I know I am an honors student at my college but this went really slow for me. I didn't get it until someone explained it to me. So for those who don't get it now I will say what they are: sleep() stops all statements below it, spawn() stops all statements inside it but others below spawn continue simultaneously as soawn. There are different times you have to use either.
Oct 16 2013, 8:08 pm
I got it once. Forgot how it worked again. Got it again. Forgot again. Now I got it again and I will forever remember it. Took me 6 years to learn it. Kind of sad in my opinion. :(
Oct 17 2013, 5:00 pm
Honors in college? What classes?

Sounds to me like you two just suckkk, though.
Oct 17 2013, 5:28 pm
That's dubious, simple by their names at the least. Literally, spawn something after x time, sleep the code until x time is passed.
Oct 17 2013, 6:49 pm
I never really liked the name 'spawn' for the spawn() proc/command. True story; when I started programming in BYOND I was trying to use spawn() to create objects.
Oct 17 2013, 7:46 pm
In response to Doohl
Doohl wrote:
True story; when I started programming in BYOND I was trying to use spawn() to create objects.

Wow, I'm really not the only one that thought this way. That makes me feel slightly better.
Oct 20 2013, 11:19 am
I don't really use spawn() and sleep() much in my projects, though I do know what they are used for. Sleep() is used once in each of my projects, which is only to sleep the main update loop.

world/New()
    ..()
    spawn()
        while(TRUE)
            // update code goes here.
            sleep(world.tick_lag)
    return src


The spawn()ing of the update loop allows the world object to be returned. Usually inside of the while loop I'd have a function called _Update() which handles the updating of specific objects.
Oct 20 2013, 11:38 am
The loop should definitely not be within world/New(), that's for sure. You should have as little code inside of world/New() as possible. You should have a proc that does the looping instead.

world/New()
    ..()
    spawn() WorldLoop()

proc/WorldLoop()
    while(TRUE)
        // update code goes here.
        sleep(world.tick_lag)


You should also not be using 'return' in world/New() =P
Oct 20 2013, 10:52 pm
It shouldn't matter too much if the code is spawn()ed whether or not it lies inside of a proc on its own. I actually do quite a bit of initialization within world/New(), called in separate global procs just to break up the code into more convenient blocks. I don't usually return in world/New() but if anything, I don't think it hurts matters.
Oct 21 2013, 8:35 am
Except that returning the wrong value inside of world/New() will cause your game to fail start-up with a 'bad world' error. As for it mattering if you have a bunch of code inside of world/New() -- it doesn't, but it's sure a lot easier to find problems with things if said things are executing on their own. A callstack error pointing at a big ol' mess of world/New() isn't quite as helpful as one pointing to a much smaller proc. Especially if you do a release build without debug mode enabled.

It's also better for code readability.
Oct 21 2013, 2:54 pm
I hate seeing "spawn()" in code with the parentheses and no number. It's a minor peeve, I guess.
spawn while()
   ...

spawn
    while()
        ...

After finding out that sleep never requires parentheses, I'm starting to dislike including them as well. I'm just crazy.


I've never had a problem with not returning anything in world/New(). The reference doesn't say it has any significant return value, and it says there's no default action, so ..() is only necessary for multiple overrides. The only New() that has a significant return value is client/New(). Other procs that use return values that people often leave out is Move() or Enter/Exit().
Oct 21 2013, 5:20 pm
Personally I prefer using spawn() and sleep() with parentheses. I use them like procs, despite them not necessarily being procs in the first place. However, it keeps things consistent.

Though I know how much you like to screw up consistency, Kaio. :P

For one you regularly use var x instead of var/x, which is downright crazy. But then again, maybe I'm crazy for thinking that's crazy. We're all crazy!
Oct 21 2013, 5:23 pm
In response to Doohl
At least I'm super-consistent with my apparent inconsistencies.

This is another case of unnecessary parentheses:
new type ()

//  worst-case scenario:
var type/object = new type ()

//  instead of:
var type/object = new