Discussion: long-range logistics revamp

Tigga

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

Math.min(0, 11 - range)

I assume that's meant to be max?

I guess it's also per-intent? I feel this cost is likely to be lower than it first appears in practise. We already see oversized harvesters to save CPU. Right now for me on MMO my code thinks the sweet spot is around 14 WORK, though that number goes up and down depending on factors. Call it 15 WORK, and now I'm paying a third of the cost than I would be if I had 5 WORK. From 5 energy/tick at 1 range to 1.666 energy/tick. Couple that with the fact I only need charged containers for 1/3 of the ticks, and things are getting pretty cheap agian.

o4kapuk

@tigga

I assume that's meant to be max?

Yes, fixed, thank you.

About oversized harvesters (which obviously costs more in energy and spawn time), do you have any numbers to share, or was it just from the top of head?

Tigga

I think if you give me 1 CPU I can get ~13 energy profit (as of right now, it varies). This is based on predicted income - cost and adjusted for measured income - cost. The difference is usually pretty small.

Put in a lot of sums and that works out as ~12 WORK/creep for maximum profit. 7 extra work costs me ~0.6 energy/tick and saves me ~0.12 CPU/tick, so you can see it kinda works out. The marginal cost on adding an extra 2xWORK, 1xMOVE is ~0.17 energy/tick, ~0.012 CPU/tick saved, so not worth doing at 13 energy/CPU (but would be at 15 energy/CPU). This assumes spawn time is not a consideration which is generally true either on shard 3, or at high GCL.

Assuming this code doesn't have bugs (obviously not a certainty) I think it's reasonable to expect people to have at least 10 work/harvester in remote rooms, halving peak decay to 2.5 energy/tick. Going to 15 work/harvester would cost ~0.4 energy/tick/harvester, and save ~0.8 energy/tick on the warp container, so I'm pretty sure that given I'm already nearly there that's a no-brainer. Going to 20 starts to hit diminishing returns (0.4 energy/tick for larger harvester, ~0.4 saved on the warp container) so stopping at 20 is probably reasonable.

Now with 20 harvest/tick I don't actually need the warp network online all the time. Exactly how the "online" method works isn't clear. Seems like 1 energy/tick while online for the whole room. I probably only need it online 1/3 of the time as I can clear a source in under 100 ticks, saving ~0.67 energy/tick.

So we're getting to the stage where a 3 warp container room with spread sources will cost 1.5 energy/tick (container maintainance) + 0.33 energy/tick (activation cost) + 2.5 energy/tick (harvest intent decay) + 3.6 energy/tick (harvesters). That comes to ~8 energy/tick and ~0.15 CPU/tick for two sources throw in a reserver, road maintainance and other random intents and maybe we can call it 10 energy/tick and 0.2 CPU/tick. This blows my current energy/CPU out of the water - I can get ~4x the energy per CPU spent if I use 3 warp containers/room naively.

deft-code

Is warp-container charging a creep intent or will they self change from energy stored?

What happens to the warp-container's contents when they are not charged? Do the resources drop? Or are they just inaccessible (like a perma-cooldowna) until charged?

Do each of the warp-containers need to charged with 100 energy every 100 ticks or just one of the warp containers?

Smokeman

Deft, I expect that there is literally only one of them, with one storage. Just with 2 or 3 .pos objects that you can interact from. Since a creep can issue only one intent, it's safe from 'accidentally' accessing both pos points, and the contents can only be withdrawn the next tick.

Oh! Oh! Or there are 2 or 3, but they simply share the same store object. Yeah, that's better. The others are just dummies for the UI. and pos point.

o4kapuk

@Tigga thanks, your calculations do match mine primarily. How much you spend on haulers currently?

Now, in your assumptions, do you count transfer intent? Even for 15+ WORK harvesters (harvests in 1/3 of ticks) if could worth 0.9 energy/tick per source. We can activate warp containers by 300 ticks for 300 energy, so saving on activation won't be possible.

