Skip to content

UDP Hardware Manager - #783

Open
millibyte-products wants to merge 289 commits into
buttplugio:devfrom
millibyte-products:millibyte-udp
Open

UDP Hardware Manager#783
millibyte-products wants to merge 289 commits into
buttplugio:devfrom
millibyte-products:millibyte-udp

Conversation

@millibyte-products

Copy link
Copy Markdown

Adds udp sockets as a transport/hardware manager.

Supports TMax OSR2, SR6, SSR1.
Configurable in json (address & port setting)

qdot added 30 commits May 3, 2025 11:26
They're only partially legacy since we carry the features in there too
This conversion originally happened in the actuator command manager, but
was moved to message conversion. A fix happened to make sure that we
heed the step limit versus the range in the v3 line ACM, and needed to
be ported into this conversion to make sure the test still passes.
Rebasing after a 3 month hiatus. Note that many protocols will fail test runs.
ValueCmd and ValueWithParameterCmd should only take one value at a time.
This means that we need to have the server break v1-v3 message with
subcommands into multiple messages, parse those, then only return one
succeed/fail status. This is done in the Xray/Check system in the server
via making a new Checked*Vec type that just holds a vector of
CheckedValue messages.
Remove the idea of subcommands from the library, simplifying the
frontend APIs but requiring us to do timing and batching management
in the server (which is fine)
Batch commands together instead of requiring users to know what
needs to come in a packet. This requires adding feature UUIDs to each
hardware command so we can know what to overwrite.
Used for comparisons in tests. These should use uuids, but it'll
take a while to get all that in.
@CLAassistant

CLAassistant commented Sep 3, 2025

Copy link
Copy Markdown

CLA assistant check
All committers have signed the CLA.

@qdot

qdot commented Sep 7, 2025

Copy link
Copy Markdown
Member

Ok, so, first off, don't worry about resolving the conflicts here for now. We're still in a massive amount of flux around getting the new library version done so you'll be doing useless work on conflict resolution until things get stablized.

I... haven't quite figured out if/how I'm bringing this in yet, mainly because we've got so many variables in flight already and this is gonna be a DCM used by a small subset of people. I'm not saying I'm kicking it out yet either. Just trying to maintain my workload/sanity for the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants