Necromancing this thread because this post was at the top of google search results when I searched for forcing a global reset.

Since the thread was made, the method "Game.cpu.halt()" has been added. It is documented here: https://docs.screeps.com/api/#Game.cpu.halt

Correct. The Discord is where much of the community activity takes place. https://chat.screeps.com/

In room E42S11 on shard1, a player has built some art using walls. This art shows in the legacy map, but the alpha map does not show the art (i.e. does not appear to render player walls). There may be a good reason for this change, but losing those occasional bits of player art would be a shame, so it would be nice to know if this is intentional or accidental.

legacy map

alpha map

I agree that terminals throughput and reach make them very powerful, and that potentially overshadows other logistic options in the game (creep transporters) or potential new designs such as Warp Containers.

If the key design objective here is to avoid short interrupts of terminal disruption being catastrophic for attackers, what about the following change to PWR_DISRUPT_TERMINAL which makes sieged terminals more expensive to use while reducing the catastrophic effect of the effect dropping:

1. PWR_DISRUPT_TERMINAL no longer blocks withdrawals, but now imposes a loss at the time of withdrawal: 30%/50%/60%/70%/80% depending on the level of the power. E.g. level 1 disrupt means that I try and withdraw 1000 energy, 1000 energy is removed from the terminal, but 700 energy is added to my creep.

2. PWR_DISRUPT_TERMINAL now uses a new expiry mechanic: level reduction. Instead of the effect dissipating after X ticks, the effect reduces a level and the cooldown is reset back to X ticks. The effect only expires when the level would reach 0. This means the effect is less binary, and fades out over time. So if you apply level 5 power, after X ticks it drops to level 4, then after another X ticks it drops to level 3 and so in. The effect can be reapplied by the attacker at a higher level, without waiting for it to tick all the way down to level 0.

3. the cooldown of PWR_DISRUPT_TERMINAL is increased to 100 ticks, and the ops cost adjusted accordingly. Making the effect longer is not a big problem as the effect is no longer a complete lockout of the terminal, but leaves a defender the option to spend their way through the effect... until they run out of money.

4. PWR_DISRUPT_TERMINAL affects the contents of a ruin formed from the terminal (destroying the terminal and rebuilding thus remains an option for the defender, but potentially an expensive one).

The effect of these three changes is:

1. level 5 disrupt terminal is a lot stronger than level 1, but level 1 is still useful. Currently I think there's no reason to go beyond level 1.
2. defender now has a choice to make - do I withdraw these Tier3 boosts now knowing that I'm paying a fortune to boost this creep, do I wait and hope that the level will drop off in the future, or do I not boost this creep in this base? The current power design leaves the defender has no choice but to wait and hope. Allowing the defender a choice makes the situation more interesting for the defender to reason about, and the optimal choice may be different for different players, bots, situations.
3. if the attacker's disruption is interrupted, there is a much larger grace period before it becomes catastrophic for the attacker. Instead of the effect dropping off after 10 ticks, the effect continues for hundreds of ticks, albeit with decreasing power. The overall effect is to make disrupt terminal more flexible and powerful for the attacker (although this is dependent on the exact loss percentages). The attacker also is able to trade off the cost in ops vs the withdrawal cost for the defender. Perhaps the economic decision for the attacker is to apply level 5 disrupt terminal, and wait for it to drop to level 3 disrupt terminal before reapplying level 5 again. The decision-making for the attacker is slightly more interesting than reapplying on expiry.
4. The economic balance between attacking and defending is tilted away from the defender. It's still possible to flood resources into a sieged base from elsewhere, however it becomes much more expensive for the defender to make use of those resources.
5. PWR_DISRUPT_TERMINAL becomes not just "wreck their defence", but "wreck their economy and their defence". Perfect application of the existing power would be stronger at wrecking their defence than this proposal, but an imperfect application neither wrecks their defence nor their economy. This proposal means that even a failed attack could be costly for the defender (potentially 5x as costly as at present).

What's good about this proposal?

1. It narrowly focuses on the specific issue with PWR_DISRUPT_TERMINAL, and doesn't change other parts of the game.
2. More decisions for attackers and defenders to make.
3. Puts a greater distance between PWR_DISRUPT_SPAWN and PWR_DISRUPT_TERMINAL. Currently, both interfere with base defence by blocking a crucial structure, aiming to make spawning defender creeps impossible. With this change, the choice is between blocking defenders spawning, and making defenders very expensive. The outcome is no longer identical (assuming perfect attacker logic).

What's bad about this proposal?

1. It narrowly focuses on the specific issue with PWR_DISRUPT_TERMINAL, and doesn't address the strength of terminals in general (but maybe that's ok).
2. Introduces a new effect expiry mechanic that doesn't exist on other effects which might make the behaviour harder to understand.
3. doesn't tie in with the mineral compression mechanic (unlike the terminal rate limit under discussion)

Performance profiling is easier to do offline. It would be a useful feature to be able to download the console log at the end of a match.

Currently I'm emitting some json-formatted stats each tick which I have to manually copy out of the game client - this is rather fiddly.

The infinite scrolls works ok with mouse scroll wheel on my PC. I can move down through the list by spamming the scroll wheel although it's not particularly fast.

It doesn't work very well on my laptop touchpad, using the scrollbars to progress down through the list.

Page-down works throughout the part of the "infinity scroll list" that has been fetched. But pressing page down at the bottom of the list does not trigger a fetch of any more of the list.Page-up works fine - it takes you back through the list as expected.

The following console.log line crashes when the under-construction structure member is StructureTower:

      let cs = getObjectsByPrototype(ConstructionSite);
      for (const c of cs) {
        if (c.my) {
          console.log("my cs:", c.structure, c.structure == null, c.structure === undefined, c.progress, c.progressTotal);

Best Rating is 3088 but Rating is 1357. After five rated games.

Although I know nothing about the server code, I wonder if the first few rating games are very erratic and swingy (a low damping parameter in early games) and if so, maybe first games shouldn't contribute to Best Rating. (or maybe the problem is something else entirely).

I'm not completely sure if this is a bug or not. If an opponent creates a construction site in S&S, the "structure" attribute of the construction site is "undefined". This means you're not able to determine the prototype of the opponent's construction site. However you are able to obtain some info about what they're building via the progressTotal property of the construction site (e.g. 1250 => tower, 200 => rampart or extension).

The following code was run in a replay with one player and one hostile construction site. The sit labelled "my cs:" has info, but the hostile construction site logged "cs:" is undefined.

      for (const c of cs) {
        if (c.my) {
          console.log("my cs:", c.structure, c.structure == null, c.structure === undefined);
          continue;
        }
        else {
          console.log("cs:", c.structure, c.structure == null, c.structure === undefined);
        }

It would be good to be able to interact with the arena replays via the keyboard more easily. I find it quite fiddly on my laptop touchpad to hit the forward/backward replay bar, and the console log scrollbar.

May I suggest the following key bindings:

Left Arrow -> equivalent to pressing the button that rewinds a replay by some ticks

Right Arrow -> equivalent to pressing the button that advances a replay by some ticks

Up Arrow -> scrolls back in the console log 1 page

Down Arrow -> scrolls forward in the console log 1 page

Space Bar - toggles play/pause of the replay (it usually does this but sometimes focus seems to be set on other elements)