Posts made by wtfrank

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)

Normal rating/replay games have a nice feature where you can start watching a replay before the server has finished running the game. While you watch the replay, you see the length of the replay periodically increase by 100 ticks, as the server streams the contest to the client.

However when you participate in a fame ladder, if you start watching a game before it is complete, the server doesn't stream any more ticks than were available at the time you started watching the replay. To see the full match, you have to leave the replay, check if the server has finished playing the match, and then start watching the replay again.

Creep.id is documented as being of type string.

In arena swamp and spawn, the id property of creeps sometimes seems to be a number rather than a string. This causes some surprises and difficulties when using that id property inside wasm - for example https://github.com/rustyscreeps/screeps-arena-game-api/issues/4

If you want to view your position in the leaderboard or players around you, you struggle against the "infinite scroll" UI that slowly loads a few more entries into the list. There are no navigation buttons that could get you to say position 100, 200 etc.

At the time of writing I am at position 450 ish in the list, but I lost the will to live before I could scroll that far down the leaderboard. So it would be a nice usability improvement to add some more means to move through the leaderboard.

I just spotted that arena has something along these lines already - so hopefully there's already a secret plan to bring this functionality back to world!


@wtfrank the problem seems to be that in app.css in package.nw, z-index 20 on the history-no-data div pushes the no-data screen on top of the exit bars.

none of the classes for the exit bars have a z-index so end up behind the no-data div.

It looks like this is is caused by a div with class history-no-data, which is above the navigation bars. If you delete this div the navigation bars are usable again

So this is definitely in the realm of a bug report not a feature request!

When viewing a replay you are able to select a creep and watch its health in the right-hand column.

It would be nice if you could pin creeps other than the select creep, and monitor their health too. Monitoring multiple creeps would help with analysis of combat, and it could help make videos or streams of screeps combat more understandable to the viewer.

There is space in the left hand side of the screen that could be used for this purpose, and I've made a simple mockup.

This could be seen as a bug report or a feature request.

When you are viewing a replay with no data available, the buttons that allow you to move to adjacent rooms are not available. It would be great to be able to switch to the adjacent room. Currently you can get "stuck", by moving from a room with replay available to a room without replay data at that tick. You then can't return to the room you were originally viewing.

In contrast, while viewing a replay that has data, you are able to switch to adjacent rooms and view their replay at the same tick

Expected:

with visibility of shard2 room E25N14,

Game.getObjectById("65dc81a3976bd52b1306ce31").isActive() should return true according to docs of StructureTower

Actual:

it returns false even as the tower viciously assaults my innocent creeps

"Check whether the structure can be used" - yes it was definitely being used.

"If the room controller level is insuffiicent then this method will return false" - invader towers don't need a room controller at all to operate, so all controller levels would be sufficient to operate.

It would be useful to be able to set up filters in the console that would let you restrict console output by keywords. The simplest version is a simple search that you can type text in to filter, or it could be more advanced and let you save favourite filter strings and return to them via a drop down.

A very quick mockup of the way it might work.

An example of when this might be useful is that you're investigating issues with a particular creep and wanted to only view logs emitted by that creep each tick.