ID:156815
Jul 21 2010, 2:04 pm
|
|
I know they're bad but there's some situations where I can't see a way around using them, how could I make a carousel of events and world restores without actually making the proc go over and over, how do I give them a break automatically so they don't stack the lag and kill my game?
|
Bustercannon wrote:
I know they're bad but there's some situations where I can't see a way around using them, how could I make a carousel of events and world restores without actually making the proc go over and over, how do I give them a break automatically so they don't stack the lag and kill my game? There is nothing inherently wrong with infinite loops. The issue is infinite recursion: // BAD: |
In response to Garthor
|
|
Infinite loops are not any more prone to causing lag than other code. Like anything, you need to consider how often the code will run and what the code does. If your attack command does some really complex calculations and you let players attack every tick, it could cause significant lag even though it's not an infinite loop.
Write the code and see if it is laggy. If it is, try to figure out why (do you need more of a delay between iterations? are you doing too much work each iteration?). Once you have the code written you can also ask for suggestions on ways to cut down on the lag. Without knowing what you're trying to do (or if it would even be laggy) it's hard to suggest ways to help. As Garthor tried to suggest, this is a bad way to create infinite loops: proc The reason is that every time you call a proc, BYOND needs to remember what proc you came from (so when the second proc ends you can return to the right spot in the first proc). This list of locations to return to takes up memory. The badloop proc doesn't end, it just keeps calling itself, so this list will grow and grow. After enough iterations of the loop, you'll run out of memory! The other two methods are better because they avoid this problem. Garthor wrote: // BAD: badloop calls goodloop? That's a little redundant, but not as bad as you probably meant it to be. Since none of these loops have delays they're all bad. I think you should look into the issue more, too. Spawn looks like it creates another thread, but really it just schedules the delayed execution of a block of code (which is what sleep does). The underlying layers don't need to use multiple threads to give us the illusion of multiple threads. |
For example, an infinite loop involving with a weather system can be initiated by calling it through world/New(), pretty much making sure it is called only once per run (per say). Health regeneration for /mob? /mob/New().
As for breaking automatically so it doesn't stack up, have a failsafe system going on. Make the loops break if a condition is satisfied or prevent the loop from happening if it is already called (with a use of a variable or some other marker).
If you want a more specific answer, you'll have to provide a more specific scenario.