Discussion: long-range logistics revamp



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


  • Dev Team

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



  • @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.


  • Dev Team

    This post is deleted!


  • @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.


  • Dev Team

    @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)



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



  • 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

    👍


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


  • Dev Team

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

    👍


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



  • @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.