Redstone as a resource

[TeamDman]

People want redstone support, and apparently comparators aren't enough to sate their appetites.

New resource types

sfm:redstone:minecraft:redstone
shortenable to
redstone::

future opportunities:

sfm:redstone:red_power:blue idk

Precident:

sfm:forge_energy:forge:energy

Alternative consideration

Unit type for numeric systems with no alternative variants?

There are many items, but only one type of minecraft redstone/botania mana, etc.

sfm:unit:minecraft:redstone
sfm:unit:common:energy
sfm:unit:botania:mana
sfm:unit:ars:source

Outcome: rejected.

Too easy to conflate the things and make scripts that don't make sense.

INPUT unit:: FROM a
OUTPUT unit:: TO b

This doesn't really make sense, so the types should remain separate, even if it means resource types with only one variant.

New blocks

SFM redstone buffer

A block that holds 0..=MAX_LONG redstone units.

This is a more specialized version of a generic "sfm buffer" which I want to add which would be able to hold all resource types within a single block, which is beyond the scope of the redstone proposal.

The sfm:redstone_buffer block emits a redstone signal equal to its contained sfm:redstone:minecraft:redstone amount, clamped to 14.

Alternative modes such as "emit percentage full scaled to 0..=14" would be desirable.

Proposed Demos

NAME "demo 1"
EVERY 20 TICKS DO
  INPUT redstone:: FROM a -- where 'a' is a redstone block
  OUTPUT 10 redstone:: TO b -- where 'b' is the proposed sfm:redstone_buffer block
END

• Inputting redstone:: from a redstone dust, torch, or block creates redstone units equal to the signal strength without mutating the block
• Outputting redstone:: to a redstone block voids the redstone units

NAME "demo 2 - decrementing redstone counter"
EVERY redstone:: CHANGE IN a DO -- where 'a' is the proposed sfm:redstone_buffer block
  INPUT 1 redstone:: FROM a
  OUTPUT 1 redstone:: TO void -- where 'void' is a labelled minecraft:redstone_block
END

• Reactive programming, the sfm:redstone_buffer block would be able to trigger a manager program
• Re-entry locks would be necessary to prevent infinite loops, configurable
  • "A manager can only tick ${config.max_ticks_per_tick} times per tick."
  • Time acceleration conflicts, we can probably differentiate between time-in-a-bottle vs SFM re-triggering itself