Last update: May 26 15:45 UTC

We've seen many discussions and suggestions about combat aspects of the game, especially high-level combat which is not perfect currently. We were brainstorming a lot, discussing many possible solutions, both suggested by the community and by the team. In most cases, the conclusion was: “too breaking, unfortunately”. Finally, we're ready to come up with a set of changes aimed to remedy the most frustrating part of high-level combat: repair. More precisely, the issue is not that repair is overpowered itself (it's not) but that it's trivial to supply more than enough energy for repairs (either from other rooms or the game market) without any way for an attacker to interrupt it. To solve it, we're going to implement the following set of improvements and features.

Terminals inbound throughput limit

Terminals throughput for incoming transactions will now be limited. A terminal will be allowed to receive only a certain amount of resources. When the limit is exceeded, the incoming transaction will not succeed.

The throughput limit is supposed to work as leaky bucket (which many players are already familiar with), i.e. the limit unused in the current tick will be accumulated for future usage (including burst usage up to filling the whole terminal at once). The limit will be shared between all inbound transactions for the terminal generated by all calls of StructureTerminal.send and Game.market.deal for the current tick. Preliminary numbers would be 50 resource units per tick accumulated up to a maximum of 300,000 resource units.

Changes in PWR_OPERATE_TERMINAL and PWR_DISRUPT_TERMINAL

In addition to the existing effect, PWR_OPERATE_TERMINAL will also increase the inbound throughput of the terminal by additional 50/100/200/300/1000 units per tick depending on the power level. This will supposedly provide a simple way to preserve special solutions that rely on high terminal throughputs, like GCL farms or room burst upgrading.

PWR_DISRUPT_TERMINAL will no longer prevent withdrawing. Instead, it will reduce the accumulation of available throughput by 10%/25%/50%/80%/100% (other effects like increasing transaction cost and longer cooldown is still under discussion). This is supposed to make short interrupts of terminal disrupting less catastrophic for an attacker and to remove the possibility of avoiding disrupting by destroying and rebuilding the terminal.

New structure: Warp Container

Warp Container is an unowned structure that can be built in any room (including rooms without controller). Each room may contain 2 or 3 (not decided yet) warp containers having general-purpose storage that is shared between all warp containers in the room. When you place a resource into one warp container, it can be withdrawn from another one on the next tick. Withdrawing from a warp container triggers cooldown on all warp containers preventing further withdraws from either warp container until it ends. The cooldown length will depend on the number of withdrawn resources, preliminary 1 tick per 1,000 units (rounding up). The cooldown will not prevent resources transfer into warp containers.

These structures are supposed to be expensive to build and maintain. The construction cost is 100,000 energy.

Every warp container will decay by 5000 hits once per 100 ticks (given their total health of 10 million hits, it takes 200,000 ticks to lose warp containers). Every harvest operation in the room will cause additional decay (Math.max(0, 11 - range) where range is the distance from the energy source to the warp container). In addition to this, containers must be charged with 100 energy every 100 ticks (for all warp containers in the room) to be able to hold resources inside.

All the numbers above are still not final. They may be changed upon release.

It is also worth mentioning that while these structures are walkable, they will not catch resources dropped over it.

A "network" of warp containers among owned and unowned rooms may be an alternative replacement for terminals with much higher throughput, if you manage to maintain and defend it. Basically, you will be able to transfer 1,000 resources per tick, with the speed of 3 ticks per room.

We plan to release all these features and improvements in the next major update. Discussions, comments, suggestions, objections are welcomed as usual!

"It is also worth mentioning that while these structures are walkable, they will not catch resources dropped over it."

the issue is not that repair is overpowered itself (it's not)

Yes it is

Terminal changes look alright. I still think repair needs a tweak to be less effective, but maybe this is fine. 50 units/tick seems about right to me.

I think warp containers are OP. Especially if it's 3 per room. You said you didn't want "too breaking" but I think they are.

A link running at full throughput over 10 tiles costs 2.4 energy/tick and moves 80 energy/tick. Two warp containers have 12.5x the throughput at a cost of 2 energy/tick.

Mining a two source room currently needs haulers and containers. The containers are 1 e/tick. A hauler will typically cost you ~1.5 e/tick/source. Depends a bit on range. Warp containers aren't really that much more expensive (for 3), and you save a lot of CPU and spawn time.

IMO the throughput is too high and the cost too low. They almost make all current hauler+harvester solutions redundent. I don't think 3 is a good idea. Two might be interesting (adding another stage to the logistics chain for souce->warp container) but as-is, probably still overpowered.

I guess it might promote usage of compacted minerals but still it might impact market

Won't the limit on .send and .deal negatively influence market in itself by making ppl selling/buying less stuff due to desire to preserve bucket ?

I guess it might promote usage of compacted minerals but still it might impact market

50/tick is a lot. You can trade bars, batteries and boosts. Seems fine to me.

However, buying energy or bulk orders does tend to go anywhere of the tens of thousands to higher depending on what the other players do deal with, so can see a room auto-buying something depleting its bucket and/or needing to manage its auto-buying better when purchasing bulk orders (ex: buy power/collect power, need to plan to over-buy energy for x ticks to insure 'minimums' are kept, repairing walls, praise rooms needing a cycle to restock)

I already use PWR_OP_TERM to reduce eng costs in my market rooms so really it just changes my auto-buy logic from sell orders from 2k to 1k per tick if I don't want to incur using more of the 'bucket' (I presume)

Does this make terminal-based spamming attacks more effective though? since your actively using up your opponents 'total capacity' while your sending is not capped, their receiving is, spam enough and they couldn't buy enough on that terminal?

With that said I think they should be positioned as follows:

1. Given infinite CPU, they're worse than haulers+harvesters. Right now (especially with 3 per room) they're not. They might be better even with infinite CPU. Haulers cost a lot of CPU just on move intents, so freeing up all this CPU and saving energy seems over the top. Oh, and saving spawn time. And road maintainance.

2. Even in limited CPU environments (eg. regular <28 GCL play on shards 0-2) there should be a choice. Either the cost or throughput (or both) of the warp containers needs to be worse than haulers. At this point you should be trading CPU/spawn time for energy efficiency.

3. But in some rooms they should be really neat. Avoiding nasty swamps/tunnels. Finding two sources close together that can share a single warp container and reduce maintainance. That sort of thing.

4. Throughput should probably be closer to links. So 5-10x lower.

Obviously these are all pretty hot takes. Will ponder some more. One thing that does occur to me is that these do favour those of us with lots of spare room. All those CPU/spawn time savings would let me harvest a lot more rooms.

Does this make terminal-based spamming attacks more effective though? since your actively using up your opponents 'total capacity' while your sending is not capped, their receiving is, spam enough and they couldn't buy enough on that terminal?

That is a good point. Might be a bit easy to shut down a terminal. Just spam it with minerals and starve them of energy when attacking.

@tigga a simple fix could be prioritizing deal transactions and intra-player send transactions over other transactions. Not a complete fix, however, but at least something. If this is a problem to be fixed (I'm not sure about it either)

It'd give you 50/tick, which may be good enough, but it'd kill your "bucket".

I enjoy seeing as many screeps moving about as possible, I rather see less teleporting, not more. Teleporting removes geostrategic gameplay and removes logistics which is otherwise super important in warfare.

Just disable the terminal entirely when hostile creeps are in the room (or similar to 'safe mode' create a 'siege mode') and force logistics on the defender side to try and supply the room.. with haulers. Very common with sieges throughout history.

No repairs with hostile creeps in room could work also forcing the defender to leave the ramparts and try clear the room.

• Limited to 1 per room.
• Each provides 500 capacity.
• If two warp containers are in rooms next to each other, they are in the same part of network. Their capacity adds up, and they share content. Total capacity cannot exceed for example 4000. This allows creation of huge network if you can defend. If previously disconnected networks are now connected, the content is added and merged in the new network. If previously connected network is broken up, content is divided evenly into subnetworks.
• Cooldown between withdrawing is fixed to 10 seconds, just like the send cooldown for terminals.

All numbers / functions are suggestions and can be changed.

This container will not replace containers or links at all, and throughput is much lower than terminal because of its limited capacity and cooldown when withdrawing, but helps for remotes and when terminals are blocked.

The second is cooldown should be triggered by sending to another warp container and not by creep withdrawing from it. Also can't imagine how capacities can add up. If container "merges" (shares) with near room warp containers, that containers can't be shared simultaneously for their neignbour rooms.

I think warp container upkeep is a bit too cheap (as others have pointed out). I suggest an upkeep cost of 3 energy per tick.

A sketch of the costs of offroad remote mining to use as a baseline:

• ignore reserver and drop miner costs since they don't change.
• .5 energy / tick for container upkeep (not 1 as stated elsewhere).
• 1.66 energy / tick for a 25C25M hauler up to 60 tiles travel

The upkeep of 2 warp containers must cost more than 2.16. I'd double the upkeep to be absolutely sure hauler remote mining is more efficient. So 2.16 energy per tick for each one, but round up to 2.5 or 3.

Keep the energyless decay where it is (needs 1 energy / tick of repair). Then players can juggle resources and repair the container spending more intents but improving energy efficiency.

It might make sense to keep the upkeep costs low for Claimed rooms to encourage players to incorporate them into base design.

@zachiever said in Discussion: long-range logistics revamp:

OPERATE_POWER will become useless

The argument being that you can't use more than 50 e/tick in a room due to terminal limits? I guess you have to pair it with OPERATE_TERMINAL in this case, or use creeps/warp containers to move energy in.

I dislike these changes, but would like to know the ideas and purpose behind these changes.

Changing two parts of the game that feel good, terminals and remote harvesting.

What is the design idea behind these terminal changes? Is the terminal change's purpose in order to nerf terminals while being under siege by players? GCL rooms? Or just upgrading bursting? Or all the above in hopes that we use power more?

For Terminals instead of creating a new variable 'bucket' that will limit transfers, why can't it just use cooldown. Recieving would add 10 cooldown to terminal, multiple receives would add 10 cooldown. Terminal operate can reduce by 50%. While terminal disable increase cooldown or stop cooldown countdown.

Warp Containers seem interesting until you said they can be built in non-controlled rooms. These seem like a best solution for remote harvesting with a downside of energy maintenance, making previous solutions obsolete. With the way you decided to balance this through energy maintenance - it'll either be too good or useless due to energy. Or balancing this by not allowing it to catch dropped resources(not a big deal, literally talking about just a creep.transfer as this being balanced/unbalanced?) . This doesn't feel like it will create code diversity, and creating a "single best solution" to remote harvesting.

By creating warp containers, what's the purpose of links now? Doesn't make links obsolete? Can't we just have operate link that makes it global? A operated link can send to any other link in any room? Or a operated link can receive from any link in any room?

We were talking about high player sieging/fights in other posts, and I don't think a single player mention terminals as an issue, and yet here we are changing it. Due to changes in terminal you want to balance it out by breaking remote harvesting, something that I think everyone currently enjoys as is.

Attacking a terminal every tick by overwhelming, the counter you're suggesting is to always send materials to get priority sending.

But it doesn't fix the problem - where I can send over and over again every tick multiple times to attack the terminal.bucket, while you send what you need. You may get what you need in, but by then I've sent 10,000's of unusable resources.

This will make it more so I would rather attack the terminal through send than disrupt. One requires power enabling and be inside the room. The other just requires terminals. So creating a 'best' solution.

I have done this type of attack before and while it's a hugh drain on resources, if the target player isn't active it can be effective. .