I’ve been running Simulation for some time today and it keeps crashing after a few minutes for a specific battle: Eserem vs pawelliz . I have attached a screenshot of the JS log output.
Unfortunately it doesn’t restart automatically, so you have to reopen the tab each time this happens and because it happens so often you cannot just leave a tab open to simulate for long periods of time.
Browser: Google Chrome Version 33.0.1750.154 m, OS Win7 x64
I have a similar issue. Simulation between daruba and mich55 does not terminate at all, even after 10 min or so.
Absolutely true. After a while all the tabs with opened simulation are filled with simulating a battle between daruba and mich55. It’s not just some kind of waiting, it really loads the cpu up to 100% per core.
http://userscripts.org/scripts/show/486640 created a short stupid script for greasemonkey that will restart simulation tab if mich & daruba are noticed together. May be useful until the bug is fixed. Will it work in chrome? ‘bla bla bla, use only google store for scripts…’, so no idea.
I’ve just instituted a 4000-statement-per-chooseAction-call limit on Greed, which makes players’ code start getting run less often if it’s really slow (which was the case for Daruba’s human code there). I think that might solve this problem. If the code straight-up infinitely loops, it’ll give up after several seconds, but we don’t have a good way of removing that game from the queue by assigning a defeat to one player yet (since we don’t know which one looped). At some point I’ll figure that out.
If we see similar problems in other levels, like Gold Rush, I can add appropriate statement limits there as well.
Is not this limit too low?
Say that you use 10,000 statements in one call, out of a budget of 4000. Your code will be delayed two frames, then run again. End result: your peasants don’t change course quite as responsively (0.75s instead of 0.25s) and your building rate might be a bit slower (but that’s usually gold-limited, not time-limited), and you (and anyone playing against you) gets to play in a world that simulates 2-3x as fast, which is more fun than having to wait 20 seconds to see changes.
Maybe the limit isn’t quite right–would love more feedback on this–but after watching some playtesters playing against some really slow O(n^2) opponents, we thought it’d be nice to give a small advantage to efficient code and prevent slow code from degrading the player experience. I would hope that anyone trying to do something that really needs O(n^2) or worse solutions would find a way to not rerun their entire nested loop on every frame. You can see which items have changed in O(n) time each frame, for example, and just update your coin-gathering algorithms according to that.