@deft-code

Is warp-container charging a creep intent or will they self change from energy stored?

They are self-charging from their store.

What happens to the warp-container's contents when they are not charged? Do the resources drop?

They drop onto the ground. We can't keep them inside because this way it's possible to fill them with minerals (either due to user's bad code or attacker's malicious code) efficiently preventing further recharges.

Do each of the warp-containers need to charged with 100 energy every 100 ticks or just one of the warp containers?

It's 100 energy/100 ticks per room, not per warp container.

Tigga

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

@Tigga thanks, your calculations do match mine primarily. How much you spend on haulers currently?

320 energy/tick for 156 sources right now.

Now, in your assumptions, do you count transfer intent? Even for 15+ WORK harvesters (harvests in 1/3 of ticks) if could worth 0.9 energy/tick per source.

Yeah, I did. With 20W+8C you're doing 0.05 CPU/tick for harvest and 0.025 CPU/tick for transfer, which is where the 0.15 comes from.

We can activate warp containers by 300 ticks for 300 energy, so saving on activation won't be possible.

Sounds good. With all these things there's a balance between giving opportunities for smart code and forcing people down a given path I guess. Syncing stuff to reduce this upkeep would be smart code, but also maybe the "only way". Doesn't make a huge difference to my above estimates anyway.

