Wow, and my solution will be to add an asynchronus var to the bomb call that defaults to 1, and if it is true, it will spawn() and then strategically sleep().
If it lags everyone out, tht means that it wnt into a very long loop and denied flow-of-control to the unseen server functions that update the clients.
Hint: The server seems to try to handle every code in what I assume ot be a queue, and then does non-code updates, including networking, and adding delays so that the maximum is 10 ticks per second or less, if you change the in-game setting to be less. So, if the clients time out, then something is looping without a sleep(), and going on for an intolerable ammount of time.
So, the fix is to make it asynchronus so that if it continues, the effect is broken periodically to let the server keep the clients from timing out.
Also, a server can(and will) crash during such a loop, for example if it has a stack overflow or malloc failure because the loop accumulates data or recurses, and it goes on for too long without cleaning up or finishing. The fact that the server merely froze for two minutes means that it was well-designed, so did not recurse enough to crash, and didn't accumulate data that fast either, but was poorly implemented, because it didn't pass of flow-of-control occasionally.
Also, if any of them are reading this, all this is my assumptions based on a decent understanding of some problems with the older powernet code, and an understanding that the code is likely not multithreaded to make it easier to work with, since you don't have to worry about a variable being accessed by another proc mid-statement.
Format:
sleep(Delay)
Args:
Delay: The amount of time to sleep, in 1/10 seconds.
Pause the current proc (and its callers) for a specified amount of time. If no delay is specified, it will be scheduled to resume as soon as other immediately pending events are processed.
This implies that BYOND has in internal queue for each pending tick, and sleep and spawn append the proc call to the end of the queue {n} ticks later, or the current one if 0.
Furthermore, as a long loop will lag clients as well, it implies that non-code server events happen between ticks, so using sleep(0), spawn(0), or not delaying at all will perpetually postpone updating the clients until the code is finished, and after a certain delay, the clients assume that the server has crashed, and disconnect. So, by adding an occasional sleep(1) to your long code, you are delaying it until after the server has had a chance to inform the clients that yes, in fact, it *is* still running.
Edit: and, reading the manual, it seems that sleep(-1) was *designed* for this. Also, set background
Edit again:
Rethinking some of that, maybe client communications are handled from within the code anyway.
However, it still won't happen within a loop than never sleep()s and is not
set backgrounded.
Poll
67 (25.9%)
Author
Topic: Space Station 13 *READ RULES ON FIRST POST* (Read 821824 times)