Hi there this is Marcel the author of the new sandbox environment, isolated-vm.

I think what you're seeing here is a tailcall optimization bug in v8. Essentially what happens here is sometimes v8 will generate infinite loops which cannot be stopped, this causes isolated-vm to panic. You can find the original v8 bug report here v8 issue #6933. The fix will be included in the next nodejs release, v8.10.0, but I don't know when that will be released.

In the meantime I've ported the fix to a branch on github: tailcall-backport. This branch is the nodejs v8.9.4 release but with this commit applied on top. I believe the Screeps guys are running this fix on the PTR as well. So please give that version of nodejs a try and see if it resolves this issue.

The results are indeed strange, but expected. [43, 44] and [22, 15] (room.controller) are both unwalkable. When the path finder can't find a complete path it will return a partial path which got the closest to the target. In the case where you're searching to [43, 44] the partial path just so happens to be a subpath of the optimal path. In the reverse the path finder managed to get closer by going around the obstacle, that's just a quirk of JPS. If you set the targets to walkable in the CostMatrix, or use range: 1 on your target you'll get an optimal path in either direction, because it will find a complete path in that case. You can also examine the `ops` property on the return value from PathFinder.search and notice that it uses far fewer operations because it's not exhausting the entire room.

I think this is a pretty common mistake new users run into with PathFinder. It is mentioned in the docs (see the "Important" section) but it may be worthwhile for us to add some kind of warning when requesting an impossible path.

Path length is the wrong metric to be looking at, you should be looking at path cost. Increasing `heuristicWeight` will, by design, return non-ideal paths. If you don't care about walking on roads or walking over swamps you should adjust those costs accordingly.

Yes it seems that the path finder is venturing into other rooms too frequently. This isn't costing a whole lot of CPU time, but it is counting against `maxRooms` which will make it so you can't find longer paths. I have a fix ready that will reduce the number of rooms the path finder looks at. Be on the look out for that later.

However, there are some changes you can make to your code right now to help out. This will also be helpful after the fix is live. First is { plainCost: 2, swampCost: 10 }. In the case that no road exists, this will increase the search area of your path exponentially as the path's length increases. I notice that your transport creeps have equal parts MOVE & CARRY. In this case you can set { plainCost: 1, swampCost: 5 } and drastically reduce the path finding complexity (by not searching for roads). Additionally if you set `heuristicWeight` (a good starting point is 1.2) you can really improve search speed without much loss of accuracy.

Actually this is my fault, sorry guys. I was watching a replay where someone had spawned in the room next to the current room. The creeps were actually getting stuck because of the protection. Please disregard

While replaying history, creeps leaving the room just get stuck on the border. Everything still works, you just end up with a bunch of motionless creeps sitting around on the border.

Try again, there was a missing folder.

There's step by step instructions on the github.

Uploaded here. It's super rough and buggy right now, but I won't be able to work on it for a while so I'm uploading what I have in case people want to play with it.

https://www.youtube.com/watch?v=wFAWe3kCXgI

Coming soon to a Chrome browser near you~