I'm looking at players that already have power creeps in the world for inspiration on how to design my own and am finding configurations that don't seem possible (at least if designing through the power creep upgrade GUI).

The simplest example is the level 2 factory power creep. In the GUI you need to be AT the level listed for that power creep in order to train that level. So OPERATE_FACTORY (OF) with 0/2/7/14/22 can do the following:

1. Level 0 Power creep takes OF. Making it level 1 Power creep with the OF power at level 1
2. It needs to be level 2 before it can take the OF again, so it has to take another power bringing it to level 2
3. Now at Power creep level 2, can take OF again to get OP to level 2 as quickly as possible

But the screenshot flies in the face of this. You can delete a creep which gets rid of everything but not a single power. This is true through the console with .upgrade(power) and through the GUI. What am I missing here?

If this is expected behavior, how do I spend 3 GPL (1 on creation and 2 on PWR_OPERATE_FACTORY) to replicate this? I can't seem to do this via GUI or console commands.

The leftmost example is in https://screeps.com/a/#!/room/shard2/E48S11 and the rightmost is in https://screeps.com/a/#!/room/shard2/E49S31

The second example seems to have 4 different lvl22 powers while still being only lvl22 itself. Again very useful, I'd like to know how to do it myself if legit.

Gadjung was suggesting adding a new game object (new structure) to cross-highways that facilitate getting pixels, artch was saying they weren't considering adding new game objects (or structures) to the world for this. You have to read the full context of the thread.

Pausing every object of yours isn't a good idea, don't get be wrong. But artch wasn't contradicting themself.

NeyaZayah's AS IT IS NOW and AS IT WILL BE hits the nail on the head. I thought the intent behind .generatePixel() and related graphics is to allow a trivial amount of code (2 lines) to allow access to graphics in the game. Getting players to express themselves with 2D graphics and spicing up the look of the surrounding MMO world at the same time.

The suggestion to cancel intents isn't a interesting problem or solution to work towards. Simply adding challenges for challenge's sake is not fun.

What is the problem we're trying to solve? The communities response has been overwhelmingly negative so let's find a different solution to the problem we're trying to fix.

1. If the problem is to many pixels are being generated by generatePixel(). The function already consumes 5000 CPU of 10000 bucket. We could play with the idea of a value between 5000-8000 but I expect this would disrupt far to many players to be viable. So we can't go higher unless bucket is changed and I doubt that's feasible. So we have to look elsewhere.

2. "Pixelization" currently costs 500 and refunds are 400 of that 500. Both of these can be changed to slow down the 'value' of pixel generation. Double/Half the amounts that we know work until we find a value that works well. If we want to slow down pixel generation, change pixelization to cost 1000. If that slows down things to much, half the difference to 750 and so on until we find a happy medium. If re-rolling is a concern we can adjust those amounts.

3. If we're interested in a more complex change we could change the amount of pixels generated per generatePixel() call. If we increase pixelization costs by the same amount. generatePixel() could generates 10 pixels if we change "Pixelization" costs to become 5000 instead of 500. This would allow us to play with the generatePixel amount so if our new "normal" is 10 we could half it to 5 (while keeping "Pixelization" at 5000) to half the 'value' of pixels.

Note for suggestion #3: If we're entertaining this idea, do this by a factor of 100 or 500. These numbers are a lot easier to tweak then a factor of 10.

Screeps already has a major problem of rewarding the old guard with the biggest economies and code-bases (Factory change did this most recently) and doing very little for the newer players (safe mode is one of the few catch-up mechanics we have). The proposed change will help those that are already idling all/most of their intents already and hurt those who desperately need those intents for energy and other things as they get their feet under them. Let's not compound problems that are only viable at higher RCL levels vs lower RCLs please.

Looks like the options for Game.map.visual.rect() make it invisible if you only put in a position and size of width and length. I have to put in {stroke: '#ffffff'} in order to see it.

If you do several saves in short order. Occasionally the save doesn't go through and saves an empty file or incomplete file. In which case you resave again to fix the issue. This is a long standing bug. Look at a different file and then look back at the offending file to refresh your window to see what is really loaded. The exact code isn't the offender here.

Long time bug

Given how long it takes to go through walls, storage provides ample time to get out a lot of defenders or pump what is needed into towers. As for raiding for energy. If you're spending the resources and CPU to get into someone's storage, everyone destroys the rooms spawners and working creeps if they've gone that far to kill the room, allowing raiding for energy at their leisure if they're interested.

You can spawn units and buildings with the on screen UI at the top of the screen and side bar and change the script to point to the one you're running in the game world. You can edit the terrain the same way as well.

I'd argue having a barrier to flooding the market with subscription tokens is a good thing. Selling subscription tokens will already bring huge profits and I'd rather dummy accounts with plenty of money backing them shouldn't be able to buy their way to victory until they've at least built up some starting capital.

Confirmed Game.spawns.Spawn1.spawning = null in simulator.

But doesn't checking == null or != null sufficient in both cases? This is a weird edge case.

No idea on dev response but a work around would be to check if:

if(Game.rooms[roomName] != null)

before executing this code and it will only run if you have sight on the room.