Creep.move and Creep.moveByPath are called by Creep.moveTo, as you can see here. You should also be aware that most profilers measure cumulative execution time, so the true average cost of Creep.moveByPath is about 0.02, as 0.199 is taken up when it calls Creep.move.
I also really think this bug should be turned into a feature. Like many of the other people in this thread, I spent a lot of time designing a base layout and implementing lab code that would allow for creeps to be boosted while they are spawning. I think allowing in-spawn boosting significantly raises the "skill ceiling" of lab/boosting mechanics without making it any less accessible to newer players, and I would be sad if this feature got removed.
@SystemParadox Perhaps "literally nonfunctional" is a (very small) overstatement, but aside from gradually slowing down to unmanageable tick rates, the sim is missing several crucial features that public/private servers have, such as IVM, multiple rooms, etc.
@artch Wow I feel stupid. 
I just went to test this one more time, and I realized it wasn't working because you can only place the invaders on exit tiles... It's been a while since I've interacted with the manual UI, so I guess I had forgotten that red text = invalid placement. (It might be worth clarifying this though, or removing the exit-tile-only restriction.)
I do still think it would be nice to have options to create the other NPC events on private server though!
I would disagree with shedletsky's opinion that HEAL should be cheaper and that recycling should be removed. HEAL is already very powerful and recycling provides interesting strategies. However, I do think that it would be worth considering buffing CARRY boosts. Currently the manufacturing cost is the same as ATTACK / RANGED_ATTACK / HEAL boosts, but I don't think that 4x carry capacity provides nearly the same utility that 4x damage/healing does (ignoring the fact that the healing further synergizes with XGHO2, which I personally think is a bit overpowered).
For example, assuming 100% lab efficiency and using T3 boosts, if you want to move a full storage worth of resources from 3 rooms away using 40 move / 10 carry creeps, it will take you 25 creeps and 3.56 million lab ticks for the entire operation. The same amount of lab ticks could boost 20 creeps (5 full 2x2 squads) with 10 tough / 40 (attack/ranged/heal) / 10 move bodies, which, in the hands of the right players, is more than sufficient to take out most rooms. I would argue that taking out a room is worth far more than faster and slightly cheaper resource transport.
One final thing I would add is that I think a big factor that limits the usefulness of CARRY boosts is that containers are limited to 2000 capacity, which is only slightly higher than the max unboosted creep carry capacity. I think it is worth considering adding an EXTEND_CONTAINER power to the operator power creep, which would increase the capacity of a container from 2000 to 8000 (max boosted carry capacity) for X ticks. (This would really need to be useable in outpost rooms to be useful, however, so I'm not sure how that would work with enabling/disabling powers in a room.) Alternately, simply increasing container capacity altogether could make this boost more useful on a day-to-day basis, and I don't forsee any balance problems with this change.
This is a bit of a tangent, but I think that a thing that Screeps desperately needs is a better sim, or at the very least least private server commands to spawn various NPC events such as resource trains. (The "create an invader" button on public servers has been broken for well over a year now.) (EDIT: I'm just dumb) Currently, the sim is literally nonfunctional, and on the private server, it takes a lot of work to set up and test a given rare scenario (testing defenses/offenses, NPC events, etc.) if it is even possible in the first place. Things that would be nice to have as private server commands or in a new sim environment:
createInvader(roomName, melee/ranged/healer, small/big, amount=1): spawn an invader(s) in a roomcreateNpcTrain(roomName): create an NPC train in a roomcreateNpcStronghold(roomName): create an NPC stronghold (once this feature is completed)
@wtfrank The ideas I pitched were just me spit-balling and may indeed be imbalanced, but I do think that there is a lot of room for interesting new structures in the game! Some responses to your comments:
shard1...) I do think that the game needs a more reliable way to traverse across the map and across shards, since currently most players are limited to only ever interacting with a half-dozen other players. Perhaps a more balanced version would be this. On a cooldown of ~10k ticks, create a portal in any core room for 100k energy which has 1hp, which can be destroyed by enemy creeps. Portals last for 1000 ticks or until 10 creeps have traveled through it.I also like the idea of using minerals in a temple to increase the upgrade cap. I've always disliked the RCL8 upgrade cap mechanic as it currently is, since you can easily but inelegantly avoid it using temple rooms. Perhaps a version that might provide a better workaround for this would be:
upgradeController(amount) method, which consumes amount energy and ceil(amount/X) ghodium to upgrade a controller by amount points, ignoring upgrade caps. (Perhaps it could accept any mineral, with X varying depending on the type of resource.)
I really like this idea! However, I don't like the "super creeps" part, since it seems redundant with power creeps coming soon (TM). I think 100M energy might be a bit too expensive (it would take a room mining 10 sources over a month to build this structure); perhaps 10-20M might be more reasonable.
If I were to design this feature, I would do something along these lines. Each RCL8 room can build one super structure from the following list of totally balanced ideas, and only one of each structure can be built per player:
@orlet I think the difference is that placing structures is a feature that is encountered within the first hour of playing the game, so having an (initial) manual way to do this manually is important for new players. In contrast, market code is a more advanced feature that is usually attempted only once a player has a better understanding of the game and has a fair amount of automation in place already.
Of course, I'm all for improving UIs in general, but given the limited resources of the dev team, I don't think that making nicer interfaces for doing things manually should be a high priority.
This happens to me sometimes, but I think it's a graphical bug, as it goes away after a page refresh. Do they persist through refreshes on PTR?
This is the first time I've encountered this bug (on private server), and I'm not sure how to reproduce it yet. I noticed one of my creeps was stuck trying to withdraw from a container; turns out there was 0.767 oxygen in the container. Until now, I assumed that stores/carries could only have integer values of resources.
If I try to execute Game.creeps.transport_0.withdraw(Game.getObjectById('ccd957154508118')) it returns -6, ERR_NOT_ENOUGH_RESOURCES, so it seems like the game floors the resource values, so I'm not sure how the container store got like this...
Programmatically creating flags is, to me, one of the most inconsistent and frustrating experiences in the game, and I think it should be a high priority issue to work on. Here are my biggest issues I have with how flags are handled.
You cannot create flags in rooms you don't have vision in. This would be understandable if the only way to create a flag was room.createFlag(pos), since the room object needs to be defined to call createFlag, but you can also call new RoomPosition(x,y,roomName).createFlag(). Room positions can be defined without vision of the room they are in, so you would expect that this would be a valid way to place a flag, especially since there is no return code on createFlag such as ERR_NO_VISION.
However, you can create flags in a room you have vision and then move them to a new position where you lack vision, although this works very inconsistently as @likeafox has mentioned. If we ignore the inconsistencies with this, the natural way to place a flag where you lack vision would be to place it in a room with vision and set a memory property, say moveFlagTo, and move it on the next tick.
But you can't easily do this either, because unlike creating a creep with spawn.spawnCreep, you cannot specify the initial memory of a flag. There are, of course, workarounds to this, but given that flags are one of the first game mechanics that new players encounter, it seems like a good idea to make them as easy as possible to work with.
What makes this even more frustrating is that you can do all of these operations manually in the GUI without issue. I'm not as much of an automation purist as some others, and I don't want to kick the "everything should be automatable" horse, but flags are a pretty integral part of the game and act as a very natural attachment point for processes in your code. Since they are such an important and frequently used part of the game, I definitely think that you should be able to do any operation with flags programmatically which you can do manually.
If I may be presumptuous enough to suggest the way that I would refactor flag creation:
Room.createFlag(pos) method and only allow flags to be created from RoomPositionERR_NO_VISION as a return code optionMemory.temp.flagMemories[flagName] and move the object to flag memory at the beginning of the next tick - but it would be great to have this natively supported to be consistent with the way creep memories are initialized)StructureSpawn.spawnCreep()A refactored function signature could then look like: RoomPosition.createFlag(opts?: {name?: string, color?: string, secondaryColor?: string = color, memory?: any})
Just my two cents.
I have been looking for a bug in my code for the last week that would sometimes spawn (n+1) the number of creeps needed for a process. I finally found this thread from a year ago, which never got any response, and found this to be the source of my problems. I added an edge case in my code to compensate for this, but this was a really difficult bug to track down and I thought the issue should deserve attention again.