Deceleration card

[HaphLife]

Describe the feature

A card that when put in interfaces, import busses, export busses, and ME I/O ports, causes the device it's in to decelerate upon failure, compared to the acceleration card's acceleration on success. This can be implemented as an exponential backoff function.

An example delay function could be:
D*min(2^(F/N),2^M)
Where:
D = default delay of the machine
F = failure counter
N = backoff frequency
M = backoff upper bound

For example, let's consider an interface with a stack of cobblestone in it, attempting to push that cobblestone into a full network. The interface would attempt to store the cobble every tick and fail every tick. With 1 deceleration card it would attempt some number N times (ex: 8), then double the wait time to 2 ticks. After each additional N failures, it would double the delay up to some bound 2^M (ex: 4).

Additional deceleration cards into a machine would decrease the value of N and increase the value of M (ex: two cards could have N=4, M=8, three N=2, M=12, etc.) this allows for a more aggressive backoff, while also not taking forever to speed back up.

Ideally, this would be implemented for the interface on a per-slot basis, so that one item type stuck in the interface (or unavailable in the network) doesn't slow other items throughput. I don't think that import/export busses would be well suited to that, however so different filters shouldn't have distinct backoffs. ME I/O ports are here mostly as a "why not" option, so idk whether backoff by type makes sense.

For the import/export busses, acceleration cards shouldn't start to accelerate the bus while it is backed off, that way they can be used together for a bus in a network where speeds shift above and below the default speed. One could implement both types as part of the same function where the accel/decel cards control the lower and upper bounds respectively, but if accel cards are currently implemented differently, changing them might annoy some players.

Reasons why it should be considered

This is a great way to allow players to reduce the lag of various components, especially on large networks.

In contexts where blocks (especially interfaces) are repeatedly attempting to pull or push items or fluids, and the network state doesn't change at all, a lot of CPU time is wasted calculating nothing.

While, yes, good subnetting practice will always save on lag, many network architectures simply necessarily involve a lot of busses, interfaces, and/or storage points, and providing an option to reduce lag in parts of a network that are "waiting for resources to arrive" or "waiting for storage to clear" would be much appreciated.

Additional details

I used powers of two for the backoff frequency, because then you can implement the division as bit-shift (or let your compiler do that for you).
Also, the caps could be calculated at compile time, I just find it easier to think of the cards exponentially increasing the cap with a function to express that, the machine doesn't need to actually calculate that all the time.

From a gameplay balance perspective, the deceleration cards should probably be pretty cheap, to encourage players to use them (unlike acceleration cards, which have a strong intrinsic draw)