Terminal Nodes and long-range logistics revamp

[undone whale]

50 units per tick, per terminal. So, if you want more, build more rooms with more terminals. That is the clear solution for GCL temples. Likewise for the frontline of a war - have multiple fronltine rooms each recieving 50 e/t and punping out units.

For other cases where terminals would be used beyond 50 units per tick currently, like raising rooms, the new solution would not be viable and the best option would just be to wait for it to raise at 50e/t (plus whatever it mines itself).

[glacial panther]

It's a receiving limit not sending, so repairs are still limited and you need energy from other rooms

[undone whale]

Yeah, you would need other rooms to support for siege defense. That is the goal of the change.

But as for how the change affects long range logistics as a whole, terminal would still set the standard for efficiency (just with multiple of them required for throughput). So whatever new thing is created would be useless for that role unless it is competitive with terminals in efficiency.

[distant glade]

I think original warp container is complained about because it fundamentally replaces remote hauler. I don't see why this bus idea won't replace remote hauler either, but it seems that artch is keen on using construction cost as deterrent instead.

[glacial panther]

The main problems with original warp container in my view were:
Not feasible to defend when under siege
Needs a creep to constantly travel between rooms to do the transfer

I dont think there was complaints about it replacing the haulers or I must have missed them

[distant glade]

some concern from Tigga.

but more from aesthetic standpoint.

[glacial panther]

There were changes in the design to discourage use in remote mining yeah

[undone whale]

I think that the devs miss the mark in comparing the new thing to creep hauling while calling it "long-range logistics" because long range logistics is terminals now and it would still be terminals after the nerf. The new thing would only be long-range logistics if it competes with terminals.

[glacial panther]

Warp containers are more efficient than terminals

(Unless the rooms are really close)

[zinc quest]

And even the current bus idea just doesn't compete with terminal in throughput (u/t), even at the lowest lever settings

[distant glade]

how do you measure u/t? assuming full 3 spawn usage?

[zinc quest]

Single event of moving 1250 units. Single creep analysis, spawn time added in.

[distant glade]

technically, you can use 49C1M with dedicated puller at the end instead.

[undone whale]

Maybe? It's hard to say. They would be extremely complicated to manage, though, because they need a creep at each room boundary along the way to hand off. So that's a large and complex cost.

[zinc quest]

Technically.. for ease of calc, just assuming the same creep across numbers atm.

[distant glade]

well, if you do optimize for it, it does makes the u/t a bit more favorable, also you can use all 3 spawn as well. So the real u/t number is about 3x your calculation.

[zinc quest]

I am tempted to find absolute throughput using all 3 spawns of a room, no boosts, no pullers.

[distant glade]

assuming no recycle, it's 3*2450/150 = 49 u/t

actually, for non-energy transfer, recycle is irrelevant for u/tick calculation.

[true shuttle]

you can still transfer resources, just via creeps

[zinc quest]

I think its a good deal worse than that.

Alas, another calc for another time. Back to work o7

[undone whale]

For a link intended to move up resources in peacetime, you could have it be a 2-way route so a creep can make many trips per life. In wartime, you probably want to use only one-way routes, but you can still receive the output from many source rooms at one destination. And you can recycle to gain extra energy on top of what they carry.

[true shuttle]

and i guess, in-war, use-case for defender, would be to ship boosted quad/defenders from other rooms

[glacial panther]

Sure, I wasn't saying you cant transfer resources, just would it actually be a feasible way to do so

[distant glade]

regardless, if the aim is to give players new go-to owned-to-owned transfer method, I don't think this bus idea is going to be used for that use case very much.

[true shuttle]

you'd be limited to spawn capacity, and depending on design, you could pop 1M49CARRY that would ship ~2.5k energy + whatever recycles over few ticks
especially if you'd make chain of gateways + creeps

[distant glade]

chances are, if bus goes through, it will mainly be used to have even more cpu efficient remote mining, and for pumping temple. Maybe only occassionally used to transport energy to frontline room.

[undone whale]

I think that the throughput would be good on busses in any case, but the efficiency would also need to be good (compared to terminals) to make resource transfer by them viable. If not, then their only use would be war. Which could still be cool, but would not be the original goal.

[true shuttle]

though the design afaik was not explicitly to replace terminal

[distant glade]

IMO, better-than-terminal intra-empire transfer method is ok, after all, terminal remains the only way you interact with market, and probably the only infrastructure left that can bring you lifeline during siege.

[undone whale]

I think that is an error on their part. They chose the topic "long-range logistics" and for that, the relevant competitor is terminals (even after the nerf).

[distant glade]

especially with their "must be worse than creep hauling" requirement, which automatically makes it worse than terminal unless you want to blow up the transfer limit.

[true shuttle]

but still having G - > E.CG -> E.CG -> E is enough to send 2.5k e in gateway-count (+1?) ticks
(G - entry, E - exit, . - free tile, C - empty creep)

[undone whale]

The new thing would be much more complex and less convenient than terminals. So it would have to be better than them in efficiency to compensate for that.

[true shuttle]

logistics could be applied both for resources and creeps :p

[distant glade]

now there are 3 orthogonal topic active, which complicates the design discussion: 1. bus as long range transfer method, 2. bus as power projection mechanism, 3. bus as remote mining enhancer.

[true shuttle]

1 - noone hauls things via creeps (if they really dont have to), so i'd say this is not viable without any meaningful change in terminal (which were not presented) so i'd drop this from discussion
2 - not much here i'd say, because i 'd say everyone at high-enough GCL will have them in their remotes.
building them outside of "zone of influence" poses multiple challenges, and opens player to attacks and forcing dropping their construction/gateway
in theory allows for easier defense of owned remotes / backstabbing siegeres but not sure how much that'd change since hostiles can use it also

3 - poses interesting area for optimization (claiming further remotes or improving existing logic)

[distant glade]

yea, the problem is number 1 was the reason we have this whole discussion. And I think it is impossible to be very mainstream in that use case without dropping "more expensive than hauler" requirement. Except for bringing resources to frontline room in total war, but as droidfreak also voiced, it too, compete with just building terminal in the next room to "buy" another 50 u/t transfer rate.

[true shuttle]

