Suggestion for hard timeouts: save memory on ticks with a timeout

  • I hope the devs realize that the issue of hard timeouts has a critical bearing on the future of the game. Longtime players are leaving or considering leaving. 

    One problem is that it is near impossible to find where the source of the timeout is in your code. On a tick with a hard timeout, nothing gets written to memory and nothing gets reported to the console. It is a complete black box. 

    My suggestion: save memory even on ticks that have a timeout.

    If the server would at least save memory during the tick, that offers a way to investigate what happened. Your code can check in at various points and the last check-in before a timeout can give some pretty direct clues as to where it happened.

    I hope the devs can appreciate how frustrating it is to investigate this issue, we need more tools. It is pretty clear that a lot of players are getting hard resets for reasons that have nothing to do with their code. Mine happen frequently enough (a dozen times a day) that it seems likely I have a problem in my code, there is just no way to find it.

    It is getting to the point where I'm also thinking of saying goodbye. I've had a very fun time in screeps and I want to continue, but five months of investigating hard timeouts with zero leads is not fun.

  • YP

    I don't think that's possible .. afaik hard resets happens when the running node process don't react to the soft reset and has to be killed... so it would not react to save memory requests either.

  • I thought that might be the case. Perhaps just more information about what can cause hard resets. I've tried to trigger them on purpose to learn more about them, and it isn't easy. Not every infinite loop triggers a hard reset, this one just triggers a soft reset:

        while(true) {




    Infinite recursion seems to throw a maximum call stack exception. 

    The only way I was able to trigger a hard reset was to use JSON.stringify on a huge object. Sometimes that resulted in soft reset and sometimes a hard reset.


  • I would appreciate it if at least our logging was preserved or entirely asynchronous so that we would have an easier time triaging hard resets and infinite loop bugs.

  • Is seems that resets for CPU and hard resets have diminished somewhat (feels that way, but I have not data to support it).

    It would still be useful to have a process to save data as it is produced so that no code issues would destroy it.

    Could the Dev's give us any available methods that they know of to effect this "save of data".