Really the "issue" seems to be that the majority of CPU in remoting goes into haulers - about 65% in my case. Remove this and you require 3x less CPU. Tying upkeep to harvest intents just leads to fat harvesters (which aren't a bad idea anyway for CPU).

I'd also like to point out I'm doing the naive calculations. It's possible I want to put the warp containers further from the source and use high carry/low move haulers (eg. 20C/5M) to move from harvester to warp container. That'd be low CPU and might be cheaper than warp container decay.

o4kapuk

This post is deleted!

Davaned

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

They drop onto the ground. We can't keep them inside because this way it's possible to fill them with minerals (either due to user's bad code or attacker's malicious code) efficiently preventing further recharges.

Dropping on ground seems very burdensome behavior. Would it be possible to make defunct warp containers have an energy reserved store of 100 units that creeps can put into a container to recharge it? That store represents what the container will use for it's next recharge cycle, and gets automatically refilled from general store if there is 100 energy available.

Then dead warp containers have their main store locked until they are recharged, but the resources don't fall on the ground. I'm not even sure what fall on the ground means given that the stuff inside isn't inside any one container.

Random other thought: What if you could use batteries with warp containers for energy supply? Just as a possibility for actual things a commodity can be used for.

o4kapuk

@Davaned We thought about it. But that sounds like a great complication of the whole unified Store API or a weird exception out of it creating unobvious edge cases. Dropping resources seems more like in the spirit of these structures (aimed to serve as transport, not storage)

Davaned

Yeah I can understand that, although this is a case of an energy-powered structure so having a .energy specific store is pretty intuitive, imo moreso than "one type of the resources you put in the general store disappear". How will the dropped resources behave then? Randomly sprayed under each warp container? This will drastically increase the pain of having skipped ticks.

Also, withdrawing all energy from a container before it renews becomes extremely powerful as harassment. If they had a 100 .energy buffer that keeps gets refilled internally/from creeps that can't be withdrawn from it would take 100ticks of room control to have the network fail vs 1 tick.

Formal suggestion: Internal deposit-only .energy store (like a nuker) of 100. This gets consumed every 100 ticks to maintain the network. If it's empty it gets refilled as highest priority from the internal store, but can also be creep deposited. Reduces complexity of warp container usage too since its more fault-tolerant and you have security that the container will be powered for next round.

Shibdib

This just seems like one of those ideas where it feels unnecessary. Why not flesh out power creeps more or make commodities less useless. More depth there would help more than another min/max tool that a small percentage of your playerbase will use

TehFiend

@o4kapuk Do you have a rough ETA for the terminal throughput limit by chance?

o4kapuk

@tehfiend It's soon to be published at the PTR

Jman

I know I'm too late to have my input considered with this update, but: Reading though what everyone else says here, warp containers sound like a "best solution" to remote mining (less cpu and energy cost/tick). The fact that they use energy, and decay costing energy seems overly complicated to upkeep (vs links with use energy and containers that decay).

I'd rather see structures that don't require creeps to preform tasks on them for them to do their job (like links, labs, terminals). Warp containers still require creeps to move their energy across room borders, and increase code complication but less cpu. If something like pipelines, that could pump less energy the bigger the system is, were introduced, I would think you'd see haulers and pipes depending on the situation (removing the best solution problem).

With respect to the terminal change, I'm not sure why civilians have to see the consequences. Just that same that structures can't be destroyed when hostile creeps are in your room, limit/block terminal calls.

An alternate suggestion to blocking terminals: Make mortars a thing. Essentially mini nukes that can be loaded up with different resources (where certain resources have different effects, just as boosts help your creeps, these will take away from enemy creeps). For instance if KH is loaded, it will reduce any creep/structure that has a .store property by some percentage.

I personally would like to see more inter-room actions, instead these updates would lessen inter-room actions (limiting terminals) and strengthen intra-room actions (with warp containers). lets see more things like mortars and pipes.

Also, I'd be interested in seeing what internal suggesting the dev team came up with even if they were considered too much of a change that they'd break peoples code.

Tigga

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

@tehfiend It's soon to be published at the PTR

How about warp containers? Still not convinced they're either needed or in a good place balance-wise based on the last update.

Tigga

Any updates?

Zpike

I just rejoined the game after a long time away and I've been setting up individual rooms to focus energy on so as to level them up as quickly as possible to compete with the older more established players. The journey from fledgling to maxed out rooms is long and tedious and the only way to speed it up is to focus my resources. From the standpoint of new players with limited code bases, this nerf on terminals looks to limit my options for leveling my rooms up after a respawn and looks to impact new players with no means to use power creeps in a severe way.

It is already very hard to quickly come back after a wipe and transfering all my energy through terminals to a focus room is required to speed that up at all. Using a leg force of transports is a huge CPU and Spawner hit for a new player and is thus not much of a solution.

I urge you to consider the impact of this decision to limit energy through terminals on respawning / newer players.

Tigga

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

It is already very hard to quickly come back after a wipe and transfering all my energy through terminals to a focus room is required to speed that up at all. Using a leg force of transports is a huge CPU and Spawner hit for a new player and is thus not much of a solution.

You can do RCL 7->RCL8 in under 50k ticks with without power creeps or external shipments. Seems fast enough to me. Remember batteries are a thing and while factory cooldown means you can only get 50 energy/tick from them, that only uses 5/50 of the terminal throughput, which gives you 95 energy/tick coming through total. Combined with upgrade boosts (going to use some terminal capacity, but 2x on energy) and local energy harvesting and 50k ticks is very acheivable.

You can move a lot of energy with creeps without using much CPU. I think it's a fine solution. If you're within about 5 rooms (call it 250 tiles) unboosted haulerers can move >15 energy/tick/CPU. Seems reasonable to me. I agree, you can be limited by spawn time.

Also, warp containers.

Also, I think most respawning players will have many rooms to level concurrently and there's no real need to push one at a time. Unless you're spending hundreds of credits/tick on energy you're not going to be hitting these limits.

I'm not trying to say it won't be a restriction, but I am saying that it isn't exactly slow to level rooms.

wtfrank

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:

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.
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.
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.
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:

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.
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.
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.
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.
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?

It narrowly focuses on the specific issue with PWR_DISRUPT_TERMINAL, and doesn't change other parts of the game.
More decisions for attackers and defenders to make.
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?

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).
Introduces a new effect expiry mechanic that doesn't exist on other effects which might make the behaviour harder to understand.
doesn't tie in with the mineral compression mechanic (unlike the terminal rate limit under discussion)