Discussion: long-range logistics revamp
-
@geir1983 @artch How about a random amount of warp containers per room, between 1-3 that is a randomly assigned number so it gives each room an unique feel.
-
could the usage of warp containers be linked to how often and how strong invaders show up ?
in a way that the more often / bigger volume / more warp containers are built in room (up to 3) the more attracted (and bigger) invaders are ? also as a bonus, it might attract the steal-invaders that would not attack, just try to take away resources from closest warp container
in room without warp containers, there would be no breaking change, and for players wanting to utilize them (in remote rooms or claimed ones) there would be a drawback of more frequent / stronger invaders (should be a minor drawback for high RCL rooms)
-
Invaders are too closely tied to strongholds for that to be any sort of balancing mechanism.
-
@gadjung Actually, this brings another idea: what if every
Creep.harvestoperation in the room decreases decay timer of all warp containers in the room? To the point it is still profitable, but much less profitable than using creep haulers?This will provide additional balancing mechanic that we can adjust for remote mining, but it doesn't affect use cases of "warp containers network" for transfer purposes only, even when this network is inside a sector, not just in highway rooms.
-
@artch Also this will affect network parts if it lies through remote harvesting rooms. Maybe in some situations there will no alternative paths other then through remote mining rooms. Maybe make it so if warp container is near the source this effect applies. Gradually like at distance <= 5 max decay to distance 20-15 low or zero effect. Or strict if distance <= 20-15 100% decay effect.
-
I think the idea, in general, is great of having an alternative to creep only or terminal only resource transport. There are a few things that seem a bit awkward though like warp containers not connecting to neighboring rooms.
As an alternative proposal I would suggest:
- 1 Warp Container per room.
- Warp Container Transfer Range of 1 Room
- 100k Build Cost
- Internal Capacity of 5k
- Decay cycle runs every 1000 ticks and does 500k damage. Requires repair
- Transfer Damage = resourceAmount * 5;
New Functions:
- WarpContainer.repairFromInternalStore(amount: 500) // heals 25000 hitpoints
- Creep.opperateStructure(WarpContainer, {transferTarget: room, resource: energy, amount: 5000})
Decay Cycle That Decays on Timer 1000 Ticks Does Damage to Structure Can be Healed with a function. WarpContainer.repairFromInternalStore() at a rate of 50 units per energy. Or a creep can use a regular style repair for 100 repair points. I think the cost should be 5 energy units per tick equivalent. There should also be damage done during the transfer function.
Needs Creep to call a function to transfer resources. Range 1. This means that if you let an enemy player near it they can transfer out the resources forcing you to defend the warp container from enemies. This solves the issues around ownership.
If a player executes a transfer it becomes "reserved" by that player. If another player transfers it becomes neutral. This makes it similar to reserving controllers currently.
-
@atanner I love the idea, since it solves a lot of problems we have at the moment. However, I think this "reservation system" can have problems when different players try to issue conflicting commands, and ownership can be simply flipped when a player issue two commands in a row.
I think the reservation system can be the same as controller reservation, and the warp container does not decay when it is reserved, since a claim creep is already necessary to maintain warp containers, and a creep is not necessary to operate the warp container, making warp containers easier to use.
-
@atanner like the idea
only thing i'd be hesitant with "reservation", in my opinion there should be no reserved for X ticks etc
One thing that could be also viable is to scale decay damage with how much stuff is in container - depending whether devs intent would be to push towards more or less often transfers
In case 2 or more creeps try to transfer - i'd say the one with more
WORKparts (or just bigger one) should take priority if both have same size/WORKamount, then can be age (priority for older one for example), distance/etc@artch @U-238 did not do enough remote mining to have opinion how it might impact the economics of
Creep.harvestdecreasing decay timer
-
I like both ideas of putting a minimum range from sources and decaying the containers from a harvest action. @U-238's idea of allowing the warp-containers to be closer but increasing cost seems like a good one (more remote mining options the better). I think the decay should be based on energy harvested from the action rather than the action/intent itself otherwise supersizing the harvesters could bypass much of the problem.
Even cooler if we get a new visualization in the client to "show" the sources reacting with the warp-containers when a source is harvested.
-
@atanner This would be an inter-room structure. With many of them, it would create high concurrency pressure on rooms synchronization tick stage and affect ticks performance significantly.
-
@Atanner's micro-terminal idea is interesting. It's harder to implement though. On the surface it would be another global intent which is bad.
With some tradeoffs terminal transfers can be done via 2 room intents, one to decrease the sending terminal's resources and a separate one to increase the receiving terminal's resources. To prevent a resource race condition (possibly duplicating resources) the terminal would need to lock out withdrawals for a tick or two.
The locked out withdrawals could be disguised as "reserving" the micro-terminal before sending. Or it could be disguised as lag, the sent resource are immediately deducted but don't show up at the destination until the next tick.
Kinda nerd sniped myself with how to to interlock a terminal send using only room intents.
On tick 1:
- The sending terminal issues a buffer intent with resourceType and amount.
- The processor records the resourceType and amount it deducted from the terminal's store in a _buffer property.
- The Terminal tick handler saves any
_bufferproperty asbuffer.
On tick 2:
- The API sees the buffer property and automatically issues a blank receive intent for the destination terminal.
- When the receive intent is sanitized or saved the values from the
bufferare attached to the intent (prevent intent hacking). - The processor increases the store of the destination terminal (truncating to fit).
- The terminal tick handler deletes the
bufferproperty.
This is would work for regular terminal transfers. I haven't thought about how it would interact with the market yet. But aside from possible market interactions this would allow players to go back to a 0 cooldown terminal and dramatically decrease the amount done in the global tick processing.
-
@artch This would also make harvest boost slightly more useful as it would decrease the amount of warp container decay while mining if I understand correctly.
-
@deft-code said in Discussion: long-range logistics revamp:
I like both ideas of putting a minimum range from sources and decaying the containers from a harvest action. @U-238's idea of allowing the warp-containers to be closer but increasing cost seems like a good one (more remote mining options the better). I think the decay should be based on energy harvested from the action rather than the action/intent itself otherwise supersizing the harvesters could bypass much of the problem.
Even cooler if we get a new visualization in the client to "show" the sources reacting with the warp-containers when a source is harvested.
What if there is no minimum range for the structure itself, but the decay is dependant on the distance to the .harvest action, sort of like how towers are more effective on short ranges. This could allow WC directly adjacent to the source, but at a high decay cost, scaling down with the range to the source. Make it super expensive when close to the source, then lower costs based on longer distances.
-
The root post has been updated. Let's perform the second iteration of the discussion!
The primary change is that we split warp containers maintenance cost onto a regular repair (mostly like usual containers except warp containers will survive much much longer) and activation cost. Also,
.harvestoperations will increase decaying speed so now warp containers should take their place as one of the alternative ways of transferring energy from remotes instead of creating the single best solution.
-
@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.
-
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?
-
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 - costand adjusted for measuredincome - 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.
-
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?
-
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.
-
@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.
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.
