Main loop reset! Stage: waitForUsers



  • Ah ok. Server version is 3.0.0.

    node_modules\isolated-vm\package.json:

    {
      "name": "isolated-vm",
      "version": "1.5.2",
      "description": "Access to multiple isolates",
      "main": "isolated-vm.js",
      "types": "isolated-vm.d.ts",
      "scripts": {
        "install": "node-gyp rebuild --release -j 4",
        "lint": "find src -name '*.cc' | xargs -n1 ./clang-tidy-wrapper",
        "test": "node test.js || nodejs test.js"
      },
      "repository": {
        "type": "git",
        "url": "git+https://github.com/laverdet/isolated-vm.git"
      },
      "author": "https://github.com/laverdet/",
      "license": "ISC",
      "gypfile": true,
      "bugs": {
        "url": "https://github.com/laverdet/isolated-vm/issues"
      },
      "homepage": "https://github.com/laverdet/isolated-vm#readme",
      "dependencies": {
        "electron": "^1.8.4",
        "electron-rebuild": "^1.7.3"
      }
    }
    


  • Have you guys found a solution yet? I am having the same problem on a raspberry Pi.

    I can connect to the Server but cant run any code in the console.

    Would be nice if we get this working



  • @skrat17 I got a Main Loop Reset, but without the other errors, although I get the same error in backend.log. I downgraded node to 8.11.3 and this problem went away.



  • I am still getting this issue with the steam version.



  • Has anyone fixed this yet? I still get it about every half hour and have to restart the server every time.



  • @unforeseen Could you tell how you downgraded node js to 8.11.3? And is this possible with steam client? Thanks



  • still get this error

    Main loop reset! Stage: waitForUsers
    Game time set to 6
    Main loop reset! Stage: waitForUsers
    Game time set to 7
    Main loop reset! Stage: waitForUsers
    Game time set to 8
    ...
    

    node.dll version is 8.9.3.0 cant find 8.11.3



  • I know this is an ancient thread, however I am running into this problem on a fresh install of Screeps on MacOS. After about 15-20 minutes, the local private server is useless and requires a manual force-quit/kill from the OS to terminate.

    The first indication that something is wrong is on the client after about 15 minutes, the client will start to stutter, and I see the message "Main loop reset! Stage: waitForUsers" in the server console - engine_main log. It's at this point that I notice an uptick in CPU usage, which started around 50%, system-wide. CPU will go up by about 10-15% on every time I see a reset error messge. The process responsible is called "Electron Helper." After about 10 minutes, and 4-5 more times of seeing the error message, the CPU is now burning at 100%, the client has completely stop moving (but is still rendering at 60-70fps), and every single tick results in a main loop reset error.

    At this point, my only option is to quit the server from the File->Quit menu, but that doesn't actually cause the CPU usage to go down. There is now an orphaned process called "Electron Helper" that must be forced killed. It appears to have been spawned by the server, but it doesn't exit when the server exits.

    Some potentially pertinent information about my particular macOS setup: I am running Catalina 10.15.2. I have many versions of Nodejs installed, and manage them with NVM as part of my daily work. My default linked version of Nodejs is v12.4.0. I am running a fresh install of Screeps server version v4.0.5 from Steam, and I have not modified it any way. I'm not sure if Screeps will use my system's version of Nodejs or a packaged version, if there is one.

    I may try setting my global node version to something different to see if that helps.



  • I fixed this by completely deleting all files from the screeps game directory and then validating the game. This effectively creates a fresh install.

    I had this on two computers..



  • @jerdaz Unfortunately this didn't do much, as this was fresh/clean install. I tired this on a completely different windows-based computer and observed the same stalling behavior, so it doesn't seem to be related to my particular macOS setup.