As far as I know, User names are cast in stone and immutable for the life of the account.

So you would need to kill off that account and start a new one from scratch.

I use the Steam client, so I don't even have a "back" button.

You also can't just use the left menu's "world" button to do back to where you were in the world, it just randomly puts you in whatever shard. You have to click the "summary" button to go to the summary screen, and click what room you actually want. It's a little annoying.

The code stopped during the attack in your room north of that one, right when a creep died and the spawn had already been killed. It probably tried to respawn, and that tried to use a null pointer. By the time the wreckin' crew got to the room shown, your code had already halted.

TRY/CATCH is your friend. During combat is usually when crashes like this happen.

The first code segment returns an array of the non-empty containers, you would need to use targets[n] to determine the one you want.

The second won't work, as "STRUCTURE_CONTAINER" isn't one of the FIND constants. You need to use "FIND_STRUCTURES" then filter for the one you want. THAT one returns a single object.

From my point of view, I like and welcome this change, it will allow me to streamline my creep states so they can exit faster (Thus saving CPU.) I am concerned that heap use may increase, but that's Artch's problem... and in reality, any heap issue impacts everyone, mostly heavy users and users past the 300 CPU limit first, so I don't have a problem with that, despite that I'm breathing down the 300 CPU limit's neck. At the end of the day, it's pretty fair.

Two potential issues. First, the obvious one: Nukers with their 5000 ghodium. Two stores? Ewww! Don't make them all the same except for this one weird bird. Applying a limit object with, for example: {G:5000,energy:250000} to it is the best solution, other structures would have null there to short circuit any checks.

Then the 800 pound Gorilla: LABS. Labs are incompatible with a Store object unless you dynamically reset the limit object on the fly. Sure, the capacity remains 5000, but it can change from (for example.) {UO:3000,energy:2000} to {energy:2000} to {KH:3000,energy:2000}. It can have only one non-energy resource as it uses that to determine what it's doing.

@orlet Code has the same limitation, it's only aware of the current shard. And no, I was doing this in code. All three shards I'm on run the same code, with the difference being the Game.... data and Memory... data being different. The mistake I was making was using the room name to find the room, then room.find the find the Power Spawn in the room. The correct way (And I might add, the way the docs have an example for.) is to use the Id of the Power Spawn with Game.GetObjectById('XXX');

An interesting ramification of this is you cannot use the Creep's memory to store where it wants to go, as you can neither use a portal nor read that memory from another shard (I originally thought the PCs were somehow synced across shards. They are not. They are merely unique across shards.)

I certainly dislike hard coding the Power Spawn ID into the code, or the room name, for that matter. A solution would be to dedicate a section of the intershard memory to the startup parameters for each named Power Creep you have, then look at that occasionally to see if one that should be on the current shard isn't there and try to spawn it.

Only if you were doing it wrong like I was. (See the edit at the bottom of that post.) If you referenced the Power Spawn as the room / room.find(FIND_MY_STRUCTURES,{filter: {structureType: STRUCTURE_POWER_SPAWN}}) then it could get confused. Simply using the Power Spawn's ID would clear that right up.

Thanks, Goggles!

It's pretty clear what the issue is, after doing a bit of research (I added the code bit after submitting the report.) it's intended to be that way, either as a stopgap to prevent something else, or whatever... I just wanted to bring it to your attention. As a fix... I'm not going to waste an experimental period... I'll just eat the 8 hours and "Necro-port" to the other shard.

I would like to point something out, though... The post-cooldown respawn of the Power Creep has no way to know what SHARD the room you've specified is on. If you have a condition where 2 rooms are on top of each other, but on different shards... and since you cannot use the portal, it may actually be impossible to spawn a PC in a desired room in those cases.

I'll consider this solved and trust it'll stay on a burner.

Edited to add: As soon as I posted this, I had a moment of clarity... I was looking for the Power Spawn by room name. Which, isn't guaranteed unique. But if I used the ID of the spawn, and then used Game.getObjectById(), it would only return an object on the shard that particular spawn is on. So I'll fix my code to reflect that.

Oddly, I can't drive my PC onto a portal and go to shard 1 from shard 2. It has a valid pos it's trying to use moveTo(pos); to get to, and the call returns 0. If I step in and manually force move(RIGHT); it still won't go. Is this intended, or is the portal somehow broken?

The portal is on shard 2, at W50S20 24,39

Ok... engineeryo on the power_screep slack pointed this out:

In move(), which is ultimately called...

if(!_.any(targetObjects, (target) => _.contains(C.OBSTACLE_OBJECT_TYPES, target.type) && target.type != 'creep' && target.type != 'powerCreep' || target.type == 'rampart' && !target.isPublic && object.user != target.user || object.type == 'powerCreep' && target.type == 'portal' && target.destination.shard)) {

movement.add(object, dx, dy);

Ok. first I have to consult the operator precedence chart... Yup, && superceeds ||, so the &&s are done first. So it appears the intershard portals are specifically set as an obstacle. And then if it IS an obstacle I guess it just runs off the end of the function and returns OK.

The majority of the difficulty in Screeps is the logistics. Structures that store materials in any quantities cannot beam resources to other structures that perform work with those resources. You must manage that with a network of interstitial elements (creeps) that have carry, movement, and CPU cost limitations. This also introduces the concept of managing an asynchronous system, you must move the creep to the source, load the creep, move the creep to the destination, unload the creep as individual atoms of code that cannot operate as consecutive calls in a single function. .

Conversely, throwing a store on the spawns with enough capacity to store enough boosts to be effective will also trivialize the learning curve as the spawn would just become a level 1 storage. This would also trivialize the body size constraints creeps face with low level rooms.

Boosting, in my opinion, needs some help, but that has nothing to do with spawns. The wall of difficulty that is labs + terminal + market all at once needs some help, but that has nothing to do with spawns either.