See this replay:

https://screeps.com/a/#!/history/shard2/W25N13?t=4244395

Thanks to my terrible rampart repairing code I found out that every time 1 rampart decays, all ramparts disappear before being redrawn.

Obviously this is not game breaking but it is rather distracting.

I suicided one of my creeps that was surrounding the spawn and the room resumed working.

So its definitely a bug with surrounding the spawn.

I broke a room. Shard 2 W22N7. Current tick is 4224470. It has been broken for a little bit and is still broken. The room is currently in safe mode but will not be soon.

Creeps cannot take action. Creeps appear to be upgrading the controller but not actually using any energy.

A creep is 1 tick away from spawning but will not finish spawning.

I can call .move and .say on my creeps in the room and they return OK but nothing happens.

My theory is that there is a bug with the new .spawnCreep and Spawning features when a spawn is completely surrounded, and perhaps only in safe mode.

This could be exploited if it is reproducible.

There is room history right up until the tick where it broke. This also happens to be the very same tick when the spawning creep would have spawned.

See: https://screeps.com/a/#!/history/shard2/W22N7?t=4224212

EDIT: Also worth noting that time still passes in the room.

ticksToLive still decreases.

Room visuals still work.

Pathfinding is still taking place.

It just seems like the intents themselves are not going through or something.

EDIT: The room is no longer in safe mode and the broken state still persists.

@wolfwings Not if they are still subscribed though I think. I went a long time without logging in and my script stayed active because i had a subscription. Makes sense, you shouldn't be cut off if you're still paying. And if they are not subscribed they're at 10 cpu and likely can't hold a ton of territory anyway.

The race could also affect your power creeps too somehow.

It could also be fun if somehow you started with a special power creep or racial creep or something when you first spawn that has no lifetime limit. You'd never have more than 1 and it could do different things based on what race you are. Heck depending on how it was implemented your "racial" creep could even be invulnerable and pathable but its abilities would be limited to utility functions or things that could not be abused.

This sounds like a lot of fun. Without giving an opinion about the specific bonuses or drawbacks, just the idea of having different races that have different effects on the game is a really fun idea.

It could also be interesting to be able to "unlock" races at certain GCL levels, so that you start with the default and standard race but as you level up you kind of unlock different ways to play that would give an incentive to respawn. I like the idea that you'd have to respawn to switch races because then you have a good reason to respawn and work on your low level code again but with a new challenge or new way to play.

More races could be added in the future as well that would give old players a new reason to relapse come back to the game and play again.

You can go attack their controller to speed up the downgrade.

@Dissi I was creating the flag in an owned room on one tick, and then on the next tick moving it to a room with no vision. This scenario does not always cause the problem but seems to occasionally.

@SteveTrov Thank you for this input, it led me to do some more testing with interesting results.

I wrote the following code:

let flagName = "test";
let desiredPosition = new RoomPosition(25, 25, "W27N13"); // no vision of this room
let creationPosition = new RoomPosition(6, 29, "W25N13"); // owned room with vision

global.flagTest1 = function() {
    let flag = Game.flags[flagName];
    if (!flag) {
        creationPosition.createFlag(flagName);
    } else {
        flag.setPosition(desiredPosition);
    }
    log(`Flag exists: ${flag}`);
};

global.flagTest2 = function() {
    let flag = Game.flags[flagName];
    if (!flag) {
        creationPosition.createFlag(flagName);
    } else {
        flag.setPosition(Game.time % 2 === 0 ? creationPosition : desiredPosition);
    }
    log(`Flag exists: ${flag}`);
};

And performed the following tests:

1. I put flagTest1(); at the top of my main loop while the flag was NOT in existence.
   • Result: A flag by the name "test" was created, and then proceeded to alternate in and out of existence at creationPosition, never making it to desiredPosition every other tick the log statement would say that the flag did not exist. I do not have any other code in my code base that would be removing this flag. Eventually after some number of ticks (perhaps a dozen or two) the flag successfully moved to desiredLocation and stayed there, behaving as you would expect.
2. I replaced flagTest1(); with flagTest2(); at the top of my main loop. The flag was already in existence.
   • Result: The flag "moved" to desiredPosition but also remained at creationPosition. There are now two instances of the flag that are both clickable and selectable in the UI.

I have repeated both of these tests multiple times with similar results.

Another interesting note: While the flag is "duplicated" and exists in both rooms, calling Game.flags.test.remove() returns OK but neither flag is removed. Both stay in existence after repeated calls to .remove() from the console. After clicking one of the flags in the UI and pressing the UI button to remove the flag, it is removed but the other version of it stays in existence and calling .remove() now functions properly on the remaining flag.

I've been frying my brain trying to figure out a good way to implement labs/reactions/boosts/etc for a while now and that was BEFORE this change. Seems like its taking something already complicated and confusing and making it even more so. I haven't actually gotten code for reactions written yet but it seems like while this won't make the actual reaction logic any different, it will make the decision of which minerals to focus on even more complicated than it already is.