Joystick Button Groups

[ArchdukeTim]

A common pattern is to combine multiple joystick buttons to perform certain actions, while the individual buttons perform individual actions. For example, the 'a' and 'b' buttons could be used to perform 3 actions: one when just a is pressed, one when just b is pressed, and one when both are pressed.

Currently, the way to set this up is

a().and(b().negate())...
b().and(a().negate())...
a().and(b())...

This is a bit cumbersome. Also, the .negate() triggers are not cached the way the positive versions of the triggers are, so it can lead to duplicate trigger definitions depending on the size of the group

It would be nicer if there was syntax to allow

a()...
b()...
a().and(b())...

or some variation.

For example, assuming there was some class ButtonGroup that handled the logic:

ButtonGroup intakeActions;

intakeActions.only(a())
intakeActions.only(b())
intakeActions.all()...

perhaps a generic version (though I don't think generics would let there be different methods like this, at least not in java)

ButtonGroup<A, B> intakeActions;
intakeActions.a()...
intakeActions.b()...
intakeActions.both()...

[Ornamus]

My team almost wound up implementing something like this, it could be useful! It'd probably be better to call it something like TriggerGroup or TriggerCombo though since it doesn't need to be just for buttons.

[KangarooKoala]

Yeah, I agree that it should be named something like TriggerGroup. Another consideration is that we need a way to match the specified triggers with the stored triggers (so that we know the expected value of each Trigger). If we pass in the Trigger objects, that gets pretty hard unless we rely on caching to get reference equality, which feels brittle. Therefore, since we can't use the Trigger instances themselves to specify which ones should be true and which should be false, we need some other data to associate them with each other, like a String name.
Also, yes, you are correct that Java generics would allow conditional method definitions. C++ generics can sort of conditionally disable method definitions, but they'd still clog up doc comments and maybe intellisense, plus you'd need to define the entire set of possibly used methods anyways.

Here's a possible Java implementation:

public class TriggerGroup {
  public static TriggerGroup of(Map<String, BooleanSupplier> conditions) {
    return new TriggerGroup(conditions);
  }

  private final Map<String, BooleanSupplier> m_conditions;

  public TriggerGroup(Map<String, BooleanSupplier> conditions) {
    m_conditions = Map.copyOf(conditions);
  }

  public Trigger only(String... names) {
    return only(Set.of(names));
  }

  public Trigger only(Set<String> names) {
    for (var name : names) {
      if (!m_conditions.containsKey(name)) {
        throw new IllegalArgumentException("name " + name + " is not a registered name!");
      }
    }
    return new Trigger(() -> {
      for (var nameCondition : m_conditions) {
        boolean expectedValue = names.contains(nameCondition.getKey());
        boolean value = nameCondition.getValue().getAsBoolean();
        if (expectedValue != value) {
          return false;
        }
      }
      return true;
    });
  }

  // We could also define none(), any(), all(), allExcept(), etc.
}

// Example
var group = TriggerGroup.of(Map.of("A", controller.a(), "B", controller.b(), "X", controller.x()));
group.only("A").onTrue(...);
group.only("B").onTrue(...);
group.only("A", "B").onTrue(...);

If someone wants to make a PR for this, you'll need to add doc comments and tests, as well as either add a C++ implementation and tests or ask for someone else to do so.