i think building 2 gateways is cheaper than raising room to rcl6 and building terminal (or should be, but then again, i'd not think about this structure as "terminal replacement/improvement")

[distant glade]

you don't build 2 though, you build 2 times room distance.

[true shuttle]

yes-and-no, you'll probably already have them in "starting room" remotes

[distant glade]

depends how deep your supply route goes. if it's just from nearest room, may not be that expensive, but you are still limited to 2 terminal income, just with extra step.

[true shuttle]

so as long as you're not trying to leapfrog a lot of rooms "it should work", i'd not "force" to make this a viable scenario otherway

[distant glade]

anyway, it does show that there are lots of constraint that is hard to satisfy at the same time. Are we going to make it cheap to compete with RCL6 + terminal cost? or are we going to make it expensive to deter remote mining use, as artch has indicated previously.

or are we going to make it have very high decay, so using it for remote mining is unprofitable compared to the maintenance cost?

but with high decay, it also fundamentally lose attractiveness in long range owned-to-owned transfer as well.

[glacial panther]

I think the devs should drill more into the requirements and what the goal is, because these past few days it's looked like that is getting a bit lost and it's hard to provide feedback on something that's getting out of the original design

[zinc quest]

@distant glade you and your funny scenarios. Ignore the Creep transport analysis there, it is off due to your body change presuming MOVE isn't necessary for busses. 😉

With the standard 25C25M creep:

[true shuttle]

to put that into perspective i'd consider

• green ones as "valid use case"
• red ones as stretching the functionality to make it work

[distant glade]

well, I think the requirement is some kind of CPU-efficient long distance transfer method that somehow have worse energy tax compared to creep hauling. I'm not sure what is the devs true stance on remote mining, because seems like they want to deter that use case a bit via building cost, but not fully forbid it.

[true shuttle]

so imo it should work "well" within close-knit empire, allowing i.e
single room to provide miners to every remote within vicinity of gateway-network,
easier redistribution of remote energy income

and less for sprawling empires / leapfrogging

[zinc quest]

@ 70 TTL/Jump cost:

[distant glade]

I think the bus is supposed to only work if you have natural room exit

[true shuttle]

did not zoom map, but the general gist is there :p

[distant glade]

you are assuming remote mining already uses bus? I presume?

[true shuttle]

yes

if it does not pay-off to have it for remote mining i really doubt anyone would care to build it for anything in 1st place (assuming terminal stays as-is)

[distant glade]

terminal is planned to be limited at 50 resource/tick receiving limit.

consider with battery compression/decompression, you can stretch it to 95 resource/tick

I think even with this limit, terminal is still the go-to transfer method most of the time

[true shuttle]

no, it's supposed to be leaky-bucket, so you can burst 300k

[distant glade]

yea, I mean 50/tick sustained long term

[true shuttle]

and keeping, even a short, gateway network because maaaaybe someone will attack you strong enough ?

[distant glade]

in that case, wouldn't they dismantle your gateway network first?

[true shuttle]

ye, kind-of

or just put a boosted 40A creep at one exit / one entry

if someone can siege you "that hard" they usually also prevent any movement around the room

[distant glade]

so, this seem to be targeted towards peacetime usage, but you need to have good reason why your peacetime usage is more than 95/tick over very long period.

[true shuttle]

temple-rooms

but then you can use the network to have remotes from big area directly feed it

[distant glade]

exactly, that's what I was predicting, this will just be mostly temple room mechanic.

[maiden marlin]

but then you can enable power and use operate_terminal power ^^

[distant glade]

yea, even less reason for terminal replacement then.

[glacial panther]

Power processing also uses more than the terminal limit but yea in that case just use operate terminal

[true shuttle]

also with the terminal limit, defender is forced to do something else than just burning energy on repairers, like send quads from other rooms/same room and engage in proper combat

[distant glade]

power is 50/tick, no? you can use battery first I think, unless you also boost it with OPERATE_POWER.

[true shuttle]

which would make game more interesting

[glacial panther]

Yeah 50/tick unless you operate, plus sending in the power, and any other resource usage

[distant glade]

I think if you use OPERATE_POWER you can also use OPERATE_TERMINAL to balance it. I think if we allow using power into the discussion, then it's even less reason to use the bus for resource transfer.

maybe if they also add OPERATE_BUS with interesting effect then it can compete again, but otherwise I'm not sure.

[undone whale]

There are multiple cases where that might be true, but none in which something less efficient (and simultaneously much more complex) than terminals would be a reasonable alternative. It would either be nothing at all, or it would be multiple terminals.

[undone whale]

You should just process power wherever your energy already is anyways, rather than moving the energy to it. Much cheaper that way.

[glacial panther]

The limit also considers buying, and I believe most of the bought energy goes into processing power

[undone whale]

In that case, buy energy in multiple rooms and process power in those rooms. They should probably be doing that anyways to avoid extra taxes.

[glacial panther]

But it's still a energy usage that's contributing to the limit. You can't say only use past 50/tick would be temple rooms and ignore a large ongoing transfer through the market in form of power processing

[true shuttle]

i mean the current idea for change being:

• terminal 300k bucket with 50/t
• gateway structure (entry-exit)

achieves quite desired (imo) things

• shift siege from "energy burn" to more "active defense"
• gateways can help defender to bring defense-creeps faster or intercept/backstab attacking-creeps
• gateways can help attacker to bring attack-creeps faster (at significant effort)
• gateways introduce new reason for ppl to communicate (this gateway is just for remoting, not to attack you, pinky-swear)
• gateways introduce new mechanics for remote mining and general logistics (i.e with specific rooms providing specialized creeps or redirecting hauling from remotes

so the main change is mostly
i can burn relatively infinite energy to defend room to i can bring creeps from another rooms to break siege

where first one is relatively easy to code and boring, and other gives some challenge to both parties

[wary surge]

It seems to me that the weak point becomes the bus stops.

They're exposed, can't have ramparts, nor towers to help defend.

If they cost millions of energy to build and have ~30M hits, they'll go down long before any siege worthy of the name really gets started.

The defender won't be able to rebuild them under fire.

[undone whale]

Yeah, they should not cost that much IMO.

[wary surge]

So you could do cheaply tens of millions of energy worth of damage within hours.

[solid elm]

Is it ok to suggest another concept? Or the overall structure is already set

[zinc quest]

Please

All the ideas

[solid elm]

How about a warp gate s.t.

1. One way portal
2. Should start in your owned room and end in unowned room including SK, center, and highways
3. Warp gate in unowned room is neutral, do not decay, and cheap. Warp gate in owned room has owner, decay only when connected, more expensive
4. If you build a warp gate and connect('roomName') and the room has viable neutral warp gate, they are connected.
5. Warp gate in your owned room that is connected has huge decay based on the distance, work as duration. So players would usually build gate, prepare creeps, connect and jump in.
6. You can use this to haul resources, offense, and defense. If you have adjacent room that is under your control, you might be able to funnel enough resources

Things to discuss : should it be one way / Their cost and decay / owned room start restriction / neutral room end restriction / end gate should be destroyed if connected gate is destroyed?...

[pine ice]

I think I would just warp to an adjacent room that I'd keep unclaimed to abuse the no decay bonus

Adjacent to the target of course

[solid elm]

You should start from your owned room which has decay

[pine ice]

Of course but it basically halves the cost compared to intended

[solid elm]

I mentioned end point should be neutral. So it's not possible to connect owned to owned at first

[pine ice]

Oh yeah true

I'm stupid 😭

[silver ocean]

Explain please, i justified 100 above

[silver ocean]

I dont think that is correct, terminals cost a lot more per unit transfered than creeps at full capacity right?

[zinc quest]

Cheapest settings artch mentioned + 100 TTL / Jump. Terminal and Creep transfer rates should be right. Silly numbers in the Bus idea section (e.g. H14:K14) likely mean untenable. Stupid scenario has the floor lifted and thus the numbers are off however much row 22 is off a whole number.

[undone whale]

If it costs 100 ttl per one room moved, then it would have double the energy cost of creep hauling (in TTL alone). That level of cost bans it from being useful for long-range logistics and remotes.

Furthermore, that level of TTL reduction also means that they would reduce rather than extend the distance which combat creeps can travel. In very niche situations, maybe the fast response time would be worth the shorter range, but in the vast majority of cases, it would just be bad.

[silver ocean]

Fair, i think i will tap out for a bit until requirements are a bit clearer. Right now this feels a little circular as people are not just debating the balance but also what purposes structure should be good for and what it should be bad for. Without a convergence on that, we cannot hope to balance this. Hopefully artch makes this more clear soon.

[silver ocean]

That isnt quite right as a moving creep needs move parts and a telporting creep could be all carry, hence why i said 100 before, i envisioned all carry creeps moving in a loop with transfers happening at either end

[undone whale]

Ah, true. That would make it more like on par with hauling - if that was the only cost.

I still think that it would be non-viable for long range logistics, though, since creep hauling is already.

[wary surge]

Terminals cost about 0.03 energy per unit per room at short range, less at long range. Creeps cost about 0.1 energy per unit per room with roads, more without.

A reasonable comparison is that creeps cost 4x more than terminals.

(It's actually worse for creeps since they have to go around terrain features)

So maybe even 5-7x more for creep hauling.

There are also spawn time limitations on throughput.

If you dedicate a spawn to hauler creeps, you can get 50/tick throughput out to a distance of 4 rooms.

Past that, you get less throughput or need to dedicate more spawns.

This would also apply to any logistic system that reduces TTL of creeps by similar amounts as walking.

So that will cost at least 40 e/t and tie up a spawn and also require road maintenance and may cost more or give less throughput if there's swamps or walls in the way, while even after the nerf a terminal will also give 50/tick throughput to 4 room distance for a cost of 12.5 e/t.

That's why anything that costs more than creep hauling will be useless for long-range logistics.

Something like the buses might still be useful for intent reduction in remote rooms even if it costs more energy (but not very useful if the spawns can't support it), or response time reduction in combat (until the bus stops are destroyed), but the topic of this suggestion thread is about "long -range logistics revamp".

[minor reef]

Alright, what if we balance portals so they only make sense as short-term, "on-demand" infrastructure? Terminals and creep hauling handle permanent logistics (long and short range), while portals are for "special projects" - moving massive amounts of resources or creeps in a very short window, after which the project ends. This would mean:

• Very high base maintenance cost – high enough that maintaining them permanently is never cost-effective for any purpose.
• Low construction cost – cheap enough that the immediate transport "profit" easily covers the building price.

Potential scenarios:

• You need to kickstart a new room. You quickly set up a line, pump in resources and builders, get a Terminal up, and then just let the bus line decay.
• A conflict breaks out. Both sides can rapidly deploy supply lines to the front, and both can try to sabotage each other's infrastructure. Once the conflict is over, the lines are gone.

Does this feel like a more solid niche for the feature?

[true shuttle]

imo it would make sense if one does need to build only 2 of them or they have range of i.e 4 or 5 rooms - as in you dont need to build a chain of them tu effectively use

would be perfect for between-room connections when you're in a pickle (to ship creeps / resources-in-creeps) or for invasion.
i like Harabis logic with .connect(roomName) / .connect(gameObjectId) , with modification that exit-gate is in owned/neutral room - has to be more strategic since then anyone can jump into your gate in unowned room

one thing to account for - for remotes, if set-up correctly, PC could boost sources to offset the cost and make it still viable to have as a permanent solution (same for really big empires, or players with Kalgen-level energy income 🙈 )

[minor reef]

This would defeat the whole idea of cutting off enemy supply chains in a conflict

[true shuttle]

it would be 1 creep/tick though, 2.5-10k capacity depending on boost (with 1M49CARRY)

also, could tie the "load" of creep to the maintenance cost

other way to allow "cutting off enemy supply, could be

• it needs to be in range >6 of any owned structure in room, so player cannot set it next to storage
• owned controller cannot be blocked
• room cannot have safe-mode
• room cannot have a nuke landing

because my worry is that it might have really niche usage other way.
coding the logic and complexity that it brings, might make it not worth the effort :/

[distant glade]

yea, that seems solid, good if you want humongous burst transfer rate, but doesn't destroy any other aspect of the game.

[true shuttle]

@minor reef what would be the "desired/estimated" build time of each gate, 50-150 ticks ?
(as in feasible for single build creep to build 1-2 gates outside of owned room?)

[distant glade]

something like have its natural lifespan be about 500 tick without repair, but if you have carry creep convoy already lined up, you can essentially burst supply the destination at about 1M+ energy with every tick sending 2000+ energy over. With such short lifespan, I think you need to synchronize its completion time to prevent decay from eating your transfer rate.

You can also standby the portal at 99% completion before activating it with a 1W construction creep if you need to bank the burst transfer for emergency.

I think something like 10k construction cost, 1M health, 2000 decay is good IMO. Need 20 energy/tick to maintain permanently, so remote mining is unviable. Only needs 250 tick to construct with 40W creep, and the "tax" to send 1M resource over 10 room is about 200k for round trip network, so it's worst than terminal already, you won't use it unless you need the transfer rate.

[wary surge]

Hmm, thinking about the "build up terminal room from nothing" application, that would imply something like 1.5-2M energy to go through the chain.

[distant glade]

I think with 250 tick construction, you can afford to build and send 2 waves

or just build 2-lane gateway

besides, you can't store the entire 2M energy in 1 go without power creep anyway.

[wary surge]

You probably want it over less than 20k ticks so it fits in a safemode.

Which is fairly easily feasible right now with haulers.

[distant glade]

yea, I am envisioning 500 tick transfer window actually. The way you use it most of the time is to have the constructionSite be at 99% most of the time, and you just complete it when you actually need it.

[wary surge]

You might want warp gate like things if you want it done faster than that.

E.g. if there's an enemy with a killzone around your target room.

[vapid minnow]

It seems like in exchange for the setup complexity, static routing, and defense requirements for a one-building-per-room chain it would be nice if the new transit was better than new terminal at both max throughput and energy/unit transported. I know there was (rightful) concern that it shouldn't displace creep hauling which implied energy/unit can't go too low. However as an alternative to an energy efficiency constraint we could instead mandate that the new transport system only transports things starting in an owned room. That makes it useless as a remote mining replacement regardless of its energy efficiency.

[wary surge]

If it was cheap enough, it could still get haulers out to the harvesters in near-zero time.

Thus doubling hauler effectiveness.

[vapid minnow]

yeah, depending on how you scope it - folks could decide how much of a niche should creep-based hauling maintain. Maybe return-trip only is OK? If the desired state is remote mining creeps need to walk both directions we could further add constraints that the destination room also has to be owned, or that the transit system doesn't move creeps.

[wary surge]

Oh hmm, I guess you could send a creep through a chain starting at an owned room and ending at an owned room, loading it up in the middle.

[vapid minnow]

A lot of this feels like trying to figure out what is the goal... then work backwards from there to decide what mechanic achieves the goal : )

[wary surge]

Yes

In some ways it does seem like the goal is similar to what someone else said way back in the thread: nerf terminals but give something else that's somewhat useful and fun to blunt the pain.

[distant glade]

Personally, I like the direction artch proposed, hauler: short range slow trickle owned-unowned transport, terminal: long range slow trickle owned-owned transport, gateway: any range burst transfer owned-owned or owned-unowned transport, but you need to transport huge amount to be cost-effective.

I think the biggest effect is that this buffs temple. You don't need to bootstrap the temple to RCL 6 with hauler

[wary surge]

Wouldn't you normally have a temple room right next to another claimed room?

[silver ocean]

I see so the idea is these will be good for bursts, like you have a huge amount of resources to shift. Anything less than a large transfer makes them uneconomical?

[distant glade]

if terminal is limited, then you potentially need to haul from more than 1 room to sustain high rate of upgrade.

[vapid minnow]

it wasn't clear to me artch's portal proposal distinguished owned/unowned... I may have misread : )

[distant glade]

also, a lot more cpu efficient without hauler.

[vapid minnow]

but yeah, anything that distinguishes owned/unowned seems like one way to carve out a niche for creep-based hauling

[distant glade]

I use owned/unowned as colloquial term for room that has terminal vs room that don't

[wary surge]

Yeah, the main use seems to be between terminal rooms and non-terminal rooms.

[silver ocean]

If what I said was along the right sort of lines, may I propose no structure decay, a moderate construction price but a huge cost to activate the structure for X ticks (maybe you need to feed them lots of E). That way the infrastructure remains in place and people can see where you have your busses but it will be dormant most of the time. This seems more interesting gameplay wise than rapid construction->use->decay.

This should still fullfill the requirement of only useful for burst transfering large quantities of resources

[wary surge]

It does rule out a lot of burst applications, though.

E.g. that "build a new room to RCL 6" or "get resources to a new front"

[true shuttle]

why not ghodium ?

[distant glade]

oooh

[silver ocean]

sure, just something that makes it cost a lot, specifics to be determined :p

[true shuttle]

i'd say it does not rule-out bursts - you still have i.e only 500 ticks to shove resources/creeps through, afterwards it could go on cooldown for X ticks

so
dormant (can be destroyed)
feed 5k ghodium to "entry" gateway and connect it to exit gateway
500 ticks where you can move creeps through, cannot be destroyed
"entry" gateway goes on cooldown, cannot be destroyed till it expires

[silver ocean]

wait, thats a really good point, we dont even need to make it expensive to use, just have a really long cool down between activations...

[true shuttle]

not "really long" because then you can just .destroy() rebuild

[silver ocean]

unless we dont make them too cheap to build

[wary surge]

Or use the same fix as nukers

[true shuttle]

or you make it that you cannot ".destroy()" if on cooldown

[silver ocean]

like if the structure costs 1-2M E to build you wont be popping and rebuilding

[solid elm]

That's why I suggested end room should be unowned

[distant glade]

G is about 30-40x the price of energy in shard2, so 300G activation already roughly equal to 10k energy in cost

[wary surge]

10k energy is pretty trivial though.

[vapid minnow]

Artch mentioned it in terms of short-term vs. long-term, but I'm not sure what would prevent it from long-term use as long as throughput demand justified it? For example temple rooms probably want high throughput over long time periods. If maintainance of the portal building makes it more expensive than building a new one then I assume folks would just rebuild it over and over.

[true shuttle]

most players that would be using them, wont be bothered with any activation cost if it offsets whatever they need

[wary surge]

I presume it would mostly be used for bursts of more than 500k, since terminals already allow you to burst 300k.

[silver ocean]

dont know, still think long cooldowns are better otherwise you will need to go along the chain refuelling them between activations which is very limiting

[distant glade]

you can use tiny creep to activate them, or fill them to 299G and just activate them with 1G in time of need.

[wary surge]

Though that only applies for terminal endpoints.

We already have ways to deliver large bursts of stuff shortish distances, so I imagine if this would be a burst thing that it would be used for (say) 10 rooms and beyond.

And more than 500k energy-equivalent.

[silver ocean]

Ok heres an issue, how do you stop people trolling neutral rooms by activating them when you dont want them activated?

[distant glade]

non-catastrophic, same as someone harassing your remote and destroying your containers, no?

[vapid minnow]

force the start to owned building in owned room?

[silver ocean]

well like say you are fueling them for a jump if we go that route which is suggested to be expensive in terms of either a cooldown or a resource, someone like me can go into any one room along the chain and ruin your day

[silver ocean]

oh I see you're suggesting only fuel the first and the rest dont need fueling?

[distant glade]

I think it's not that expensive to activate, it is only expensive if you want to maintain it indefinitely.

[true shuttle]

guard them, parley with players or accept that they will be trolled

[silver ocean]

I mean as others pointed out, if we follow the cheap to build and activate, just keep popping and rebuilding

[true shuttle]

not if you cannot destroy if active / on cooldown (and limit to one-per-room)

[silver ocean]

then slap a parrallel route down in another set of rooms, also the plan wasnt to limit them to 1 per room anyway so you can have different routes

[true shuttle]

ye, but then you need to do that automatically somehow

[vapid minnow]

and yeah you could say that the intermediate nodes don't need fueling. Their upkeep might be tied to costs that are fixed over time rather than per-use costs.

[true shuttle]

and that might not be possible because owned rooms/remotes

[distant glade]

yes, pretty sure that's the goal here, per tick cost is expensive but if you bank it for burst transfer it's not. Let's say we are using my numbers, 500 transfer window at 10k construction cost, would you pay 20 e/tick to maintain it indefinitely (by rebuilding)?

[true shuttle]

so going with parallel route adds complexity

[distant glade]

or you just bank 1M energy at your storage, activate the entire chain, then transfer all of them.

[vapid minnow]

cooldown seems like a fine way to enforce 'bursty use' to me : )

both bursty and non-bursty niches seem interesting to me... that just goes back to deciding which niche feels more fun/interesting

[silver ocean]

I think that's why artch clarified because before it was just a loop of people arguing for one or the other

I was firmly on the "screw the current meta, busses for remote mining an entire sector team" but unfortunately that isnt the direction that was decided XD

[distant glade]

wait, maybe my numbers is a bit off, should have been 50k construction cost probably to make it actually worse than terminal in energy efficiency.

[wary surge]

Terminal isn't comparable when going to unowned rooms

(Or less than RCL 6)

Terminals can't do that at all.

[distant glade]

yea, but still should be worse than terminal if we still want terminal to have niche in peacetime

[wary surge]

Terminals have the "non-burst" niche.

Well, they do burst, but only up to 300k.

Terminals will no longer allow burst delivery of 1M resources

(and can't send creeps at all)

[vapid minnow]

I still think as long as there is an owned-room starting constraint the new thing doesn't have to be worse than terminal on energy efficiency. Building a chain of buildings that have to be defended is a cost all on its own.

[distant glade]

sending 1M energy through terminal with 10 rooms distance cost 283.5k energy if you trickle it. If gateway is cheaper than that, then you empty your storage, burst transfer 1M energy, then not use terminal at all until your storage has run out. Not saying it's bad, but it's a possibility.

[vapid minnow]

(to be clear a complexity/defense cost, not necessarily an energy cost)

[distant glade]

but if that is the case, then terminal is sidelined as trading + lifeline during war.

[vapid minnow]

yeah, its another goals question.. is it interesting meta to allow a more complex and defended setup that has better efficiency than current terminal

[silver ocean]

I'll just summarise what I was proposing as I know it is in disconnected messages and other people have inspired me since for prosperity:

• Moderate construction cost (1-2M as discussed previously)
• No activation cost, but long cooldown between activations.
• Activation can only occur in owned room (preventing mid chain trolling). After first jump from owned room creep gets a hidden value which is the ID of the first station in the chain. At each neutral room you jump to - check for creep flag, if exists, is that structure still active? If yes - push creep to next stop in chain.
• When the structure goes on cool down delete flag from creeps.
  Then people cant jump on your bus halfway through, its good for bursts nothing else, the infrastructure is more permanent so people can see where it is etc and take action, there is no issue at all with destroy + rebuild.

[vapid minnow]

I'm assuming the new thing has one building per room requirement so during war that can be cut off

[wary surge]

Does the creep become unable to use withdraw or accept transfer?

(while in a transit hop)

[distant glade]

can be interesting for sure, depending on if the devs wants to go that route or not.

[distant glade]

yea I mean terminal still superior during war.

because it can't be cutoff, even if it trickles.

[true shuttle]

i'd still keep separate activation for whole chain - so players have to either cooperate or ensure the gateway is secured

[vapid minnow]

only creep carrying or also allows resource carrying independent of creeps? (both seem interesting to me, but different)

[true shuttle]

the whole "fun" is to have to maintain and "control" whole chain

[wary surge]

If the creeps can only go one-way from an owned room, that removes a lot of the applications.

And frankly this was already a small niche

[true shuttle]

if someone starts "trolling" that's a good reason to wipe them. same as when someone "trolls" your remotes

also it allows for attacker to cut-off the room (as intended by artch)

[vapid minnow]

IMO the owned-room start is a nice restriction that still feels useful (launching assaults, supporting new colony, temple/mineral resource transport if resource transport is supported)

[wary surge]

I don't consider 1M per room in a chain of 10+ unowned rooms to be "moderate" construction cost.

[vapid minnow]

yeah, I guess its just a question how easy should it be cut. Access for 1 tick by a 1M creep, or something a little more intentional like a dismantler.

[wary surge]

It's probably "moderate" for a single base station in an owned room, but that's a ton of expense to be just sitting out there in unowned rooms.

No ramparts, no towers to protect it.

[distant glade]

Summary of my proposal:

• short transfer window (500 ticks)
• construction cost low but not viable to maintain indefinitely (20k-50k energy depending how good it should be vs terminal)
• construction cost or activation cost is roughly equivalent, so either can be used.

Side effect I predicted:

• bootstrapping to RCL 6 for temple is easier, as you can supply it with 1 or 2 waves.
• Sieging a room need to control surrounding area as well, to prevent resupplying gateway from being built. Failure to do so means the room you are attacking get fresh extra 1M energy.
• Terminal is still unbeatable for daily use, as the complexity and cost to build supply line every 1M transfer is still not worth it compared to just waiting the transfer trickle.
• Power projection is easier but not unlimited. Within 500 ticks, you can send only 1 wave of quads (though theoretically you can bank quad first before activating line) from backline room, then you need to rebuild the supply line to do it again.
• Gateway will be 99.9% completed most of the time, and small 1W creep is going to be used to activate it when in need.

[wary surge]

I think that's a lot closer to what artch was proposing, yes

The timescale to build it will still be longer than the transfer window though

[distant glade]

yea, but since the transfer is so bursty, the transfer/tick is still high, no?

[wary surge]

I guess you would need to mostly-build them, then put in the last energy in quick succession.

[distant glade]

yea, I think that's going to be the way to use it.

[wary surge]

Like, if going 8 rooms then you'd need 7 builders on standby at the end.

[distant glade]

yea, but having 7 small builder on standby is cheap

if you do the math right, it can be 1W 1C 1M

[wary surge]

Err, 9. But yeah. Just complex 🙂

[distant glade]

my concern is power projection actually, you can bring fresh quads 20 room over if you are willing to spend let's say 400k energy for the burst transfer.

[wary surge]

Lots more setup time than use time.

And fairly trivially disruiptable

[distant glade]

but not so catastrophic if it does get disrupted.

[wary surge]

Not catastrophic, just means you lose 50k energy per disrupted site

(or 20k)

[distant glade]

yea, about the same having your remote containers get destroyed.

[wary surge]

Uhh, what do you build your containers from, ghodium?

[distant glade]

for 2 room source it's 10k energy to build

[wary surge]

At least with those you need to deal 250k hits to each one and only lose 5k each.

[distant glade]

not as expensive but roughly in the same ballpark

[wary surge]

With these you can pre-activate them before the rest are set up and the whole thing becomes useless and needs to be built again.

[distant glade]

if enemy manage to pre-activate 1, you just lost 20k, unless they manage to pre-activate every gateway in the chain

[wary surge]

Yes, I was assuming they can do it to all of them, since there's not much stopping it

[distant glade]

I think if you are facing hostiles destroying your supply route, you might have to resort to hard-build the gateway and guard it with troops.

so banking it is not that easy in hostile situation.

[wary surge]

Yeah, so I think it's not that great for power projection.

It's more useful than not having the option, just not decisive.

[amber adder]

I really like this idea. the role of different logistics methods is very clear.

[wary surge]

Definitely more a peacetime thing.

[distant glade]

yes, makes combat more active as well, you can destroy supply chain easily before enemy has a gateway chain to you, but you do need to wrestle area control from them.

[wary surge]

It would probably be more useful in war if cheaper to build and required something more compact and valuable (like sigh ghodium, trite though that is) to activate.

DUnno. Maybe 500 ticks is too short.

[distant glade]

I think not making it too easy to build during conflict is ok, after all, forcing players to have active deterrent to protect your supply line in a war is ok.

[wary surge]

Yeah, could be. It's more the all-or-nothing aspect that feels off.

[distant glade]

I was thinking if you can abuse the entire lifetime of the gateway by lining up 40C 10M creep per tick, you end up with 1M resource, already fills up unboosted storage.

[wary surge]

I mean, an alternative would be that it supports N parts transported.

Instead of being open N ticks

[distant glade]

the problem is that if like that, it will be abused for remote mining hauler.

it's to make per tick cost goes through the roof instead of on-demand cost.

[wary surge]

Ah yeah, I can see that.

[silver ocean]

If the goal is long range logistics in burts and that can be broken by a 1M creep using 1 intent somewhere along the line, that would just be bad design imo

[true shuttle]

you'd need to activate the gateway, so 1M creep should not be able to do that

[silver ocean]

Like destroy the structure fine, thats valid but damn... not that XD

[distant glade]

well, that comes with the fact it's unowned structure IMO, at least you have option to hard-build it if you are willing to spend resource to guard it.

It's like pirate vs merchant thing

[true shuttle]

also, a single-move creep can break remote mining easily, by standing on just-right road

[silver ocean]

But like remotes are usually just a few rooms over from a base, this is designed for opperating at much longer range right?

[true shuttle]

i'd say that trying to use it over 8 rooms would be pushing it

[distant glade]

You could just block it with 8 1M creep of your own, no? then they will use 1M 1A to counter that, which you use something else to counter that too, etc, and so the arms race begins.

[true shuttle]

because that's like 5 rooms out of usual influence range

[minor reef]

Decay could be different for activated and non-activated structures. You build it, wait until the whole chain is complete as long as needed (decay is slow), and then activate each station (high decay starts).

As for using resources for activation, that feels like extra complexity. Do we actually need that, or would a high maintenance cost be enough on its own?

[silver ocean]

I personally advocated no cost by longer cd. Are you happy with the chain trolling thing btw?

[distant glade]

yea, hostiles can still destroy it by activating it prematurely.

but I don't think it's a flaw

[true shuttle]

i'd say that activation should be requiring something so there's limit how "trolling" can happen
could be either some resource requirement, or i.e CLAIM bodypart

[distant glade]

500G to activate is ok to me honestly

[minor reef]

Maybe we can implement it similar to nukes then, with no-withdraw internal store for G only

[true shuttle]

could burn G also as ukeep

[distant glade]

I agree, this seems to be solid design so far.

but I think you can only activate it once it's 500G, and you can't turn it off until it's empty.

[true shuttle]

and for the example chain-case
fbr player wants to attack other player
so they build/use 8 gates and then activate them

[minor reef]

Activation consumes all G in store and activates it for some period. Then it becomes inactive again, you have to recharge and reactivate

[distant glade]

valid implementation I think

[night bronze]

My problem with creeps hauling is: It is one or more intent every tick.

[true shuttle]

yes but you save a lot intents by not having to walk

and for the "defender" case
2 rooms building/using existing gateways to ship creeps/resources to attacked room

attacker still can "cut-off" gateway on highway i.e, and defender can do the same in above-image

[amber adder]

requiring a little (like 200) G to activate it avoids the hostile 1Move issue.

build - low decay - activate(permanently) - high decay
sounds good imo

[minor reef]

Do we need high decay in this scenario, with G activation cost?

It depends on whether activation is permanent or temporary

[amber adder]

if the activation is temporary, I prefer no decay

keeping only one type of cost reduces unnecessary complexity

[distant glade]

agree, 500G for 500 tick activation is functionally already equivalent to decay

even 0 decay is fine IMO.

[minor reef]

Actually, there’s another way to implement this: we could remove the activate() method entirely (since it’s an unowned structure and there’s no precedent for calling methods on those) and just set the direction and channel like this:
createConstructionSite(15, 25, STRUCTURE_PORTAL, {direction: TOP, channel: 42}). Essentially, we'd repurpose the parameter that's currently only used for spawn names. Once it's built, there is no way to change it. Activation would then happen automatically as soon as enough G is loaded.

[distant glade]

it does complicate createConstuctionSite api though, as it now need to support options parameter.

although the alternatives aren't much better either.

[minor reef]

there is already name parameter, it will just become data with two different purposes

[distant glade]

though technically, reserveController is a precedent of an action to unowned structure, but you can argue it was special case and the api is simple,

[minor reef]

reserveController is an action of a creep

actions to unowned structure are fine, actions of unowned structures are unprecented yet

[distant glade]

unless you implement it as creep.activatePortal(channel, direction)

[minor reef]

sounds too much for this niche

[true shuttle]

hum, i'd say gateway should be as "generic" as possible, so no predefined direction / channel

[minor reef]

One more detail: when the G is loaded, what technically happens might not be an "activation" per se. Instead, a regular Portal with a specific TTL is created at that tile, linking to the adjacent room's tile where a StructurePortal with the same channel exists (even if that one isn't activated yet, since the channel number was already assigned during construction). There wouldn't be a Portal at the destination point until there’s enough G on that side too.

That raises a question: should the Portal vanish immediately if the StructurePortal is destroyed? Or should it just expire naturally once its TTL runs out?

[true shuttle]

vanish immediately i'd say, as in "no structure to maintain connection exists anymore"

[distant glade]

wait, then you have 2 portal in 1 tile? exit portal and entrance portal?

[true shuttle]

every portal is 2-way

[distant glade]

I never use portal, but does it have precedence?

different exit-from and entrance-to portal I mean

[minor reef]

wait, we already have StructurePortal, not Portal

[minor reef]

no, why?

[minor reef]

technically it's not mandatory

and inter-shard portal are not 2-way

[true shuttle]

but it makes sense here :p

[distant glade]

ok, so portal doesn't have to be bidirectional.

[true shuttle]

that you can go both entry->exit and exit->entry

though it depends on implementation

there'd be two options imo

1. you activate 1 gateway via .activate(otherGatewayId-or-name) and you get one-way transport to otherGateway
2. you activate 2 gateways and you get bidirectional transport

[distant glade]

2 way transport is just standard portal, no? I mean can you do A->B, B->C?

or do you need to do this? A<->B1, B2<->C

[true shuttle]

no you'd need [ A ]->[ A' B ] ->[ B' ] with each being a different gateway

[distant glade]

then you need move part to step from portal B1 to B2?

or A' to B in your example

[true shuttle]

yes

that's how portals work now

if you stay on A' you'll bounce back to A (usually)

[wary surge]

So if the destinations weren't reciprocal, you'd move to C instead.

Being on a portal at end-of-tick moves you to the destination, wherever that is.

Current portals happen to be created with reciprocal destinations.

But the code don't care.

[distant glade]

it's functionally similar balance-wise, but if you can do A->B->C, you don't need to spend any move intent during portal travels.

[true shuttle]

(except on shard0 edges)

[silver ocean]

I like this, just load the resources and it comes online impossible to troll that way, much better than the cooldown idea

Also like the set params on construction site placement more elegant than after finish

[distant glade]

well, we are already talking about implementation details. I think the fundamental design is solid already, I don't particularly care how the exact implementation going to be.

[silver ocean]

Only concern is big alliances have basically infinite resource are you ok with this potentially being a big tool for force projection (even if the cost per activation is high)?

No strong feelings either way personally just thought id point it out

I guess creep ttl penalty discussed previously impacts that though

[distant glade]

I assume in that case, might be a good idea to turtle and just ride out the wave? after all, they are spending upward of 50k+ G to send you 1500 ticks of total war.

[wary surge]

If there's the same creep TTL penalty then it pretty quickly fails to be useful for large bursts.

The burst delivery idea was predicated on being able to reuse the same creeps many times.

If you can't do that then you will run out of haulers long before you run out of activation time.

Unless you put unghodly amounts of stuff in to keep it open while you slowly spawn more haulers.

[amber adder]

TTL penalty is a major concern. is it possible to surpass the current range of force projection? whether the 600TTL limit of CLAIM part still holds?

[distant glade]

i think if power projection concern is really pressing, maybe consider if capping ttl to 600 once a creep entered a portal is a good idea

[minor reef]

Any idea how to balance a TTL cost and G cost?

[true shuttle]

i'd tie it directly to G, so put anywhere between 1-500G get equivalent of gateway TTL
500 ties nicely for 10CARRY, and for spawn-boost-transport 3 sets of 3 max-sized spawned creeps
if you'd need a shorter burst player can put less

[minor reef]

I mean, creep TTL cost

[true shuttle]

hum, i'd say that impacting creep TTL would not work well, but could be like ceil(creep.ttl * 0.005) which maxes at ~8 and diminishes the older creep is

would make long chains less punishing on top of the maintenance and godhium cost

(could also switch that inactive gateway can still be used but at significant TTL impact (like 1-2%))

[distant glade]

what is the design requirement of the ttl cost? to reduce power projection?

[minor reef]

yes

[distant glade]

a bit hard, because the burst transfer cost only make sense if you can line up cargo creep so the chain has 1 creep per tick throughput

otherwise you can't reuse the cargo creep too much, meaning you will still be limited by spawn speed eventually

[true shuttle]

wouldn't it be better to calculate the G cost then, to be greater than what a single room can "cook" in 9 labs over the activation time ? [lazy to do the math]

[distant glade]

you can still buy G from market though

[true shuttle]

there's limit though how much market can provide

[amber adder]

I'd like 25ttl per jump, which means u can double the power projection range if u put the investment of construction.

[true shuttle]

1st two jumps are within your domain most of the time (through your remotes)

so you save 25TTL per room

[distant glade]

maybe something like 100 ttl per jump, but no cost if below 300 ttl, it's still feasible to do burst transfer, but combat creep using portal is going to arrive very weak at destination

[zinc quest]

100 is so dang expensive unless we are talking multi-room ranges.

[true shuttle]

100 ttl is literally worse than just having the creep to walk same distance. so that would make it unusable except very few, life-and-death situations

[amber adder]

100 is too bad since u need construction and G for portal

[zinc quest]

Though I do like a floor for ttl impact though if we keep a ttl impact.

[distant glade]

if it's for burst transfer i would assume you are having that creep expressly only for transfer purpose, not general hauler you conscript into becoming narco sub.

[true shuttle]

it would depend how much "range" is supposed to be main use-case,
because with clamped high-TTL impact (i.e 100TTL per jump if creep is above 1100) would promote longer transfers
while smaller TTL would increase "short-range" use

[distant glade]

or maybe 500 ttl floor, it's already make it weak for combat transport

or just straight up cap ttl immediately to 500 or 600 upon stepping on the portal

[true shuttle]

makes no difference for long-vs-short gateway then, also makes it unusable for anything but emergency hauling

[distant glade]

yes i guess, but at least for short range you pay less G

[true shuttle]

scaling with remaining creep TTL could be good, with i.e 3% so after 10 jumps creep is around ~1170TTL

more jumps you do "bigger" relative gain

3% seems to be good spot of being 'slightly' better on short distance

[silver ocean]

Im more inclined to agree with you dont want it to be too bad and you should gain some kind of projection - otherwise what is actually the point of these structures. Like if the TTL is such that it adds no or very little projection, all this infrastructure does is allow you to move cargo creeps a lot faster - at a very high cost. Apart from extreme emergency hauling I can't see any use for them if the TTL penalty is too high

[distant glade]

if we use 3% cost every jump, then it's better for troops transport than for cargo. a single cargo creep need to jump back and forth between end-to-end. so they can survive like maybe 100 jumps

[true shuttle]

with ceil

[wary surge]

Even emergency hauling is not really any good for high TTL cost since haulers will die very fast.

[distant glade]

unless the cost is floor(ttl * 3%), not ceil

[wary surge]

Yeah, even 3% is far too high for burst transport.

Doesn't matter much whether it's floor or ceil, 3% still kills the idea of burst transport stone dead.

Pretty much any TTL cost kills that idea.

[true shuttle]

hum, why, you shave ~5-10 ticks per room

[silver ocean]

I guess the idea is you just desperately want to get resources somewhere and dont care if the creep will die a few ticks after arrival in that situation but yeh, I think Droid raised a similar comment before about it just being creep hauling but faster but more expensive resource wise

[true shuttle]

so transport instead of taking ~500 ticks over 10 rooms, takes ~20-30 (let's be generous) and creep instead of losing 500TTL less, loses ~380TTL

[wary surge]

I mean, it works if there is literally no other way to get stuff there, but we know you can get stuff there since you had to transport stuff to activate all the portals.

[distant glade]

the G cost doesn't make sense unless you can reuse the sent creep back to pickup the next load of energy over and over though

[wary surge]

Right

[true shuttle]

why reuse creep though ?
send hauler and recycle it in target room

[wary surge]

The idea mentioned was sending 2M or so energy to a new room.

If the creeps are one-shot then you have to spawn 1000+ haulers.

That takes a long time.

[distant glade]

because even if you use 3 spawn, you can only send like 30 creep over working full time, if the creep is one-way trip only

[wary surge]

So it stops being burst and reverts to being trickle.

[silver ocean]

that doesn't seem too unreasonable and may be worth the cost, no sure though.

[true shuttle]

given that Storage has 1M limit, and mining 2nd million of energy in 500ticks is rather unfeasible, i dont think that's a real case

[wary surge]

You can send from more than one room.

Or use storage expansion

So yes, it's a real case.

More to the point, it was one of the motivating cases that artch mentioned as being made possible by this tech.

[true shuttle]

so, what's the issue of multiple rooms, spawning 49Carry haulers that send 2.5k energy + 1.6k each (carry + recycle) ?

[wary surge]

So if we set parameters that make it useless for the motivating case, what are we even doing?

[distant glade]

you need 500 creep if it's all going to be sacrificed

to maximize throughput

[silver ocean]

I dont quite follow how the suggested parameters make it useless sorry

[true shuttle]

also the "older creep is, the less TTL impact it'll have"

[wary surge]

Spawning 25000 parts takes way too long to be even jokingly called a "burst"

[true shuttle]

at 3% per gateway-jump, you look at roughly 120 "jumps"

[distant glade]

still 1 creep is only viable for like 125 jump if the cost is floor(ttl * 3%), meaning you still ned 4x more creep to saturate the transport line

[wary surge]

Yep, which is abotu 6 round trips

[silver ocean]

Why is that a good thing, sorry I think I missed some reason behind it

[wary surge]

(Assuming a reasonable distance of 10 rooms)

[true shuttle]

because if it's a "flat" cost, it's either low-enough because it's useless to be in the 1st place, or high-enough that it makes the whole concept useless

[true shuttle]

in 500 ticks you can spawn 9 49CARRY haulers, that can then bounce-between the rooms

or you can pre-spawn them

or you know, boost them even

which nets you 10k/trip/creep

so 60k over 10 rooms

[distant glade]

if 1 creep only survive 125 jump, with 10 room distance (so 20 jump round trip) you need 80 creep to saturate it for the full duration of 500 ticks.

[silver ocean]

I see so the idea is, say if someone is jumping war creeps to the front, they will not have too much time to live by the end so are less impactful but you can still cover the distance with haulers if you want to? Clever

[true shuttle]

so the supper-happy-path scenario for hauling is

• prespawn and renew 9 haulers
• boost carry
• move 9 haulers across 10 rooms
• deposit 9 * 10k of energy
• return them back 10 rooms
• repeat trip 5 more times

and you have 450k energy hauled over 10 rooms

and during the prespawned haulers haul, you can spawn another 9 haulers

[distant glade]

wait, you have a point, with renewCreep, you can technically replenish the almost dead hauler but still low enough that the cost for round trip is survivable.

[silver ocean]

unless you use boosts though

[wary surge]

Well, you can't renew boosted ones, and it takes nearly as much spawn time to renew as to spawn.

[silver ocean]

as you will loose them

[wary surge]

But you do get some gain.

[silver ocean]

@wary surge what is it you advocate for for the TTL stuff? I'm assuming you don't like the % thing. I personally think its a really neat idea so I'm curious as to what alternative you think is better.

[wary surge]

If you renew only when they're very low and have 3% per hop you could get reasonable re-used out of them.

So maybe that does actually work.

They come back with about 1/2 TTL - 20, which is pretty quick to renew if you started with 50.

[distant glade]

yeah, I think so, but the numbers do need to be balanced so this is still possible

or you can skirt the limit even more by renewing on both side.

[silver ocean]

sure, perhaps not 3% maybe 1 maybe 10 but the principle of a % decay is the best option I've seen so far

[true shuttle]

yes-and-no, every 10th jump you add 12TTL, and below ~120TTL you get more from renew then from TTL decay from 10 jumps

[wary surge]

Yeah, I realized later that if you let them drop very very low then you can manage it.

So yeah, it's not as bad as it looked.

[true shuttle]

so for "peak performance" you'd need good code, but also that'd be the point

at ~100TTL the cost of 10 jumps is virtually 0 (because it's offset by 12ttl renew)

[distant glade]

I think floor is better than ceil, because you still lost 1 TTL normally anyway, so the formula still end up being ceil once that is considered.

[true shuttle]

so you look at "in theory" infinite hauler (when not boosted)

[silver ocean]

I feel like there should be a ceil lower bound to the % thing right? Otherwise it could get a bit silly idk

like max(3%,20) or something

(not those numbers though they are just an example)

[true shuttle]

difference is quite insignificant, wether over short or long gateway chains

[silver ocean]

if this is the idea #1450220297063104703 message then dont you want it to be significantly different at different TTLs?

[distant glade]

agree, you need 1 spawn doing renewCreep on both end for 12 room distance to sustain it indefinitely, 2 spawn on both end for 24 room distance transfer. 3 spawn for 36 room distance. This do make transfer longer than 36 room distance impossible though, so it's still a nerf in theory, just not necessarily that limiting.

[true shuttle]

so whether it's .ceil(creep.ticksToLive * 0.03) or .floor(creep.ticksToLive * 0.03) makes no diff "in big picture"

[distant glade]

no, ceil is double cost than floor for the purpose of this inifinte hauler.

[silver ocean]

oh I mistyped, I meant a lower bound my bad, like 3% but at least 20 decay for example (numbers for example, not advocating these specifically)

to prevent near inf distance travelling haulers

[distant glade]

correction: longer than 36 room distance transfer is still possible, but you need to use creep with less than 50 bodypart.

[true shuttle]

assuming gateway lasts 500 ticks, you look at 50 round-trips at room-distance being 10 (perfect situation)

[distant glade]

25 round trip actually, but still 500 jumps in total.

or you meant 50 one-way trip?

[true shuttle]

25 round-trips, my bad

[distant glade]

still, let's say if we use ceil, then even at the lowest ttl, the creep still lost 2 ttl per tick, 1 from jumping, 1 from its natural ttl loss. meaning round trip already cost at least 40 ttl. Compare to floor, which result in 20 ttl loss. Still servicable with just 1 spawn on both end.

[true shuttle]

looking at excel now, there's hardly difference between floor & ceil, you still get "infinite" hauler, just less TTL on it

[silver ocean]

hence the need for a minimum loss :p

[true shuttle]

also i dont think infinite hauler would be desired result 🙈

[distant glade]

I think infinite hauler is the goal here, you and I have different idea I think.

[silver ocean]

hmm, I guess you are right @distant glade we did just assume it was a bad thing

[distant glade]

after all, the cost of the gateway chain is the G needed to activate it, the creep cost was collateral damage from limiting power projection.

[true shuttle]

it 'd need the min cost of one so Math.max(1, floor(creep.ticksToLive * 0.03)) or at low enough TTL gateway jump is free

[silver ocean]

Ok on the force projection front though... For the big alliances spawn times are a limiting factor (based on conversation with sneaky), so this could help bypass that if spawned creeps are moved to allied bases to be renewed and boosted, allowing more spawns to partake on a particular front. <- incorrect ignore

[distant glade]

renewCreep still fundamentally take the same spawn time to just hard-spawning it.

[silver ocean]

Ah true fair, ignore me sorry

[true shuttle]

yes-and-no, because you split that time against 2 rooms

and you dont block spawn for 150 ticks

[distant glade]

still not infinite power projection. Though stronger than just walking.

for 500 ticks, at the cost of I don't know, maybe 100k+ G for activating entire network?

[true shuttle]

so ye, Math.max(1, floor(creep.ticksToLive * 0.03)) for creeps TTL impact, might be sweet spot

[distant glade]

I actually proposed floor(creep.ttl * 3%)

at very low ttl, no cost for jumping, just the natural 1 tick decay of normal creep.

[silver ocean]

Ok on a serious note, would anyone actually use these structures as they are currently being planned, with the G cost, 3% lifetime cost + construction and maintenance?

like terminals are still an option even if they are nerfed

[distant glade]

I think mainly for temple? and maybe resupplying frontline room that is spawning quad 24/7

[true shuttle]

hauler get's you 2.5k-10k/e roundtrip, so 125e-500e/t if 10 rooms distance, so good if you're in a pickle

can allow sending a claimier FAR

can allow sending attacking creeps FAR also

it's not prohibite on any use so i'd say players would find the way to use it

[silver ocean]

ok so if you control the intermediary rooms and have a situation where a room demands a vast qunatity of resources such that the terminal isnt enough - which I guess is what this was designed for. I wont like though, before this direction was decided I was kind of looking forward to trains busses for remote mining infrastructure.

[true shuttle]

me the same - but seems that's not intended use-case

[silver ocean]

oh well! Maybe when I get to the super late game I could maybe use this XD

[distant glade]

let's assume average bodypart of a quad averaged over all 4 members is 10T 15R 15H 10M, costs 7600 energy and 1500 compound boost total per spawning. If your spawn is working 24/7 you are using on average 9100/50 resource per tick, meaning 182 resource per tick. If terminal is going to be limited to just 50 resource per tick, you can stretch it to 95/tick with battery. Still not enough, so you need external supply route.

[silver ocean]

I mean if all you need are two terminals worth, just claim an adjacent room purely to have a terminal you can send to right?

a lot cheaper than ghodium fueled mass transit I reckon XD

[distant glade]

or you could spend 2M energy to build second terminal next room over. However, activating train network (assuming from 10 room distance), costs you 10k G, which is roughly equivalent to 400k energy in credit cost if using shard2 price

[silver ocean]

Im assuming if its constantly farting out quads though you would want to do this continuously

so the investment would pay off in the long run

[distant glade]

sorry, some miscalculation

terminal have 50/tick limit is only becoming 95/tick if they have factory

so in fact, you need 2 slave terminals to cover your resource usage

or you upgrade 1 terminal room to RCL 7, which is even more expensive.

you need 10x network activation before new terminal is competitive.

[silver ocean]

which actually... doesn't seem like that many...

like especially for a conflict lasting months

[distant glade]

I guess we can stretch the number a bit more if we consider that terminal also still have tax

at 10 room distance, terminal tax is 283.5k for 1M transfer

so, when calculating the tax difference instead of endowing the full cost of network activation to the portals, we end up with 34x activation

[silver ocean]

you mean the amount of E you have to pay?

[distant glade]

yea

for network, I converted the G cost to energy cost using current shard2 market price.

about 40x

so, roughly I think, if your conflict lasts for more than 7 days of pumping quads 24/7, then yes, new terminal is better.

that's about the cutoff I think

[silver ocean]

You also need to account for build/maintence of the nodes/portals/whatever we are calling them now

[distant glade]

I think this assuming no decay, just activation cost

[silver ocean]

not sure if we picked a number for that yet

[distant glade]

I wish it has no decay, having decay and activation cost at the same time is unwieldy.

[silver ocean]

ok but what about construction cost?

[distant glade]

I don't know, not sure what artch is going with for the construction cost, but I wish it's a lot less than 2M for 10 room network.

[silver ocean]

Can we agree though for temple rooms, this structure in its current form will not be useful and you should instead build slave terminals in adjacent rooms?

[distant glade]

depend on how crazy your temple is I think

at the very least, it can jumpstart your temple directly to RCL 6 with 1-2 waves of transport

[silver ocean]

fair. Anyway I got to go to sleep now, these structures are still somewhat interesting but they will probably be for late game players. The % TTL was a pretty awesome breakthrough for balance. Its a shame that the remote mining status quo won out in the end, it could have been really cool with different bus routes for different remote sets and stuff in highways etc etc. Oh well, gn! 🙂

[distant glade]

You know what, I think it's also possible that instead of G for activating, we use battery instead, keeps the cost ratio to terminal stable instead of relying on market price. Which I suspect will be more volatile if G has more widespread use.

[true shuttle]

G cost could be also nullified if you can spare lab time and mine minerals

[distant glade]

yea, but no difference if you buy G or use it from your own production, because you can sell the produced G instead. In the end, you still lost some credits, just as opportunity cost, not direct payout.

[true shuttle]

most ppl dont produce lab compounds for sell

[distant glade]

in theory I mean.

though selling G is a bit less than buying G I think,

[undone whale]

This proposal seems reasonable to me. Although, I do think that it makes the "bus" name less apt and that the name change to "gateway" would fit better. Since "bus" sounds too routine for something that's intended to be short-term only.

[undone whale]

I think that power projection is the main purpose of these and should not be nerfed.

I'm fully caught up now I think. I like the idea of it being configured in the cSite and powered temporarily with G rather than decaying. Regarding TTL cost, I would generally oppose that mechanic, but if it was low enough, it wouldn't totally cripple their utility.

Being cheap to build and expensive to run as a flat cost with minimal or no per-teleport costs fits with my general philosophy for what they should be. It would mean that for high-throughput connections or for high-importance applications (like war) they would be viable.

One thing I thought of, though.

If I understand correctly, the current proposal is that each link between two rooms would become active when just the source gateway is powered with G, because that would create the one-way portal.

This would be very good for the speed of activating a gateway route (the creep dropping off G can insert it, teleport, and then immediately insert it in the next one). If it required both ends to be powered before the portal appeared, then it would be activated at walking speed only. However, implementing it this way would probably make it so that the optimal strategy is to place gateways at room edges and only power every other one, like in this image: #1450220297063104703 message

Both of those potential "downsides" are relatively minor, though and either could be deemed acceptable. Maybe the limitation of only activating at walking speed would be considered a good thing, even. Or maybe the edge jumping workaround would be considered fine.

Or, if you prefer to avoid both slow activation and that workaround, there would be ways around it. Maybe creeps which step off of a gateway are "stunned" by high fatigue for a while (which would also make it less viable to teleport directly on top of enemies), or maybe gateways couldn't be build as close to exits as normal structures can.

That "stun" of high fatigue would would act as a sort of "summoning sickness" mechanic which is common in games. It makes it so that there is more time to react to an enemy that suddenly appears before it becomes an active threat.

[sweet cove]

I'm starting to think these are going to be too complicated to actually bother with.

[undone whale]

I think that with the current proposal we are close to a version of them which would be viable (in niche situations) and not to complicated to handle. Basically where we are at now is -

(Official proposal)
Set direction and channel in the cSite (so, no activation later)
Cheap construction cost
No decay
Insert G to power them until G runs out (consumed at 1 per tick)

(What I would add)
No TTL cost
Maybe fatigue upon stepping off of a gateway

That seems very reasonable to me.

The TTL cost (if we have one) and/or fatigue would both be fairly simple to handle in code because those are mechanics we already have. And eliminating decay in favor of G cost would make paying for it much simpler to implement. I was sort of dreading the complexity of reparing a bus line in the earlier proposals.

The only thing that would maybe be complex to implement about my proposal would be if you want to move a large volume of creeps off of the exit (faster than the fatigue would recover) you would need some pulling code. It would not be too difficult, though. You could make a 50m orb (or multiple) and have it donate fatigue to the stunned creeps by having them "pull" it until they can move again.

[sweet cove]

Let's just.. not with the stunning

[undone whale]

Fair enough.

I think I would be fine with either of those other situations (activating at walking speed or the meta being edge gateways).

[sweet cove]

I'm not worried about enemies popping into remotes. It's when they pop into owned rooms it could be a problem, but if they land on a predictable exit tile, alright, at least that I can rampart, box off, surround with towers, whatever.

I don't want to entirely break the idea of sending a quad or train through one of these things.

[undone whale]

There are 8 tiles around the exit (if it's built in an open area), so 2 quads could exit before they had to wait for the stun anyways. Plus, if they work the way that portals usually work, all creeps that come along after that would pile up on the exit tile. So they would just need to wait before they can get out.

To me, it doesn't seem like a crazy idea, but I also don't think it's necessary, it's just something I proposed as an option. If we consider the goal of not making gateway attacks too surprising to be important, then making the exit portal need power would achieve that goal anyways since you would be able to see the ghodium-carrying creep walk up to it before enemies pop out.

[true shuttle]

they cannot land into owned room assuming you dont have gateway in room or dont allow them to build/use "entry" gateway in nrighbouring room

[distant glade]

activating at walking speed can be circumvented by just having a creep carrying G ready for each gateway. I think needing both end activated for the portal to exist is better for ease of use rather than having to code edge walker to get the optimality of this mechanic

besides, for transfer purpose, I think you are supposed to have 2 portal station per room for forward and backward direction, so 1 creep can activate both as well.

[undone whale]

Yeah, I think that (having both sides need power) is probably the better option. Walking speed would still apply if you have a pre-built gateway route that you want to activate in response to an emergency (like, for bringing in defense creeps), but simultaneous activation could save some G.

[distant glade]

yea, it's not instant on-demand activation, but you do need to bank up hauler first anyway before activating them to get the max rate from this mechanic

or for defense purpose, you need to at least spawn the defender first

[undone whale]

Yeah, if you have regular haulers spawned already you could have them start walking to activate it while the defenders spawn.

[silver ocean]

I swear you were pointing out the issue of allowing large players to easily project force over large distances meaning they control a huge proportion of a shard @undone whale but that might have been someone else. Either way the % TTL penalty is a simple way to nerf that (but not completely disable it) whilst still allowing long range logistics

[distant glade]

alternatively if you do need instant response time, you can just always standby a guard creep ready to dump G on every portal, you do need to handle the shift transition so old guard can always transfer the G to his replacement.

Technically, the guard can be a tiny 1M 1C as well if you pre-fill the G to 450

[silver ocean]

Why not just have a creep that jumps carrying the resource to fuel each gate in a chain?

[distant glade]

because to activate the next gate you need to walk to it from previous gate, costing your precious 500 tick window

[silver ocean]

You jump from one to the other right? Or am i missing something?

[distant glade]

this is assuming you need both end activated for the portal to work, so if you have A->B->C but you only have A and B active, then you need to walk over from B to C to activate C as well.

[silver ocean]

Thats a bad way of doing it, much better to have activate-> jump on one

[distant glade]

then you can pay half cost if you can code edge jumper

[undone whale]

My concern was not the ability for players to project force across a large area, but the benefit which large players would gain from controlling a large area if busses were OP for remotes. Large players will generally grow to claim as much territory as they can economically exploit. So if they can exploit much more territory, they would grow more.

I don't like the TTL penalty because it directly punishes the utility of the mechanic. I think that the mechanic should be highly useful, if the cost and complexity is paid.

[silver ocean]

Then its better to balance accounting for that rather than needing a more complex awkward walk

[silver ocean]

Understood thanks for clarifying

[distant glade]

Edge jumper is like this

[true shuttle]

but remotes are not a use case for the the bus system

at least not with the design that was discussed about 10hours ago

[silver ocean]

He knows he was clarifying why its ok to project force but not exploit

[distant glade]

can go that route, depending on the design goal, I'm more on the ease of use once it was activated, but whether to dump the complexity in using it or activating it is not something I have particular preference on.

[silver ocean]

Generally things should be simpler where possible, both in terms of mechanics and use. Having to walk the distance and activate both ends is much more complex than a jumping creep feeding structures hence why i prefer that even if it means to balance the cost is increased

[true shuttle]

mechanic complexity should be not-high, naive-usage should be simple (code wise) so everyon can hack it working in short time, advanced/efficient usage should be complex and provide significant benefit

and i'd say that's the current state

[silver ocean]

To be clear does the 'current state' involve fueling one gate and then it jumps you or the alternative?

[distant glade]

one thing to note, using edge jumper actually necessitate 2x the amount of creep to fully saturate the transport line, because you slow down significantly for the edge walking compared to just stay where you are and get teleported in 1 tick.

The coding complexity is comparable-ish I felt like, but I felt like orchestrating activation sequence is a bit harder for race condition complexity.

Because let's imagine you have 6 portal jump, so you are lining up 6 creep to activate G on each portal. The problem is, for the 6th creep, you can't just tell it to creep.moveTo to form the conga line, because by the time you pathfind, the 4th and 5th portal is not yet active

[silver ocean]

Which in turn leads to coding complexity right?

[distant glade]

but if you do simultaneous activation, you just line up 6 creep, have all of them moveTo to each site, then wait until you bank up your payload before give them go ahead signal to dump G to the portal.

[modest grove]

It certainly was not originally...

[inner eagle]

definitely wasn't, yeah

that came from the "freight train" proposal which was only about moving resources at higher throughput, where we pondered the possibility of allowing creep transfers as well, and even then, only between terminals

[undone whale]

True. But with the latest pinned proposal, it seems to have settled firmly into that niche (with short bursts of high-throughput logistics being a possible use as well but not the main use)

[modest grove]

I'm unhappy with the idea of creating an overcomplicated power projection tool. I don't think that is a net positive for the game and I think that does the exact opposite of what the terminal nerf is meant to do.

[undone whale]

How do you figure?

[modest grove]

I saw many newer combat-focused players like Harabi explain the issue as such: Terminals currently allow a larger empire to outcompete any amount of focused local power projection purely through economy. They wanted, from what I saw, local power to be more important, so they could compete against the more established alliances and destroy them bit by bit. Buffing power projection seems to just exacerbate that? Sure they won't be able to use terminals but if they can boosh their defenders in from 20 rooms at a time all across the shard, that's hardly a better situation and would in fact let those larger players then overwhelm their opponents even better.

It's possible I completely misunderstood the situation. But that was the most compelling argument, in my view, in favor of the terminal nerf.

[distant glade]

I think the 3% TTL cost idea by gadjung is a decent compromise, it allows somewhat stronger power projection at significant cost but by the time the combat creep arrive at the frontline, it's still not a fresh creep.

[modest grove]

I am not, generally, in favor of making it easier to knock over people's sandcastles, but I do understand the argument of making it possible to play as the underdog

[undone whale]

That is not really my understanding of the issue. My understanding is that terminals being so strong makes for boring gameplay. It takes the excitement out of sieges when the terminal is a never-ending fountain of resources allowing the room to hold indefinitely until the empire is drained. And it doesn't even require enemy combat creeps to show up to break the siege, they just spawn local creeps with the unlimited resources and sit safely inside the ramparts forever.

The terminal nerf on its own would make combat more interesting by preventing sieged rooms from holding forever (just for a long time) so the side being sieged would need to be more active in breaking the siege or fighting back. Gateways would further make combat more interesting by bringing more active creeps to the frontline when they are used and by allowing for such supply lines to be cut. A large opponent could still be formidable, but they would have to do it in a more active and engaging way rather than just with a large economy making their rooms impervious to attack.

[modest grove]

I have seen the results of balancing a game by what is "exciting" before, and the results are rarely a good thing.

Power projection is already such that a sufficiently established player can just chase someone across the entire game world and prevent them from respawning. It's happened before. Buffing that is very dangerous.

[undone whale]

What do you see as the danger of it? If that chasing is already possible, what would this change about that?

[modest grove]

I would make it even more difficult to deal with. There are currently at least some places that are difficult to reach via shard0, extending players' reach would make it even harder to hide from a vindictive player with a grudge.

[silver ocean]

To be clear as @distant glade points out a % TTL penalty allows for long range logistics - which is still the focus of this, but nerfs any sort of power projection over long ranges

[modest grove]

Yes and that's what DroidFreak is saying shouldn't be nerfed, I think. Idk man these's like 5000 messages here I may just be lost at this point.

[distant glade]

yea, %TTL cost still allow burst haul if you dance it with renewCreep

[undone whale]

I don't think it would really make a difference in that scenario.

I see this as being primarily a tool for large, near-peer rivals to fight each other. A fight between vastly different power levels is always going to be imbalanced.

I also don't think that the sort of scenario you are talking about should be what the game is balanced for. It's extremely rare for a large player to get that pissed off at a small player. Usually the most they do is automatically swat away any small player that infringes on their territory and move on.

[silver ocean]

True hes arguing for the counter and i agree, there are a lot of messages, conflicting points of view but it is at least getting clearer with each pinned message, hats off to artch for trawling through all this XD

Personally i was trying my best to keep up with it all as this was quite an exciting proposal.

[distant glade]

with terminal nerfs actually power projection do get hurt a bit, because your frontline room can't sustain 24/7 quad spawning indefinitely. But I'm still in favor of not allowing sending the full weight of your empire to the frontline just because you can pay for it. I personally like %TTL idea, it still allows you to recruit spawner from moderately greater area to contribute war effort, but you eventually come to a trouble of keeping them stocked with resources to sustain it indefinitely.

[undone whale]

I see a TTL cost as being a bigger issue non-combat use, actually. Because it is a form of cost-per-teleport which reduces the benefit of using it for burst logistics (where cost-effectiveness matters more), whereas for combat, higher costs are tolerated if they have a payout in the outcome of the fight.

[distant glade]

if we use 3% TTL per jump, you can do the dance with renewCreep once the haulers are at around 30 TTL or less. Very close to dying, but can stll be sustained indefinitely.

[silver ocean]

Yeh the % fixes that, you care far less about haulers being nearly dead by the time they arrive than combat creeps. Because its a % you can move huge distances at the cost of the creep being nearly dead on arrival

[distant glade]

yes, but still a bit fresher than manual walking, so there is some value in it.

[glacial panther]

Personally with the %TTL cost this seems fine and addresses the problems I had with creep teleportation before

[undone whale]

That still adds some energy cost, and a lot of complexity. Plus, any form of TTL cost not only reduces efficiency of the connection, but also throughput because spawn time limits your throughput.

[glacial panther]

I just dont want this to be the new default way of moving creeps, and rather an option even if costly

[undone whale]

I think that the ghodium cost effectively addresses that concern.

[glacial panther]

For peace time creeps sure, but if you are attacking someone, sending in boosted attackers the ghodium cost is not necessarily significant compared to cost of the creeps being sent

[distant glade]

%TTL still allows you to not have to respawn the hauler for throughput purpose, but you do need to dedicate some time for renewCreep-ing very low TTL haulers that is sent your way. Still cost some spawn labor time but not impossible to maintain full throughput during 500 tick transfer window.

I advocated for floor(3% * current_ttl) formula for jump cost, so once you got 33 TTL or below, portal jumping is free and you only have to deal with the natural 1 TTL decay per tick of the creep itself. Which means your transfer throughput is still viable to be maintained at max rate indefinitely as long as you dedicate 1 spawn on each end to renewCreep-ing whatever creep they come across.

on very long distance (more than 12 room distance), you do have to resort using 2 spawn on both end to renewCreep, and for even longer distance, you might have to resort using smaller creep so renewCreep can still maintain it indefinitely, but the limit of viability of full throughput is 33 room distance.

it does limit base design to allow for it though.

[glacial panther]

There is a middle ground where boosted creeps would suffer a %TTL penalty and unboosted creeps would not, I dont personally see a need for it but that would make the hauling side less complicated and limit military force projection

[distant glade]

then you still can project unboosted military creeps to frontline room and boost there using the labs

[glacial panther]

Sure but it's more complicated to implement, you can do it but maybe the game should allow you to do complicated things and get a benefit

[undone whale]

I don't consider combat creeps walking slowly to their destination to be compelling gameplay anyways. And I think it would only become the default for large-scale conflicts anyways, since the cost would be pretty high to pay for a small conflicts. Plus, they can be disrupted.

[silver ocean]

Would it though? boosting costs no cooldown on labs. Work around would just be spawn creeps in distant room (spawn time is a limiting factor for army creation). Move unboosted to room on front, boost them there. Also having a cost that applies to one class of creep (boosted) only is a little less elegant but not too unreasonable.

[amber adder]

sounds good. fatigue fits current game meta better since TTL penalty is totally new.

and fatigue can be overcomed by hauling or orther intended (complex) code.

I suggest 20 fatigue per non-Move bodypart, which means 10tick for a normal full-speed creep

fatigue also encourages logistics usage. in a round-trip, the backward have no fatigue penalty.

10tick fatigue per room slow down the force projection, give time to defence or interceptions

fatigue penalty can be reduced if the attacker is willing to trade-off as less non-MOVE bodypart and more MOVEs, which weakens the force

[distant glade]

can be abused using room edge. fatigue is reset when stepping on room edge

it will hurt hauling more than force projection

[amber adder]

when a creep landed, it's between (include) coord 1~48 with fatigue.

[distant glade]

a pull creep can be prepared near room edge to pull it out

[amber adder]

cannot step into the exit by itself

[amber adder]

that's the complex code tho

I'd prefer not to reset fatigue after passing exits

but it requires the dev's work

[distant glade]

still, it is not effective for deterring power projection. If it's op for power projection, someone will still code it eventually.

abusing op mechanic is always great motivator for creating complex code.

[amber adder]

if fatigue is not reset after passing exits, then everything is good

[distant glade]

it makes normal hauler a lot more complicated to code, because you can't build road in room edge

so they will blink multiple times before they can move again for let's say 32C 16M hauler

[amber adder]

then let the exits tiles cause no fatigue

[amber adder]

yes but still much faster than hauling step-by-step

[undone whale]

My intention with that proposal would be for it to apply only when stepping off of the portal, not when traveling along the portal network.

[undone whale]

I assume that you could not build them next to room edges.

[distant glade]

you can still using puller chain to yank it out to room edges if you are dedicated at force projection.

[amber adder]

I'd like to make it need to step into a portal in each room during the journey

in artch's description, the other end of a jump is a backward portal rather than a forward portal

if so, creeps need to step between each jump

[distant glade]

then you slow down the transfer rate? it makes the 500G activation cost not worth it IMO.

[amber adder]

more haulers can increase the throughput

[distant glade]

you can't send more than 500 hauler during activation window already

if they have increased fatigue upon stepping a portal, it means they will just clog the portal blinking back and forth, creating traffic jam.

if you use more hauler, you have more car, but still traffic jam.

besides, if you use it for power projection, you don't need to send 500 creep over the network, you can afford having each creep blinking back and forth for 10 ticks before stepping on the next portal and you still manage to send 50 combat creep over.

[undone whale]

That seems fine to me. It wouldn't reduce the effectiveness at what my intention was - avoiding making one-room hops every other room the meta (if the exit portal did not require power) and reducing the surprise attack potential.

[distant glade]

I suppose you are currently advocating for maximalist power projection proposal?

[undone whale]

More or less. I don't think that reducing the power projection potential should be a reason to nerf them. I disagree with a TTL cost per jump because it has only downside, in my opinion.

I think they should be high cost high reward to make them a meaningful mechanic. The G activation cost covers the high cost side of that equation effectively, I think, and a TTL cost just reduces the reward to make them less useful.

[amber adder]

no blinking, you land adjacent to a portal rather than on the portal

IMO, if exits won't change, just constrained the portal can only be built 10 tiles away from exits

to avoid abuse

[amber adder]

u still can do that with haulers to haul tired creeps

10 creep's waiting in each room for fatigue, the portal has 8 adjacent tiles

just need 2 to move one step to avoid stuck

1move can haul the tired creep away

[distant glade]

I think we have different opinion here. I think the terminal nerf is a welcome change to emphasis local power concentration. The power projection buff to me is supposed to partially bypass the nerf at significant cost, not completely invalidate it. My position is more on allowing the mechanic to be low-moderate buff for power projection but still not allowing you to bring full weight of the empire into front line.

[maiden marlin]

for me it's unnecessary hassle to haul resources via bus/portal, why not operate_terminal and have up to 1050 resources per tick
imho bus would be good only for remotes/power projection depending of implementation

[amber adder]

temple room under rcl6; defense and don't want power enabled.

[silver ocean]

I guess its good for those that dont want to activate power but you are right, that would be a much cheaper and easier option.

[undone whale]

That's why I think that it should be more efficient than terminals for logistics. The flat G cost would limit it to only being good in high-throughput bursts, but if it was more efficient than terminals in that niche then it would be useful.

[amber adder]

the amount of G and "summon weakness" is still requiring balance

if reuse the existing Portal mech, there is no stunning or fatigue after jump.
the limit can be: the constructed portal (c.portal) cannot be built in range X of other c.portal, and not in range Y of exits.
Such constraints may not meet Droid's idea, but give limit to throughput and force projection.

If so, the balance can be made only considering G. the meta is consuming G for saving path lengths.

[silver ocean]

According to the latest pin though thats the direction that is desired, burst of throughput

[amber adder]

my mistake, same-shard portal lands ON the portal rather than around (adjacent to) the portal

then Droids step-out penalty is applicable.
if we allow two portals to be adjacent, creep can step into another portal without the penalty.

and it also makes sense for hauling round-trip: the jumping creeps are always on the portal, and other creeps upload/download.

when used for combat, the creep needs to step out eventually, then the penalty applies.
if portal cannot be built near controllers, the CLAIM range limit also can be achieved by the step-out penalty.

I think this solution is neat. a creep can blink back if it stay on the portal (if the backward portal is also active), or take the next jump by stepping into an adjacent portal.
player build the portals, activate them by G, make the BUS creep blink back and forth, other haulers upload/download resources on the two ends.

IMO, only one c.portal need to be built for a 1-room round-trip. the destination coordination should be assigned when create the c.site, which keeps the current inner-shard portal's function instead of requirement of building and activating a backward portal.

[minor reef]

Let's now try to analyze another idea in parallel. We keep portals in mind, we're not dropping it (in its various forms), but let's compare it with a concept that was proposed here earlier: a pylon network for terminals, which removes the throughput restriction for them.

Terminal nodes

StructureTerminalNode can be built in any owned/unowned room, limit of 1 per room. It's an inexpensive static unowned structure with no special methods or properties. Stats, for example: 10K construction cost, 500K hits, decay 1000 hits per 100 ticks.

Incoming terminal transfers throughput is limited to 50/tick only if there is no continuous path of nodes or terminals leading to the sender (if a room has a terminal, it counts in place of a node). Each send and deal triggers a lightweight pathfinding check across the entire shard room grid to determine whether a path exists from one terminal to another. In a cluster of adjacent owned rooms each containing a terminal, building nodes won't be necessary at all. If there are gaps of rooms without terminals, those need to be filled with nodes — and they can be destroyed to break the path. Maybe a new method Game.market.checkTerminalNodes(room1, room2) would be beneficial for checking before sending.

The throughput boost via OPERATE_TERMINAL might be better off dropped entirely, it makes things too easy. The only way to maintain terminal throughput should be to maintain the network.

Unlike portals, this doesn't provide any power projection and isn't nearly as global a feature, but it aligns well with the upcoming terminal throughput changes.

[true shuttle]

i understand that while a single player builds it, in theory "everyone" can utilize it ?

[minor reef]

yes

[true shuttle]

i'd make them a bit more fragile so bigger group of invaders in remote is able to tear it down. love the concept

i dont know how feasible it'd be, but could the decay be tied more to utilization, rather than "by default" ?
(more in controller downgrade factor, rather than hits)

[amber adder]

terminal nodes are much simpler than portals. good for the leaning curve of the game

[silver ocean]

No complaints about this, it gives a way to send resources bypassing limits, its simple, it is something earlier game players can take advantage of, its interceptable, not too expensive. All round solid idea.

[amber adder]

dose hostile terminal counts for a node during the path?

[minor reef]

yes

[silver ocean]

That makes sense as allies are technically hostile

[amber adder]

I think the little bad thing is a new player may not even noticed the terminal limit when he starts in a crowded area.

[silver ocean]

I dont follow how would being in a crowded area affect terminal limit of a new player?

[amber adder]

he is passively connected by other's terminal node

and thus has unlimited terminal

[undone whale]

I think that new players would be unlikely to run into the 50 units per tick limit before becoming aware of it via the docs.

[silver ocean]

Ah in the connected area i guess thats true

[undone whale]

You have to be not so new to even be able to push >50 units per tick

[wary surge]

I suspect cutting off a room could be quite difficult in this case, depending upon geometry and how acceptable it is to cut off other nearby players.

[silver ocean]

I guess this could be vulnerable to respawn trolling. Like respawn delete structure repeat.

[wary surge]

E.g. the target room is on the other side of a terrain walled area belonging to another player.

[silver ocean]

Unless all rooms are reserved in network

But so have the other ideas XD

[wary surge]

If the attacker has to go right around and through other players' claimed rooms to reach that neighbouring room, it will be much more of an issue.

[silver ocean]

Negotiations gunboat diplomacy id argue its all part of the game

[wary surge]

Yeah, it would definitely have diplomatic implications.

[undone whale]

I think that for these to feel like a worthwhile addition, they should improve terminal send efficiency as well as throughput. The need for greater throughput would be rare anyways, while greater efficiency would always be useful.

[minor reef]

Actually, what about an even more radical idea: don't add any throughput concept at all — just block terminals from functioning outside the network entirely. No connection to the other party — nothing works. Not even through the market. Connected — everything works as before.

Yes, it's a drastic change, but then there's no need to calculate throughput, think about whitelists/blacklists, and overall it puts more emphasis on topology and locality in the game. It opens up the ability to control regions of the world for access to resources and markets, and creates stronger incentives for cooperation, diplomacy, and conflict.

[wary surge]

Would there be any way to determine which market orders are dealable from your room's terminal?

[minor reef]

See above: Game.market.checkTerminalNodes(room1, room2)

[weak wedge]

Will NPC terminals then act as part of the network? Meaning that rooms on the corners of sectors would be important for connectivity between sectors?

[wary surge]

I expect that a lot of highways would have nodes built in them

[silver ocean]

The markets are already so weak in screeps, please dont do this lol

actually at first it would be chaos but maybe this ushers in a new era of cooperation, like working together means you get connected to market network, failing to do so may mean you are isolated

[wary surge]

I expect that pretty much all but possibly tiny islands, possibly in the far corners, would be connected.

Within a week or so, anyway

And any deliberately cut off through violence.

[silver ocean]

if you do this, you should get rid of the decay though

[wary surge]

Let's see ... ah right, 10 hits.tick so about 0.1 energy per tick for each one.

Certainly not a large expense, but definitely annoying 🙂

[amber adder]

I'd like connecting to a crossing of highway means connected into other parts of the world. this make a big shared market.
diagonal room will not counts for connection, thus make the nearest room interceptable.

[wary surge]

me wakes up and chooses violence and also make it require room exits to count as a link 😏

[minor reef]

Yes, they will. And there is an interesting twist with NPC terminals: each NPC terminal tracks its own transactions to calculate order prices. This means if some NPC terminal is cut-off and controlled by some player/alliance, they can take advantage of more profitable buy/sell prices with this NPC terminal.

[wary surge]

Ooooh.

[minor reef]

That's an option too

[minor reef]

If we drop decay, maybe we can launch this feature flipped the other way around: place a pre-built node in every unowned room from the start. Nothing needs to be built, everything will work as usual by default when the update launches. But once you start destroying them, that's when things start to change.

[silver ocean]

sounds good, and if it looks like the network isn't being altered after months a very slight decay could be introduced which you could ramp up based on observation

also doing it that way makes it far far less disruptive when it is first introduced

will just say again though, markets are already pretty weak, this could go quite badly and result in basically destroying the player market.

[amber adder]

sounds good.
smooth for the community to get familiar for it.

[minor reef]

Destroying unlikely, but definitely making it more localized, with price variation even within a single shard, not just between shards. That's more of a good thing than a bad thing, since it adds extra depth to trading, logistics, cooperation, etc

[silver ocean]

If there was like a thriving market across a particular shard I would be more inclined to agree but I have already noted people complaining about how week things like the boost market is, and that is with access to the entire shard! Not saying the plan is bad necessarily just this could be a consequence. For example for me, the nearest person selling energy (arguably the easiest thing to sell on the market) is 27 distance away (i just looked that up).

and looking at T3 boosts as well, there are between 1-6 sell orders for them across the whole shard

[minor reef]

I think 90% of players will still be connected to each other, with the only exception of some war conflict areas and deliberately isolated regions

[silver ocean]

hmm, I guess if you make it so diagonals connect (not 100% necessary though I think but adds more network stability), there is no decay, initialise in every room and they can connect even if there is no exit to a particular room that is likely to remain true for a while

[minor reef]

Exits are not relevant, yes. Diagonals - we need to consider this.

But hey, with this change, the word "siege" actually starts meaning something. Cut off a chunk of someone's empire, remove all the nodes on the perimeter, keep patrolling, and slowly choke them out because there is no way they can get supplies, even at 50/tick rate. That's exactly what we wanted, and something the game has really been missing.

[silver ocean]

Agreed, i do think this is very interesting and would change the attacker defender dynamics completely, just making sure we look at different angles!

I dont think this nerfs defender advantage too much especially if they are cheap and connect diagonally

[minor reef]

I think diagonal connection is problematic due to NPC terminals. Too hard to cut off

[amber adder]

yes

I don't like diagonal connections

[true shuttle]

i'd put "permanent" nodes only on highways

so player still needs to build and defend "something" if they are not right-across highway

[minor reef]

I didn't mean they are permanent. Pre-built but destructible

[true shuttle]

npc terminals would need to be connected to the network though ?

[minor reef]

Why?

[true shuttle]

because if they are not connected, players cannot get the specifc npc order from it

(i mean it can be a feature also)

i very much like the idea, but at the same time, one thing to take into account is that it requires significant player input to work,
which might be issue depending on how many zombie players are there

(also if highways have the "permanent" ones, rooms next to highway are OP - so ye right cannot be)

[minor reef]

This is a feature, and a nice one, because of [this](#1450220297063104703 message)

[minor reef]

What kind of input?

[minor reef]

I don't think we need any permanent nodes at all. Except NPC terminals which act as nodes on their own

[true shuttle]

if they are not "prebuilt", there can be quite-big-patches without access to market, noone (or very few players to build it) and "zombie legacy" code constantly destroying it

[silver ocean]

I think thats one reason why it was suggested

[minor reef]

Prebuilt doesn't mean permanent

[true shuttle]

yes, so it's spawned, zombie-overmind keeps wiping it after each rebuild

for the prebuild, i'm thinking how viable it would be with slightly changed behavior:

• every room gets terminal node
• by default, terminal node is off
• terminal node can be turned active and putting "switch" on cooldown
• terminal node can be turned inactive and putting "switch" on cooldown
• when terminal node is on "switch" cooldown, it cannot be switched to other state

though personally i like the idea of build-and-defend-from-destruction also

[amber adder]

I don't think zombie overminds have the code to destroy a newly introduced structure

[true shuttle]

it's enough for zombie to have a .find() that excludes roads, containers and controllers

[silver ocean]

I'm not sure if this will be a big issue globally, there are a lot of structures one will need to cut to make the probability two distant rooms are not connected high - even without diagonal connections and just a grid connectivity

But i guarantee at least one person will do nothing but spawn in and destroy the ones they can, respawn... so overtime isolation will occur

[minor reef]

Maybe terminal nodes shouldn't be player-constructible structures, but work more like power banks — they spawn on their own in walls in all rooms, you can destroy them, but after a while they respawn. If you want to isolate an area, you have to constantly hunt down and destroy newly spawned nodes. Once someone stops putting in the active effort, things go back to normal. After respawning, a node remains inactive for some time, so that you can go and destroy it until it's active again.

[silver ocean]

I guess that fixes it but it is far less interesting. Another solution may be to somehow make it cost more to destroy than build (no idea how). Wakfu has something similar for environment managment, plants to harvest for example dont just spawn a player needs to actually plant them, it is much easier to plant than to harvest the resources though... Not sure if this is even possible in screeps though, just throwing ideas out.

With the structures auto respawning i think it kills a lot of the interesting player dynamics that would have potentially otherwise emerged though.

[zinc quest]

The idea of being able to indirectly war against a player by destroying their market access is quite the entertaining prospect, that's for sure. This most recent idea is a fun one.

[maiden marlin]

reserving room can prevent that

[true shuttle]

i'd prefer the on-off behavior (or the original, "you have to build them") rather than them "respawning" after "random time"

[minor reef]

In the on-off behavior I don't like that there is no need to attack. But if you attack something, it should be destroyed

[true shuttle]

so i'd say the build-destroy would be then the best solution, with "prebuild in every room" state

[undone whale]

This concept seems decent to me.

It means that players generally don't need to worry about the mechanic, unless someone is currently destroying nodes near them or they want to cut off an enemy room. And even then, it will go back to normal on its own after a while if the destruction stops.

[true shuttle]

but that means that rather "key" mechanic is mostly irrelevant for most players

[undone whale]

That seems fine to me. This whole topic exists because of an issue that applies to wars between large players (that is, terminals making things boring and static). The respawning node proposal addresses that issue with minimal impact on other players.

Eco in peacetime would be completely unaffected, and for smaller players in wars they probably wouldn't be getting much terminal support anyways. By the time it would be relevant to them, I think they would definitely become aware of it. After all, they would see the nodes in every room.

[maiden marlin]

maybe socket:
new structure in every room
when connection quality > 80% then connected to network
you can improve quality with energy
connection quality also increase every tick/x ticks passively
by attacking socket, you decrease connection quality

by default every room is connected, can be disconnected by force, can be reconnected

[maiden marlin]

(maybe the bigger connection quality, the higher your terminal throughput is ^^)

0% - 0/tick
50% - 50/tick
60% - 100/tick
70% - 200/tick
80% - 300/tick
90% - 500/tick
100% - 1000/tick
if you send (or buy/sell) resources then max throughput is the lowest connection quality in path between terminals

[maiden marlin]

max quality - 1000000
repair - 10 / 1 energy
dismantle - 10
regeneration 1000 every 100 ticks

[silver ocean]

Hmm, prefer the suggestion artch put forward, simpler and solves the main problem we were working on

[glacial panther]

Nodes sound cool, maybe there will be more diplomacy and even fighting for npc terminal control

[undone whale]

An interesting thing about the NPC terminal control is that for a player to trade with the isolated terminal, their own room would also have to be on the isolated network. So, if they want to trade with the broader shard network as well, they would need an "airgap" between their own rooms, with creep hauling being used between them.

IDK if it's been said already, but I would suggest that when they respawn, they become visible and vulnerable before they become active. Maybe something like the spawn-in timer for strongholds, except that they can be destroyed during spawn-in. That makes it much more feasible to maintain an air-gap between networks.

[solid elm]

So every room automatically spawns terminal nodes and if you destroy the node you can isolate the network?

[undone whale]

Yes

[solid elm]

So if I want to attack the room, if I keep destroying nodes in these 3 rooms, I can block the terminal usage?

[undone whale]

I think that artch said that it would not respect exits so it would need to be the north room as well. I'm not sure about that though.

[solid elm]

Ah, so you always have to surround the room

[silver ocean]

There are two competing ideas right now, 1) they initialize the nodes in every room but then it is up to players to build/destroy them 2) the nodes automatically respawn like after a certain time period or something.

btw if we do 2) artch you should make it so you can destroy a node that is being respawned. Like it takes 100 ticks or something just so if you are seiging you can keep it going as long as you control the rooms.

[solid elm]

I see. I'd prefer the second option

[wary surge]

Maybe except for the very first spawn-in, they respawn inactive and need to be activated by a creep?

Then once activated they stay that way until destroyed, presumably.

Though I suppose it could have an activation timer instead.

That way zombie bots still function unless someone is actively maintaining cutting them off.

[silver ocean]

So option 2 more generally will achieve the primary goal of providing a mechanism to cut off terminal throughput BUT it fails to achieve a stated secondary goal of trying to force localisation for markets on a shard (which even with option 1 would require a lot of destruction to achieve)

[wary surge]

Yes, I think you would only get partition of whole sectors or more if players had to build and do upkeep.

[lethal juniper]

Why do I feel attacked here...

[minor reef]

#1450220297063104703 message

After spawning, a node is inactive for some time, so that you can go and destroy it until it's active again.

[distant glade]

Hmm, I think if we go with absolute 0 reception when out-of-network, then defender's advantage almost entirely evaporate. Since the defender always need to fight in the open, necessitating similar level of military investment with the attacker.

Of course, the defender can just hunker down and harvest energy from its own room only, but if we ignore intent and cpu for a moment, the attacker is already at energy advantage as it is unconstrained to harvest from its own remote.

[undone whale]

There is definitely still some advantage to the defender, because a room can defend for a decent amount of time on just the resources inside it. And, depending on how it is set up, the defender could potentially hold a supply line for a short period of time to allow resources to pour in and replenish the room's stocks.

[distant glade]

oh, I see, the defender don't need to contest the network 24/7, just barely long enough to receive 1 tick of resource injection once in a while.

I think as long as the node respawn timer isn't too long, it can work. Otherwise there might be a case of double blockade that prevents single siege-breaker wave to clear the blockade on its lifetime.

[wary surge]

Seems like a lot of code written around sieges assumed to involve only the defending room will stop being effective.

I suspect it would be very difficult to write code that is effective at contesting the network if there's a player on attack but the defending player is asleep.

I guess the defending room might have enough resources locally to hold out until the defender is awake.

There's also safemode, but that is only allowed on 1 room at a time.

[minor reef]

Also, you can have a cluster of rooms with protected perimeter, all those rooms will be able to supply each other even if they are cut off from the global network

[wary surge]

It's possible yes, very few people actually have such an arrangement at the moment.

So it may require a major reorganization.

It tends to mean having quite a lot fewer remotes.

But maybe they're a luxury that players won't be able to afford anymore.

[minor reef]

Currently a lone distant colony of a big empire is as strong as every other room in this empire. After this change, it will be indeed a vulnerable colony in comparison to the empire's main cluster

[wary surge]

Yep. A lot of empires these days are entirely composed of "lone colonies".

Very porous boundaries, but each claimed room was previously strong enough to hold.

I expect with this change, Tiggaland will quickly fall.

Well, "quickly" in Screeps terms.

Most of Tigga's rooms are 4+ hops from the nearest other Tigga room.

Most empires aren't quite that sparse, but a large fraction of them are 2-3 rooms apart.

[true shuttle]

defender can send reinforcements from other rooms. or ask other players for help

so "strategically" game gets medieval level of combat

which makes a lot of sense game-design wise

[silver ocean]

I guess that's actually quite desirable if the bigger players end up clustering their rooms more that opens up the world a bit more. On the defenders advatage point if you can defend the 4 neighbours, the difficulty in cutting off a room completely increases exponentially I believe as a function of the distance from the room you are trying to cut (I haven't proved this, its a hunch).

[wary surge]

Oh yeah, it would get very much more difficult. Hard to quantify since it depends so much on room topology, neighbours, etc.

[silver ocean]

well just the number of rooms you need to cut off I was refering to

[wary surge]

Oh, it's linear in radius

But the difficulty increases if you have to kill some other player's room to do it.

Since other player terminals count as nodes.

Also some will end up in dead-end protected mazes etc.

[silver ocean]

4,8,16 at D=1,2,3 I believe right? as each extra unit of distance adds 2 new rooms that also feed in to the ones closer (3 but they share them with neighbours)

let me draw it out...

[wary surge]

It's 4 extra per radius.

(π = 4 in Screeps)

Oh, I guess π = 2 since it's 2 π r.

[silver ocean]

I miscounted I think you are right it is linear yep

[wary surge]

But yeah, the chance of being able to effectively destroy them all drops pretty fast.

[distant glade]

what about cutting off entire sector? patrolling the highway so entire 9x9 region is cutoff?

[wary surge]

You can't kill the NPC terminals

So you'd need to also get one or more corners

(Some corners are hard to reach)

[distant glade]

diagonal connection doesn't count I think?

[wary surge]

I haven't read the entire discussion, it's thousands of lines. Let me check...

[silver ocean]

that's still 81 rooms you need to attack and keep down

[silver ocean]

no diagonals

[wary surge]

Okay 🙂

Then yeah, if you can take out the nodes in the 40 highway rooms around a sector that woudl isolate it.

[silver ocean]

I've watched this go through so many itterations now, but I must say, I think this one seems to have far more agreement 😄

[wary surge]

Though a whole sector can probably hold out a long time.

[silver ocean]

true, lots of mining opportunities just internally

[wary surge]

And you may also catch other players who object very strongly.

Ones who may not even have been allies.

(But they will likely be temporarily allied against you now!)

[distant glade]

yea, I do think depending on topology, you might have to cut-off some bystander to actually blockade your target

sucks to be them I guess.

[wary surge]

Most of my rooms seem to have at least one neighbouring protected room that borders another player.

As in if you attack from one side, it's a looong way around or one room is outright in a dead end.

Mostly because I don't have many remotes compared to bigger players.

For one group of rooms you would literally have to cut off the whole sector to blockade without first taking down owned rooms.

Ah no, not quite. There is one room that provides an opening to the centre rooms of the sector which can cut off 5 owned rooms in the sector.

If this change goes in then that will get plugged 🙂

[wary surge]

I think because it has so much fewer moving parts and unintended side effects.

Something like the other stuff could still also be added, as some stage.

I mean, this is a much more direct nerf, no room for speculation about how to use it to boost some favourite aspect of logistics. There is no boost, only nerf!

It's just a different nerf from the 300k buffer + 50/t nerf 🙂

[silver ocean]

well I mean even for the other effects there were always different ideological camps, like force projection, some hated it some loved it and then the question of how to balance it was reflected in that. Creep transport, some supported it being good for mining others hated it, anyway just glad we have come to something interesting that people can agree on. The bus thing was tending toward being nerfed into uselessness.

[wary surge]

I was a bit concerned about "pathfind" but it's really just an O(n) shardwide union-find.

Done once per tick at most, usable by everyone.

Probably really less often than once per tick, since it only needs to be updated on activate and destroy.

[silver ocean]

which will probably happen somewhere across an entire shard every tick, but I am sure there are efficient ways of handling that

[wary surge]

Union-find on 15k-ish nodes should run in milliseconds.

As in single-digit milliseconds.

[silver ocean]

I'll take your word for it, I have 0 expierience with the algorithms to do it

[delicate echo]

anything runs in milliseconds if you convert the time to milliseconds

[distant glade]

You don't need to do it every tick, no? just on changes, like if some node turn state from inactive -> active or active -> dead. Save computation cost even more, even though likely still have change every 1000 ticks or so on average.

[sweet cove]

If screeps starting using some WASM compile stuff on the background could probably save a lot of time and headaches.

If they're running UnionFind every second in just.. regular JS I suspect it won't be so cheap. Depends how efficient it is. Might depend if they can fetch the "edges" (room exits, room types) faster than we can.

[undone whale]

I think it would ignore room types and exits.

[minor reef]

No need for union find. It's just flood fill with different region ids, which takes ~1ms for a 120x120 grid according to our tests, and then an instant check room1.regionId == room2.regionId.

[sweet cove]

That either sounds like UnionFind or a worse choise than UnionFind 😄

But if it's ~1ms I guess it's fine either way

[minor reef]

No, it's not. Flood fill is static and simple, union find is dynamic, more powerful and computationally intensive. We don't need actual graphs here, because we don't need dynamic changes in the grid

[amber adder]

I am really curious about how you implement flood fill for this.
Is it finds 1 area each time and runs N times if the map has N areas?

[wary surge]

Sure that works. Run flood fill starting with any node that wasn't found earlier, until you run out of nodes.

All of these are pretty simple O(n) algorithms.

But yeah, these graphs are small enough that recreating the regions each tick is fast enough. No real need for data structures that allow fast updates.

[amber adder]

then how to get the nodes that wasn't found earlier? creating a Set holding all unvisited nodes and?

[wary surge]

Yes, a Set is the usual sort of data structure for that

Start each flood on an arbitrary element from the set, until you have no elements left.

(removing the ones you visit during the flood, of course)

Though in this case you don't even need anything as complex as a set.

(Though given that it's built-in and pretty decent performance, it will do)

All you really need here is an array of bits and a counter.

The counter just tells you where the first unvisited bit is. When that's visited, you advance it.

In an object-based system like Screeps, you would probably just look for the next room that doesn't have a region number.

So you could do without any sort of extra data structure.

[sullen tundra]

how will these disconnected areas in shard 0 be handled with the regions?
will they just be completely separated from the rest of the world?

[minor reef]

They will be connected through nodes in the highway rooms

We will make sure there are open highways connecting all areas

[minor reef]

Terminal Nodes and long-range logistics revamp

[night bronze]

Okay, my 2 cents:

• Separating an NPC terminal from the rest of the network:
  This may be hard. I think alliances will be incentivized to connect all their rooms through terminal nodes with the main network.
  NPC terminals are important, but keeping it separate from the global main network may be hard.
  I think the default configuration will be that there is one global network.
  Different alliances will probably establish some trade agreement (or maybe just build nodes) connecting all networks together.
• Maybe allow terminal nodes to use portals as well?
  Providing alternative paths may be important to increase resiliency.

Okay, more on that global network:
It is hard to keep larger networks separate.
One room may accidentally connect two previously unrelated networks together - but this is usually a good thing anyway - as it makes it possible to trade with even more people
Depending on the geography, it may be hard for people to cut those connections - and with several people trying to maintain the connection & safemodes, it may even be impossible to cut all connections.
(Worst case: Two alliances are fighting each other, but one player of each alliance have a room next to each other - maybe not even with a passage, so this was fine before, but now it connects everything)

[night bronze]

You could treat the closed highways as "has a terminal node" that does not decay (or can be destroyed)

Then of course, I expect the a******* - running around on the highway destroying nodes.
Meh, this may be something the community can deal with.

[minor reef]

Since nodes respawn in every room (even owned), we can use only nodes for the network. Terminals won't function as nodes. Two terminals in adjacent rooms can always talk to each other, but if there is another room between them, then there has to be a node in it, even if it's a room with a terminal.

This means one terminal can connect to two networks which are isolated from each other - if this room with a terminal doesn't have a node.

[zinc quest]

It would be cool that, if we go with naturally respawning, destructable nodes, that they could be rebuilt by dumping energy (or a resource) into the destroyed node.
Don't know if that has been said yet or not.. been a long conversation here.

[night bronze]

Respawning nodes make a lot more sense when the default is "everything is connected".
Problem are respawn timings and stuff - for example if you want to isolate a room, you would need to keep the 4 adjacent rooms without a node.
But if the nodes can respawn at any time, it could connect the terminal to the network for just long enough to transfer some stuff.
So: They maybe need some time to establish the network after they spawn.

[minor reef]

#1450220297063104703 message

After respawning, a node remains inactive for some time, so that you can go and destroy it until it's active again.

[zinc quest]

The hope too would be that it wouldn't be too fast a respawn.

[undone whale]

My thought on that balance is that it should be relatively fast to spawn a new node but take a relatively long time for the new node to activate.

My reasoning is:

The activation time dictates how often someone attempting to isolate networks needs to patrol regardless of how often the respawns are. So it should be long enough to not make it too much of a burden to isolate networks in an unopposed situation.

The respawn time gives no meaningful effect on anyone in an unoposed situation, but in an opposed situation, it hurts the person attempting to reconnect networks because they have to wait for the respawn to begin (being ready to immediately start defending it) and only then can they begin defending it long enough for it to activate. So I see no benefit to a long respawn time. It could probably be instantaneous with no downside.

[minor reef]

Any rough estimate for an activation period duration that would be convenient?

[true shuttle]

how many hits would the node have

[undone whale]

I think it might actually be beneficial for there to be a way for players to actively speed up that activation time.

I have a wacky proposal that would achieve that effect:

• Any room without a node or a node cSite spawns a node cSite immediately (or within a period of 100 ticks, at least)
• Node cSites passively gain construction progress over time.
• Players would have the option to build the node cSite with their own energy to speed it up or the option to stomp the node cSite to easily suppress its respawn.
• Node cSites would be specifically excluded from dropping energy and nodes would be specifically excluded from dismantle.

If it was done that way, then the activation time (set by the construction cost and passive gain rate) would not need to be quite as long because the patrol could just be a scout stomping the cSites, and someone trying to reconnect networks would also not have to wait if they add build progress.

If you went with that, the respawn time and build cost should probably be high enough that an attempt to rebuild a node could be spotted and stopped before it is complete (with enough combat power to win the fight).

[true shuttle]

i like that idea, having like 10-20k build cost, with 5-10progress/tick would land it nicely imo
(assuming the hits are low enough that it's fast enough to take it down)

[minor reef]

Allowing to boost activation creates too much defender advantage. The defender can find good timing, complete the construction almost instantly and use the network immediately. The attacker doesn't have time to react.

With activation time that can't be boosted, you have to actually defend the node during the entire period, which is a good balance in this case.

Considering that in most cases only one node will be needed to connect the entire cluster of rooms

[true shuttle]

it boils down whether it's better to have

• flat 5k ticks actiavtion
• 10k ticks activation that can be sped-up

rebuilding node would require more logic than just "pop enough defenders"

because defender needs to both defend the cSite but also ship working creeps and energy

[minor reef]

If you can speed up, then in most strategically important cases it will be sped up to 1 tick

Just a pack of boosted creeps that complete everything instantly

[true shuttle]

30W T3 creep build 300/t

so it would require breaking siege 1st and prevent spawning defenders for ~150ticks

[undone whale]

The reason why I suggest that is because we have two use-cases and the ideal balance for one would make for poor balance for the other.

One situation is where a player or alliance wants to isolate networks and no one opposes them. At that point, they are just fighting the game, and they have to patrol the entire border within the activation time period. In order to not be frustrating to them, the activation time should be long. Probably longer than a creep lifetime at least, but the longer it is, the more convenient. Maybe sometime like the length of a safemode.

However, if that period of time is that long, it creates an undue burden on anyone trying to reconnect networks in a siege. I think that it should be feasible for them to fight for it and be able to reconnect it. If the period was 20k ticks then it would require them to camp that room with defenders for the whole time and an attacker could stop it by coming in with a stronger force at any time during that 20k ticks. So it's imbalanced in the attacker's favor by too wide of a margin, IMO.

We could maybe make the construction cost high, like 500k or something, and the passive gain an average of 25 per tick so that someone being active about it can speed up the process, but at siginificant cost.

[minor reef]

As an attacker, you have to keep many nodes down. As a defender, you just need to activate one node. Clearly, the balance here should be in the attacker's favor.

Also, patrolling should be predictable. You don't know plans of the defender. If the activation period can be affected, it's very hard to predict the opponent's actions. When the activation period is always the same, it's even ground - you fight during this period, and then it's over.

[true shuttle]

effectively, as an attacker you just have to keep nodes next to attacked room down

[minor reef]

Yes, at least 4 of them, or more if you attack a cluster of rooms

[true shuttle]

and in theory, if attacker has quads sieging in target room, target room hardly can spawn a set of builders and safely transport and defend both them and the c-site

[minor reef]

As a defender, you just choose one room at your convenience and direct all your efforts there

In many cases the defender will have many connected rooms within the isolated network, not just one

[undone whale]

I don't think either of those is necessarily true.

As an attacker, you have to keep many nodes down.

The attacker could attack as few as four room to cut off the network from a room. That's not a huge number.

As a defender, you just need to activate one node.

The attacker could choose to cut off additional nodes. They could make a wider perimeter to begin with, or they could scout the defender trying to guard a node and then cut off the nodes that would connect that one to the network.

[true shuttle]

hum, i still like the added complexity and risk that speed-up introduces.
so given a single T3 30W building for 300 progress make the progress be 900k ?
thats about 3k ticks for a single one, quite significant cost in creeps, boost and energy to do fast

[minor reef]

Any real world examples maybe?

[true shuttle]

it could be paired with 6k activation, so no progress by itself, but when activation reaches 0, node c-site is automatically built

[undone whale]

Ultimately, the goal is to nerf terminals, so to some extent it makes sense to make it unfeasible to reconnect the network to a room under siege. But I think it would be more interesting if it were feasible to some extent. If the balance swings too far in favor of either side, then fights over that objective will never be fought if people follow the meta because it's predetermined who wins.

Camping a room for an extended period of time is an imbalanced fight against the camping player, because they have to pay multiple creep lifetimes of a certain combat power and their opponent only has to pay for one lifetime of a slightly high power to interrupt their camp. If we go with my example of 20k ticks, then the cost to camp is something like 13x higher than the cost to disrupt it would be. If the balance was something like that, it would probably be meta to never try to fight for node connections.

Fighting over getting hauler creeps in could be interesting as well, to be fair. In that case it's the sieging player who must camp and be vulnerable to disruption. So, even though it is more expensive for the defender, it would probably be the way to do it.

[true shuttle]

you also need to prevent c-site stomping

[minor reef]

I think if there is any option to speed up activation, the entire sieging idea will simply fail to take off. It's just too hard for most attackers to properly implement. You just miss one node, and boom, the entire campaign has been jeopardized, because it's enough for the defender to recover connection for a few ticks to get all supplies needed to continue for a long time. Even if you destroy the node in 50 ticks after that, it's not important anymore.

In order for the sieging idea to work, there has to be a realistic way for an attacker to permanently block all nodes around a cluster of rooms without interruption. And this should be an accessible mechanic for most players, even with mediocre code.

I think, the attacker's advantage (in this particular case) should be so big, that the new meta sounds like this: in a war situation, one must never rely on external supplies. You can only rely on secured paths within your cluster or with standing army. Any external connection is extremely fragile and can easily be interrupted, even by a small force or with simple code. External connections are only feasible during peace time.

[true shuttle]

if that's the intent 👍🏼
for the activation i'd say 1-2k ticks and around ~10-15k hits

• enough time for both parties to spawn combat creeps and have them reach the room/position
• enough hits so it's not a one-shot by quad / single T3 creep but still fragile enough that defender has to be active
  (i assume that it's possible to repair the node ?)

[silver ocean]

The position of nodes is worth thinking about. May i suggest placing them like controllers so they dont get in the way of base building.

[silver ocean]

Ah ignore me i see you already mentioned this sorry

[true shuttle]

also would the node be in "permanent" place or would it move around afterdestruction ?

[silver ocean]

Would hope permanent, moving it around could really screw up basebuilding

[true shuttle]

wasn't it to be like a source/controller (in wall with acces by creeps) ?

because if it's permanent, it can put some rooms at permanent adventage/disadvantage (which can be a feature also)

[undone whale]

That's reasonable. It still leaves the option of haulers for resupplying sieged bases.

[night bronze]

Maybe for speed up, do a "reduce time by 10%" thing?
It would mean that you can speed up the progress by 1 tick if you use it at 10 ticks, but 500 ticks if you do it when it spawns (and the timer would be 5000).
Numbers pulled out of some dark place, feel free to suggest better ones.

[silver ocean]

Ok moving conversation from world-talk to here. Should nodes connect only where there are room exits? Without doing this some rooms become extremely difficult to siege. With doing this some rooms could become trivial to seige.

[minor reef]

Exits are not respected. Terminals beam resources over the air rather than physically move then. If exists were respected, it would complicate things too much both for the system and the player who wants to check why this particular network path is broken.

If you can't siege one room, you can siege a cluster of rooms with more accessible perimeter.