Discussion: long-range logistics revamp
-
@o4kapuk Thanks for the clarification
-
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.
-
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
-
@gadjung said in Discussion: long-range logistics revamp:
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.
-
Currently my market rooms do about 2000 auto on buying for incoming per tick and deal with a queue to purchase stuff so that's not too bad.
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?
-
A bit more thoughts on "design" of warp containers. I think a lot of people have put a lot of care and attention into harvesting systems using haulers and harvesters. I think warp-containers as specified would make all this code redundent overnight. I also quite like the aesthetic of tendrils going out from a base with creeps heading how to do remote hauling.
With that said I think they should be positioned as follows:
-
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.
-
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.
-
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.
-
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.
-
-
@donatzor said in Discussion: long-range logistics revamp:
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 Yeah, good point. But, spamming terminals must be closer to the attacked terminal than supplying terminals because closer transactions take priority, as usual.
-
@tigga Could just auto-deny transactions from the player w/ creeps in your room attacking you but then I guess some one else (alliance member, ect) could still spam and/or you could start depleting their bucket before you attacked, so there'd have to be some way to detect the incoming spam and stop/adjust it like shutting off the terminal, or rejecting incoming trades from xyz room or player.
-
@o4kapuk If your in range to attack, you'd be in range to have fairly high priority on the spam wouldn't you? Unless your energy supplier from the buy order is much closer and/or you have an arrangement w/ a neighbor I guess.
-
I'm not sure there's a simple "fix". Best I can think of is a way to "reject" something sent via "send". I don't really know what that would look like. Maybe a blacklist of usernames? Maybe it's not a problem that need fixing.
-
@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)
-
@o4kapuk said in Discussion: long-range logistics revamp:
@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".
-
@tigga this is exactly why I said 'not a complete fix'
-
How this does not classify as "breaking" I do not understand... This will pretty much break everyone's market and resource balancing code and on top of that potentially obsolete everyone's hard worked remote harvesting system. There is still so much for me to work on, I do not appreciate having to fully revisit something I have nailed fairly well.
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.
-
Might be a bit different from what is originally proposed, but I think a warp container can be like this:
- 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.
-
@cookies I see some problems with solution that you suggested. The main is warp containers are neutral thus anyone can connect to your network and steal resources. Maybe if warp containers were owned it could fix that. 1 per room, owned and you gotta defent it.
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.
-
OPERATE_POWER will become useless
-
I like the novel approach to warp container upkeep. If the repair route was more energy efficient it would create a more interesting tradeoff.
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.
-
One suggestion that came up on slack to benefit networked warp containers without making them too powerful for remoting was to decrease the upkeep significantly in highway rooms.
@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_TERMINALin this case, or use creeps/warp containers to move energy in.