This repo houses are pure .Net version of the Buttplug C# Client, runnings the Version 3 Buttplug Spec. It is expected to run against either Intiface Central (GUI) or Initface Engine (CLI). No Rust FFI bindings are required.

What happened? Why is buttplug-csharp back?

For those of you that have been around a while, you may remember that this used to be the main C# implementation. From 2017 to 2020, it was the reference version of the Buttplug Intimate Haptics Control Standard.

Then I rewrote everything in Rust because I like Rust more and it's far easier for me to port across platforms. This repo was archived ~2 years ago in preference to seating the C# client and server on top of the Rust implementation of Buttplug, as part of the Rust FFI Project.

That project ended up being a partial failure.

While the FFI system is handy for languages where it is very difficult to rebuild some parts of the library (C/C++/Java/etc...), for managed langauges like Javascript and C#, requiring both the client and server to use the FFI was overkill, and caused many extremely difficult-to-debug issues. With that in mind, the C# implementation is being turned into a Client only, .Net native implementation that should run on all platforms.

The embedded server/connector is no longer built for C#. It's too difficult for me to keep the package up for all of the needed architectures, and debugging it was hell. For now, I'm recommending developers point their users at Intiface Central as a hub application. If you have a reason for needing an embedded server in C#, leave an issue on this repo and we can discuss.

Documentation and Examples

API Documentation is available at [https://buttplug-csharp.docs.buttplug.io].

C# Usage Examples are available in the Buttplug Developer Guide, with source code and VS projects in the Dev Guide Repo.

Didn't ManagedButtplugIo already do this?

ManagedButtplugIo is a community produced, .Net native version of the Buttplug C# API, modeled off the FFI (which itself was modeled off of the original C# API). It's been helping the community along while the C# FFI implementation went off a cliff.

They did a very good job and I'm very appreicative of it (and I've used it in some of my own projects)!

The main reason I'm still keeping up my own C# client is that this is a big part of a LOT of the systems I maintain, like the Unity plugin. As part of how I fund this project is consulting on those, I need an implementation I'm responsible for. That said, this doesn't have to be the only implementation, and I'll still be keeping all imeplementations listed both in this README and on our Awesome List

Nuget and Packages

In order to reduce the amount of required dependencies, Buttplug is currently split into 3 Nuget packages.

• Buttplug - The Client Implemenation. Only dependency is NewtonsonJSON and Microsoft.CSharp 4.7
• Buttplug.Client.Connectors.WebsocketConnector
  • A Websocket connector built in top of WebsocketListener. While a websocket implementation is very much needed to use the client libraries, This is kept as a seperate dependency in case developers want to use a connector built on top of another Websocket library that may work better with or is already integrated in their setup (Like WebsocketSharp).
• Buttplug.Util.WebsocketDevice (Not yet available) - This is a test package that allows simulation of devices via the Buttplug Websocket Device Manager. More info about this can be found in The Buttplug Developer Guide.

Contributing

If you have issues or feature requests, please feel free to file an issue on this repo.

We are not looking for code contributions or pull requests at this time, and will not accept pull requests that do not have a matching issue where the matter was previously discussed. Pull requests should only be submitted after talking to qdot via issues on this repo (or on discourse or discord if you would like to stay anonymous and out of recorded info on the repo) before submitting PRs. Random PRs without matching issues and discussion are likely to be closed without merging. and receiving approval to develop code based on an issue. Any random or non-issue pull requests will most likely be closed without merging.

If you'd like to contribute in a non-technical way, we need money to keep up with supporting the latest and greatest hardware. We have multiple ways to donate!

• Patreon
• Github Sponsors
• Ko-Fi

License

This project is BSD 3-Clause licensed.