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:
flagTest1(); at the top of my main loop while the flag was NOT in existence.
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.flagTest1(); with flagTest2(); at the top of my main loop. The flag was already in existence.
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.
Occasionally I create a flag in one room and then the following tick I change its position to a different room. This seems to SOMTIMES result in the following:
Game.flags points to the second flag in the new position..findable with FIND_FLAGS, so it seems not to be only a display issue, the flag exists as a room object in 2 distinct rooms.Some console proof (also showing room names and shard if necessary):
[Game.rooms.W22N11, Game.rooms.W21N12].forEach(r => console.log(r.find(FIND_FLAGS)))
[4:38:36 PM][shard2][flag SCOUT_W22N11_FROM_W21N12]
[4:38:36 PM][shard2][flag FILL_WAIT_W21N12],[flag SCOUT_W22N11_FROM_W21N12]
Note that [flag SCOUT_W22N11_FROM_W21N12] exists in both rooms on the same tick.
I have had this happen to me twice now in the last week or so, I do not create these flags often. The first time I thought it was just a UI glitch and I don't remember what I did. Perhaps I clicked on the flag that should not have been there and pressed "Remove Flag," but I can't say for sure what happened. I will be leaving the errant flag in existence for now just in case it can be of some use in finding or fixing the bug. Let me know if you would like any more information.
@dissi Rubble sounds cool. Would be consistent with the tombstones. The destroyed flag would only work in conjunction with the rubble right? If the structure is destroyed (without rubble) you'd still have the null issue.
@gankdalf said in Draft: room event log:
{ type: EVENT_DESTROYED, structureType: STRUCTURE_SPAWN }would be enough for me. I don't care where it was destroyed, or what it used to be, but if an important structure goes down, I need to look at creating a new one and/or starting safe mode.
I also think this would be plenty. Even if it triggered when an old hostile structure was destroyed I think it would still be useful. At the very least it could tell you to .find all of your structures of that type and handle any missing ones, instead of checking like that every tick. If a player handles it incorrectly due to it being a hostile structure that was destroyed, that is the problem of that player to fix.
It doesn't look like this needs any more support than it already has, but I really like this feature idea. The EVENT_EXIT and especially EVENT_ENTER would be awesome.
Claimed rooms would never have to .find(FIND_HOSTILE_CREEPS) again. The hostile creeps could have their id's recorded when they trigger an EVENT_ENTER and tracked until death or EVENT_EXIT, which could both be handled differently. Granted you'd have to check the log every tick versus perhaps only doing a .find every x ticks. Which method would require more CPU do you think? .finding hostile creeps every tick or checking the log every tick? Either way the log sounds useful.
Also being able to determine when something has taken damage without looping through every single thing and checking the hit sounds great. Especially for things where this is tricky because of decay like containers, roads, and ramparts.
Also will allow something like this:
if (ALLIES[damageDealer]) {
ALLIES[damageDealer] = false;
IS_JERK[damageDealer] = true;
}
Which was still probably manageable before, but not quite as simple and nice as this ^
@SteveTrov is that what happens currently when you press the "<" button to go back 1 tick? I figured negative tick speed could just do whatever that button does but at a regular interval. Anyway its not a huge deal.
When wanting to follow a creep backward in time to see where it came from or what it was doing previously, it is tedious to press the "rewind 1 tick" button repeatedly. It would be nice if the tick speed in the room replay could go negative and play the data backward as well as forward.
@mrfaul Yes that is how it works, but there is also a roomCallback or routeCallback depending on which function you use so that you can do things like tell the pathfinder to avoid certain rooms or to prefer highway rooms and things like that. I know WHY my creeps are getting stuck, i'm just asking for a way to solve that problem in my code, and not have to manually type out room names for dozens and dozens of rooms when there is a novice/respawn area. Manually adding flags to 60 rooms is not a fun solution either, and will still need to be redone every time you spawn into a new respawn zone.
As a side note it would be nice if the max value of the maxRooms option was increased. The longer purple arrow in that picture i shared goes through more than 16 rooms which means no path can be found. I'll have to do some kind of multi stage pathing to get that far for now but it would be cool if the maxRooms option could go higher instead. If using Game.map.findRoute to only allow rooms along the optimal room path it doesn't use an unreasonable amount of CPU to path that far considering the distance.
Also want to note that as my temporary work around I just manually typed in the 60 room names that surround my novice area so that i can tell my pathing to avoid them. If/when i get killed and respawn in a different respawn zone i'm going to have to do that again. Let me tell you nothing makes you want to play a game more than manually typing in 60 room names with the knowledge that you may have to do it again in the future.
For illustrative purposes:
I am in a novice area right now and it is shaped a little bit odd in that it makes it difficult to get from one side of the novice area to the other without going all the way around the outside of the novice area in the highway rooms. When I try to tell a creep to move to a room on the other side, it attempts to move through rooms that are not accessible because of the novice area walls and the creep just gets stuck.
I know there is a routeCallback that can be used to avoid or prefer certain rooms, but I can't find a way for the code to know whether or not a room is in a novice area or not. I originally thought Game.map.isRoomAvailable was the answer but i guess that is not the intended purpose of that function.
I also know you can tell if a wall is a novice wall by checking that it doesnt have a .hits value, but this only kind of helps in the immediate room, it doesnt let you path through multiple rooms optimally. The UI has a timer showing for the novice walls but I cannot seem to access that timer value.
Someone sent me to this post:
where someone says there is a .ticksToLive property on the wall, but there is no such property (maybe it was removed), so there is no way for the code to determine when a wall will come down. Even if this property did exist or if we could access the decay timer, there is still no way to determine which side of the wall i'm on.
It would be really nice to have a new function like:
Game.map.protectionLevel(roomName) that returns values like the following (or similar):
{type: "normal"}
{type: "novice", endDate: 1519073582938}
{type: "respawn", endDate: 1519073582938}
Where endDate is a value similar to that returned by Date.now()
Could also roll the Game.map.isRoomAvailable functionality into it and have it be Game.map.availability(roomName) with the additional return value:
{type: "unavailable"}
This would allow us to use this feature in our route callbacks and make it so we can path around and inside of these novice zones.
I suppose there would also be constants
AVAILABILITY_NORMAL: "normal",
AVAILABILITY_NOVICE: "novice",
AVAILABILITY_RESPAWN: "respawn",
AVAILABILITY_UNAVAILABLE: "unavailable"
I would image that if this were implemented, future types of rooms would be easily added as an additional return value.
EDIT: The only issue i see with this right now is that highway rooms adjacent to novice rooms would both be "novice" and "normal"... Perhaps each room could have multiple types if necessary. I'm not sure on that one.
Hi, I am in a novice area and am trying to use code to find the best path between some rooms but its not working.
I found Game.map.findRoute but it is returning a path that is blocked by the walls that are keeping me inside of the novice area.
I then found Game.map.isRoomAvailable that says in documentation:
"Check if the room is available to move into."
but it is returning true for both rooms inside the novice area and rooms outside the novice area so I can't use it in the routeCallback to try to change the path I get from Game.map.findRoute
Which shard is affected?
Shard 2
What happened?
Game.map.isRoomAvailable("W25N13") === Game.map.isRoomAvailable("W25N14")
What should have happened?
Game.map.isRoomAvailable("W25N13") !== Game.map.isRoomAvailable("W25N14")
How can we reproduce this?
Put the above code into the console
Optional information:
Replay link
N/A
Piece of code which shows the bug in action
See above.