Would an XInput/gamepad output controller be welcome in DOF? #26

Hi,

before I write a pull request I would rather ask whether this is something you
want in DOF at all.

Some context first: I briefly opened PR #25 on 30 August and closed it again
within minutes. I had put it up before it was ready, and before asking whether
you want this in DOF in the first place. Doing it the other way round now.

What it is

An output controller that drives the rumble motors of an XInput gamepad instead
of physical hardware. It derives from OutputControllerFlexCompleteBase and
behaves like any other controller: outputs are assigned in the cabinet config,
and the existing config database decides what fires when. For people playing on
a desktop without a cabinet, it turns shaker, knocker, gear motors, slingshots
and bumpers into something they can actually feel.

I have been running it for a while now on a fairly large table collection, and
it works well enough that I would like to offer it back rather than keep it in
a fork.

The one design question I would like to settle first

Some toys follow the raw solenoid state and stay on for as long as the mechanism
runs. The train in Cactus Canyon is the clearest example. On a real cabinet that
is correct - the motor is supposed to run. On a gamepad, a motor at full power
for fifteen seconds is unbearable, and it also masks every other effect while it
lasts.

My current controller solves this itself: anything held longer than a
configurable time fades towards a configurable level, while short hits are never
touched. With the fade level at 0, a starting motor gives one clear kick and then
goes quiet.

That behaviour is not something other controllers do, and I am genuinely unsure
where it belongs:

1. inside the controller, as it is now (simple, but a controller doing effect
   work),
2. as a proper effect in the effect chain, so any controller could use it,
3. or not in DOF at all, and left to the config.

I would rather hear your view on this before building the wrong thing. If you
think option 2 is right, that changes the shape of the contribution
considerably.

Two smaller questions

• Per-output weighting. The controller currently accepts a list like
  3=50,19=0 to scale or silence individual ports, because the port numbering
  means the same thing on every table. Is that acceptable in a controller, or
  would you rather see it solved elsewhere?
• Cross-platform. XInput is Windows only. Since libdof is built for six
  platforms, would you prefer this to be Windows-guarded, or built on something
  portable such as SDL from the start? I ask here because a later libdof port
  should be a faithful 1:1 port of whatever lands in the C# code.

Disclosure

I want to be straight about how this was built, because your contributing
guidelines ask for exactly that.

I am not a C# developer. My background is web development and scripting
(AutoIt), and it is a good few years behind me. This controller was written
with AI assistance, under my direction. I would be overpromising if I told you
I could defend every line of it.

What I can vouch for:

• every behavioural decision in it is mine, and I can explain the reasoning
  behind each one
• it has been tested by hand over weeks, across a large table collection, on
  real hardware - that part is genuinely thorough, and it is how the
  sustained-motor problem above was found in the first place

Your guidelines say that where a contributor does not fully understand a piece
of code, they should test it rigorously and disclose it. That is precisely
where I am, so I am disclosing it now rather than in a pull request footnote.

If that means this is better treated as a starting point for someone who knows
the codebase, rather than as a finished contribution, I am entirely fine with
that. I would rather it land in good shape than carry my name.

Thanks for maintaining DOF. The config database is what makes any of this
possible in the first place.