Posts made by The_General

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~

Why is this intended behavior? As it stands now, for example, if your controller is just about to hit RCL7 and gets downgraded you're in much better shape than if your controller had just passed RCL7.

Example:
Controller is RCL6 w/ 3.5m (out of 3.6m) progress towards RCL7
-> Downgrade to RCL5 w/ 3.5m (out of 1.2m -- 291%) progress towards RCL7
-> upgradeController() once
-> Upgrade to RCL6 w/ 2.3m progress towards RCL7

Next example:
Controller is RCL7 w/ 100k progress towards RCL8
-> Downgrade to RCL6 w/ 100k progress towards RCL7
-> upradeController()
-> Still RCL6 w/ only 100k progress

Obviously we should be avoiding controller downgrades, but the current mechanics are a little weird. Perhaps progress should be scaled down to match the lower RCL. So in the first example, you were 97% of the way to RCL7. When it gets downgraded you could then be 97% of the way to RCL6, or 1.1m.

Anton, now that I'm thinking about it I think the fatigue change with transferEnergy() may have unintended side effects. Imagine I have a link and storage next to each other, with a creep sitting there whose role is to just take energy out of the link and put it into storage. Right now I can just have a creep with 1 MOVE and several CARRY parts to transfer the energy. If I want to transfer energy from link -> creep -> storage I would need to have equal MOVE and CARRY parts.

I know other users do something similar, check AzuraStar in W5N7. He has a chain of CCCCCM creeps from his miner + link to storage. I remember in the EP there was a player (I think maybe dt7?) who would build a maze of extensions and fill the maze with CCCCM creeps and they would transfer the energy deep into the extension maze to fill it up. In those cases we'd have to add MOVE parts even though the creep never actually moves, which seems a little counterintuitive. I guess the creep is MOVEing energy so it kind of make sense. Anyway, just food for thought.

The cost of the parts isn't too bad, but right now I'm noticing that my biggest bottleneck isn't actually getting the energy, it's building the creeps. My spawns are running non-stop to create enough courier creeps, so any time I need to spend more time spawning I get grumpy. That's actually why I turned off my Source Keeper code, it was just too many parts to make sense without several RCL8 rooms.

Aww dang, 1 fatigue per 25 energy would certainly fix it as well. I stand corrected!

@dt7 I don't think it's a bug. A creep with 0 weight can move for free on swamps, that's a core part of the movement mechanics. drop and move are in separate command pipelines as per: Simultaneous execution of creep actions. Put two-and-two together and you get this trick. It's the same idea as the move+transfer trick-- which the Screeps team already mentioned in the latest Game situation review, so we know that's legit. Even if they made it so you can't drop and move on the same turn you could still move every 3 ticks on swamps which is faster than 5 ticks per tile by default. The only way to "fix" it would be to change the range of pickup() to be 0 instead of 1, and that seems a little overkill.

You still move half as fast on swamps even with this optimization, so terrain remains a factor when it comes to your energy logistics.

If you drop energy and move in one tick, and then pick up the energy from where you just were in the next tick you can move on swamps every 2 ticks instead of every 5 ticks.

You can see it in action here: https://screeps.com/a/#!/room/E8S1

A lot of my triggers are based on energy available for spawning and energy in storage, so it would be cool to see this in the overview panel.

I think that may be the case, but the behavior right now is ridiculous. If they don't want us using spawns we don't have the RCL it should just destroy the spawn I'm not supposed to have. Or return ERR_RCL_NOT_ENOUGH. Or literally anything besides what it's doing right now.

In E7S4, Spawn7 just doesn't do anything.

Game.spawns.Spawn7.createCreep([MOVE])

Hunter

Then nothing happens.

You used to be able to select a flag, click "Change Position" and then click into another room and move the flag into there. After the recent changes to flag placement this no longer works. I have to remove the flag and create a new one with the same name in the next room.

People in the IRC channel have mentioned that the bug specifically occurs on ticks when your creeps are moving from room to room. Not sure if that helps you track it down, but it's a lead.