Code doesn't necessarily run on other shards after creeps enter inter-shard portal
I don't have any rooms claimed on shard1 and I'm finding that when I send a creep through from shard2 to shard1, my code doesn't start running on shard1. I expect that as soon as a creep goes through an inter-shard portal, my code would start running on the destination shard (whether or not I have any rooms claimed on that shard).
These are some of my logs which demonstrate the problem.
I have 5 CPU allocated to shard1 and the remainder to shard2. I'm sending a creep through a portal from shard2 to shard1 while the creep has 998 ticks to live, which should mean it arrives through the portal with 198 ticks to live. These are some console log files indicating the problem with my comments in italics.
2018-07-01 14:10:41 shard2: Inmate-472869-exp explorer [room E40S30 pos 43,26] 998ttl About to enter inter-shard portal to shard1 E40S30 - logged when I issue a move onto the portal - not complete proof that the creep went through the portal
2018-07-01 14:10:44 shard2: Clearing non-existing creep memory: Inmate-472869-exp (explorer) Combined with this message though, it's certain that the creep successfully went through the portal
2018-07-01 17:07:03 shard1: ISM processed message: creepmemory containing memory of Inmate-472869-exp 3 hours later my code seems to run on shard1, probably in response to a different creep travelling through the portal, and it processes the message I had written to the inter-shard segment containing the creep's memory
2018-07-01 17:07:08 shard1: Clearing non-existing creep memory: Inmate-472869-exp (explorer) but the creep is long dead!
3 hours later later I sent a different creep through the portal, and 9 minutes after that creep went through I have evidence that my code started running on shard1.
2018-07-01 16:58:37 shard2: Inmate-473600-exp explorer [room E40S30 pos 43,26] 1163ttl About to enter inter-shard portal to shard1 E40S30
2018-07-01 16:58:40 shard2: ISM sent message 3 to shard1
2018-07-01 17:07:00 shard1: New code uplodated
2018-07-01 17:07:00 shard1: tick skipped - we went from 9745947 to 9773628 a jump of 27681. bucket is 9953
We see from my logging that the code hasn't run for 27681 ticks, or roughly 23 hours - however we know that just 3 hours earlier, my creep went through the portal so my code should have been getting run 3 hours ago - perhaps 3600 ticks ago... not 27681!
iceburg last edited by
I have had a similar issue when trying to send creeps from shard1 -> shard2
When I had 0 cpu assigned to shard2, my creep didn't work right, but I could use Game.creeps['creepname'].move(dir) and it would move. I could change it's memory, and it worked.
As soon as I allocated 5 cpu to shard2 I could no longer interact with my creeps. Or run any commands on the console even.
Even typing Game.time on the console did not return a value;
iceburg last edited by
Maybe I did a bad:
Sent creeps to a shard where I have no CPU? Allocate CPU to shard where I have no creeps? Broke the RawMemory.interShardSegment on shard where I have no CPU?
I was refactoring at the time all this happened, but it also, as far as I can tell, caused a major oopsie with my RawMemory.interShardSegment
@SBense has experienced the same thing and it seems that if you upload your code after a creep has been through a portal, that is enough to get the code running on the other shard.
Right, I found that if I have CPU dedicated to a shard, but no assets currently present on the shard, the code would not run until a creep had arrived and I re-uploaded the code. After that, as long as assets remained on the shard, the code would run as expected. If the assets were lost on the shard, the code would shut down and I'd have to jump start the process again with the next arrival. Otherwise, I think you'd be at the mercy of random code resets to get the code running again. I also had to delay creep memory writes from the intershard segment by a tick after the jump start or the memory write would get lost, but that could just be poor implementation.
Is there a minimum amount of CPU you need to have allocated to a shard in order for the code to start running when a creep goes through the portal?
hyramgraff last edited by
@wtfrank Even with zero CPU allocated to a shard, you should still have a CPU bucket that you can draw from. However, if you have zero CPU allocated to that shard, the bucket will never grow it will only deplete.
PythonBeatJava last edited by
I had the same issue. I am based on shard2 and decided to use the portal to shard1 to have fun. I relocated 10CPUs to shard1 and transported a creep there. However, I could not call the creep by its name
Game.creeps.xxx, neither was I able to get any responses from the game's console. Whatever I typed in the console would not give any feedback. Later on, someone told me to go back to shard1 (the new shard for me) and save my code again. By doing this, my codes got executed in the new shard. So it seems that you need to save your code on the new shard in order to activate it.
The hotfix has been just deployed addressing this issue. Now your code on the other shard should be activated immediately after the creep is moved. Please report if you still experience any problems with this.
My code started running on shard1 within 11 seconds of a creep going through a shard2 portal. And yesterday one went through and the code took 8 seconds to start running. It's looking good!
Only 569 creeps were harmed in the testing of this feature
2018-08-22 15:39:02 shard2: Inmate-806945-exp explorer [room E40S30 pos 43,26] 951ttl About to enter inter-shard portal to shard1 E40S30
2018-08-22 15:39:06 shard2: Inmate-806945-exp explorer left this shard for another: shard1 with ttl 951
2018-08-22 15:39:06 shard2: ISM sent message 569 to shard1
2018-08-22 15:39:17 shard1: New code uplodated
2018-08-22 15:39:17 shard1: tick skipped - we went from 11076763 to 11089474 a jump of 12711. bucket is 9347
@wtfrank Could you please specify, it was 11 seconds after a creep went into the portal, or after it appeared on the other side?
@artch creep gave intent to enter the shard2 portal at 15:39:02. The following tick 15:39:06 it was gone from shard2.
The first evidence I have of my code running on shard1 is at 15:39:17. However I wasn't watching the room when this happened, so I don't know the timing of when the creep appeared on the other side.
(The bucket was at 9347 on the first tick that my code ran, but the bucket was at 9350 on the final tick that it ran several hours before - I have only 1 CPU assigned to the shard, so the bucket is recharging slowly).
I will have a look out next time a creep goes through so I can give you an accurate answer of when the creep appears and when the code runs.
OK I sent a creep through another portal. The code started running the tick after the creep appeared on the other side.
The creep sends the intent to move into the portal at tick 8875926 at 23:51:41. The creep disppears on tick 8875926 and shows TTL 1351 https://screeps.com/a/#!/history/shard2/E30S30?t=8875926
The creep shows on the other side at tick 11097888 with TTL 548, but the code doesn't run until tick 11097889 at 23:51:56 https://screeps.com/a/#!/history/shard1/E30S30?t=11097888
So in my opinion, the creep goes into the portal on one side, takes about 10 seconds to travel through the ether, which is no big deal. During this 10 second period, 3 ticks of it's life tick down (which correlates with either the shard1 or shard2 tick rate). It then appears on the other side and is inactive for one tick, before the code starts running the following tick.
@wtfrank This is exactly per design. Transporting the creep may take time, but code should be executed immediately when it is transported.
good so it's all working well