Giter Club home page Giter Club logo

buttplug-lite's Introduction

Buttplug Lite

This application serves a websocket that runs a dramatically simplified version of the Buttplug Sex Device Control Standard protocol. This allows commands to be sent to devices with significantly less programming, making integration feasible in more restricted environments where the buttplug.io protocol is difficult or impossible to implement.

Installation and Usage

  1. Download the latest release.
  2. Run buttplug-lite-windows.exe (or your operating system's appropriate binary if you aren't on Windows. Builds are also provided for macOS and Linux.)
  3. Add tags for the devices you plan to use.
  4. Press "apply configuration" to save your settings and apply them to the current server.

Features

  • Extremely simple fire-and-forget protocol
  • Standalone application requiring no other software

screenshot of GUI

Supported Devices

All buttplug.io supported devices should work. This includes everything from Lovense devices to Xbox controllers.

Building from Source

  1. Install Rust
  2. Clone the project
  3. cargo build --release

Integrations

Neos VR

A Logix reference implementation is available in this public folder:
neosrec:///U-runtime/R-1d65fb20-ab7b-46c1-89eb-90d176309ec2 (paste that link in-game to spawn it).

Below is a screenshot of the reference implementation.

screenshot of reference implementation

This implementation is designed to go on an avatar. The avatar/user input should contain the user currently in the avatar. This could be sourced from an AvatarUserReferenceAssigner or a Get Active User. The top half of the Logix handles resetting the websocket connection when a new user enters the avatar, and can be omitted if the avatar will only ever be used by one user. The lower half of the logix sends updates to the buttplug-lite server at around 7 Hz. If you go too far beyond 7 Hz you may start to run into latency issues. The two float inputs should be between zero and one (inclusive) and represent the desired motor intensity. You could source this from any number of places, such as Nearest User Hand, VirtualHapticPointSampler, or even a simple UI slider.

Manual

Sending Commands

Send text-type messages to ws://127.0.0.1:3031/haptic. Binary-type messages are not currently supported. Commands should be sent at most at a 10hz rate. Beyond that application performance may begin to degrade.

Message Format

The message format is a list of semicolon (;) delimited motor commands. There are three possible types of command: Scalar, Linear, and Rotation. All commands start with a motor tag, which is a user-defined string representing a specific motor on a specific device.

Scalar

tag:strength

Strength controls motor intensity and ranges from 0.0 to 1.0.

Linear

tag:duration:position

Position controls target position and ranges from 0.0 to 1.0.
Duration controls time in milliseconds the device should take to move to the target position. Duration must be a positive integer.

Rotation

tag:speed

Speed controls the speed of rotation and ranges from -1.0 to 1.0. Positive numbers are clockwise, negative numbers are counterclockwise.

Contraction (Deprecated)

tag:level

Only supported in versions 0.5.3 to 1.1.0. Starting in version 2, contraction is handled via a scalar command.

Contraction controls the pump strength on the Lovense Max. It must be an integer between 0 and 3, inclusive.

An Example Command

Tag Type Strength Duration Position Speed Contraction
foo Scalar 0%
bar Scalar 30%
baz Scalar 100%
gort Linear 20ms 25%
klaatu Linear 400ms 75%
barada Rotation -0.75
nikto Rotation 0.26
foo:0;bar:0.3;baz:1;gort:20:0.25;klaatu:400:0.75;barada:-0.75;nikto:0.26

Note that you are not required to specify all the tagged motors if you don't want to. The following is also valid, but will of course only drive the foo motor.

foo:0.1

Motor State

Motors will continue running at the vibration and rotation speeds last commanded until another update is received.

If no command is received for 10 seconds, buttplug-lite will send a stop command to all connected devices. To avoid this, send commands periodically even if your desired motor state has not changed.

Checking the Application Version

Send an HTTP GET to http://127.0.0.1:3031/. A 200 OK will be returned with body containing the application name and version. Example response:

buttplug-lite 0.7.0

Prior to version 0.7.0 this endpoint is a 404.

Checking the Configuration

Send an HTTP GET to http://127.0.0.1:3031/deviceconfig. A 200 OK will be returned with body containing a machine-readable list of configured motors. Example response:

o;Lovense Edge;scalar
c;Lovense Max;scalar
i;Lovense Edge;scalar
m;Lovense Max;scalar

The response is a newline (LF) delimited list of motor configurations. There is a trailing newline. Each motor configuration line is a semicolon (;) delimited list of tag, device name, and motor type. In the case where there are no configured motors the response body will be an empty string.

Possible motors types are: linear, rotation, and scalar.

Prior to version 0.7.0 this endpoint is a 404.

Checking the Status

Send an HTTP GET to http://127.0.0.1:3031/hapticstatus. A 200 OK will be returned with body containing a plain text summary of the connection status and connected devices. This response is intended for debugging and is not intended to be parsed. The response structure is subject to change. If you have a use case that requires parsing device status let me know by opening an issue.

Example response:

device server running=true
  Lovense Edge
    ScalarCmd: ClientGenericDeviceMessageAttributes { feature_descriptor: "No description available for feature", _actuator_type: Vibrate, step_count: 20 }
    ScalarCmd: ClientGenericDeviceMessageAttributes { feature_descriptor: "No description available for feature", _actuator_type: Vibrate, step_count: 20 }
  Lovense Hush
    ScalarCmd: ClientGenericDeviceMessageAttributes { feature_descriptor: "No description available for feature", _actuator_type: Vibrate, step_count: 20 }
  Lovense Max
    ScalarCmd: ClientGenericDeviceMessageAttributes { feature_descriptor: "Vibrator", _actuator_type: Vibrate, step_count: 20 }
    ScalarCmd: ClientGenericDeviceMessageAttributes { feature_descriptor: "Air Pump", _actuator_type: Constrict, step_count: 5 }
  The Handy
    LinearCmd: ClientGenericDeviceMessageAttributes { feature_descriptor: "No description available for feature", _actuator_type: Position, step_count: 100 }

Checking Battery

Send an HTTP GET to http://127.0.0.1:3031/batterystatus. A 200 OK will be returned with body containing a plain text list of devices and battery levels. Devices are delimited by newlines, battery levels are delimited by :. If the device has an unknown battery level a -1 will be returned. Example:

Lovense Edge:1
Lovense Max:0.45

Command-Line Arguments

buttplug-lite is intended to be used as a GUI, but for debugging purposes a few command-line arguments are included.

Usage: buttplug-lite [OPTIONS]

Options:
  -v, --verbose...               Sets the level of verbosity. Repeating this argument up to four times will apply increasingly verbose log_filter presets
  -c, --stdout                   Log to stdout instead of the default log file
  -f, --log-filter <LOG_FILTER>  Custom logging filter: https://docs.rs/tracing-subscriber/0.3.16/tracing_subscriber/filter/struct.EnvFilter.html. This completely overrides the `--verbose` setting
      --debug-ticks <SECONDS>    Emit periodic ApplicationStatusEvent ticks every <SECONDS> seconds. These "ticks" force the UI to update device state, which for example can be used to poll device battery levels
      --no-panic-handler         Disables the custom panic handler in the log file. Has no effect if used with `--stdout`
      --force-panic-handler      Enables the custom panic handler in stdout logs. Has no effect if file logging is used. Note that file logging is the default without an explicit `--stdout`
  -h, --help                     Print help
  -V, --version                  Print version

Files

Here is where buttplug lite stores its various files on your filesystem:

Windows macOS *nix
Configuration Directory %APPDATA%\runtime-shady-backroom\buttplug-lite\config $HOME/Library/Application Support/io.github.runtime-shady-backroom.buttplug-lite $XDG_CONFIG_HOME/buttplug-lite or $HOME/.config/buttplug-lite
Log Directory %APPDATA%\runtime-shady-backroom\buttplug-lite\data\logs $HOME/Library/Application Support/io.github.runtime-shady-backroom.buttplug-lite/logs $XDG_DATA_HOME/buttplug-lite/logs or $HOME/.local/share/buttplug-lite/logs

Note that once a maximum of 50 log files are reached, old logs will be rotated out.

Feedback

If you have bugs to report or ideas to suggest please let me know by opening an issue or starting a discussion.

License

Copyright 2022-2023 runtime-shady-backroom and buttplug-lite contributors.

Buttplug Lite is provided under the AGPL-3.0 license.

buttplug-lite's People

Contributors

dependabot[bot] avatar jeanahelver avatar runtime-shady-backroom avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

buttplug-lite's Issues

Suggest rebuild to support Buttplug.io 7.1.16 due to Solace bug

Describe the bug
The Solace will not stop running unless the build is updated to 7.1.16, even if it's given a value of 0.0. See buttplugio/buttplug@d146969

To Reproduce

  • Connect a Lovense Solace, send a value of 0.0, it will start moving.

Expected behavior
The Solace should stop given a zero value

Screenshots
N/A

Desktop (please complete the following information):
All

Additional context
I suggest merging #154

Windows Security labels as Trojan with 2.4.0 .exe

Describe the bug
Windows Security labels the program as very dangerous and labels it a Trojan Wacatac.B!ml

To Reproduce
Steps to reproduce the behavior:

  1. Download latest .exe for windows
  2. Fin

Expected behavior
Previous .exe's have not triggered this response, version 2.0.1 works with no trojan alert.

Desktop (please complete the following information):

  • OS: Windows 11
  • Version 22H2

Crash on macos (m1)

Describe the bug
Crash on startup.

To Reproduce
cargo run will crash.

Additional context
Trying to debugging this to no avail. This is kind of head-scratcher. Let me know if there's something you want me to try or code to write.

Older versions (for example git ref 5d9485885f0a6bb0e0a6c710e99e2937f3af0dcc) will run inside lldb, but cargo run and target/debug/buttplug-lite will always crash.

Currently, checkout from master and cargo run will crash and running it inside lldb will crash. I've been trying to figure it out on my own, but figured i submit a bug in case its something you had seen before.

Running in side lldb

(lldb) target create "target/debug/buttplug-lite"
Current executable set to '/Users/gibberton/source/rust/buttplug-lite/target/debug/buttplug-lite' (arm64).
(lldb) r -c -v
Process 38639 launched: '/Users/gibberton/source/rust/buttplug-lite/target/debug/buttplug-lite' (arm64)
2023-06-11T15:36:07.021174Z  INFO buttplug_lite: initializing buttplug-lite 2.4.1
2023-06-11T15:36:07.035749Z  INFO buttplug::server: Buttplug Server Operating System Info: Mac OS 13.4.0 [64-bit]
2023-06-11T15:36:07.035819Z  INFO buttplug::util::device_configuration: Loading from custom base device configuration...
2023-06-11T15:36:07.072459Z  INFO buttplug::util::device_configuration: No user configuration given.
2023-06-11T15:36:07.074377Z  INFO buttplug::server::device::server_device_manager: BtlePlugCommunicationManager: false
2023-06-11T15:36:07.074388Z  INFO buttplug::server::device::server_device_manager: SerialPortCommunicationManager: true
2023-06-11T15:36:07.074394Z  INFO buttplug::server::device::server_device_manager: LovenseHIDDongleCommunicationManager: false
2023-06-11T15:36:07.074399Z  INFO buttplug::server::device::server_device_manager: LovenseSerialDongleCommunicationManager: false
2023-06-11T15:36:07.074404Z  INFO buttplug::server::device::server_device_manager: LovenseServiceDeviceCommManager: true
2023-06-11T15:36:07.074440Z  INFO Lovense HID Dongle State Machine: buttplug::server::device::hardware::communication::lovense_dongle::lovense_dongle_state_machine: Running wait for dongle step
2023-06-11T15:36:07.074483Z  INFO Lovense Serial Dongle State Machine: buttplug::server::device::hardware::communication::lovense_dongle::lovense_dongle_state_machine: Running wait for dongle step
2023-06-11T15:36:07.074485Z  INFO buttplug::client: Connecting to server.
2023-06-11T15:36:07.074526Z  INFO buttplug::client: Connection to server succeeded.
2023-06-11T15:36:07.074562Z  INFO buttplug::client: Running handshake with server.
2023-06-11T15:36:07.074586Z  INFO InProcessClientConnectorEventSenderLoop: buttplug::core::connector::in_process_connector: Starting In Process Client Connector Event Sender Loop
2023-06-11T15:36:07.074637Z  INFO Client Loop Span: buttplug::server: Performing server handshake check with client in-process-client at message version Version3.
2023-06-11T15:36:07.074720Z  INFO buttplug::client: Connected to buttplug-lite
2023-06-11T15:36:07.074794Z  INFO buttplug_lite::app::buttplug::startup: buttplug_server: Device server started!
2023-06-11T15:36:07.074847Z  INFO buttplug_lite::app::buttplug::startup: buttplug_server: starting device scan
2023-06-11T15:36:07.074961Z  INFO buttplug_lite::config::util: Attempting to load config from "/Users/gibberton/Library/Application Support/io.github.runtime-shady-backroom.buttplug-lite/config.toml"
2023-06-11T15:36:07.074993Z  WARN buttplug_lite::config::util: falling back to default config due to error: Os { code: 2, kind: NotFound, message: "No such file or directory" }
2023-06-11T15:36:07.075003Z  INFO buttplug_lite::config::util: Loaded configuration v3 from disk
2023-06-11T15:36:07.075158Z  INFO buttplug_lite::app::webserver::routes: starting web server on 127.0.0.1:3031
2023-06-11T15:36:07.075216Z  WARN Lovense Serial Dongle Finder: buttplug::server::device::hardware::communication::lovense_dongle::lovense_serial_dongle_comm_manager: Cannot find Lovense Serial dongle.
2023-06-11T15:36:07.087032Z  WARN Lovense HID Dongle Finder Task: buttplug::server::device::hardware::communication::lovense_dongle::lovense_hid_dongle_comm_manager: Cannot find lovense HID dongle.
2023-06-11T15:36:07.509142Z ERROR buttplug_lite::util::panic: buttplug-lite v2.4.1 has crashed.
To help me diagnose this problem you can attach this log file to a new GitHub issue at https://github.com/runtime-shady-backroom/buttplug-lite/issues
thread 'main' panicked at 'ASDF', /Users/gibberton/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.28/src/stream/stream/mod.rs:1243:9
Process 38639 exited with status = 101 (0x00000065)

wgpu: Validation Error

buttplug-lite is crashing on startup with the following error:

wgpu error: Validation Error

Caused by:
    In a RenderPass
      note: encoder = `<CommandBuffer-(0, 1, Vulkan)>`
    In a set_scissor_rect command
    Invalid ScissorRect parameters


thread 'main' panicked at 'Handling wgpu errors as fatal by default', C:\Users\michael\.cargo\registry\src\github.com-1ecc6299db9ec823\wgpu-0.7.0\src\backend\direct.rs:1896:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Running on Windows 10 19044.1889

Duplicate device support

Identically named devices are not currently supported. Without some sort of support for a unique device identifier from the buttplug-rs library, this will be functionally impossible to do in a way that remains consistent between application runs.

New version available notification

I can detect if a new version is available by hitting the github api. This could be displayed in-application as some sort of "โš  hey there's update" notification.

I don't know if this is something that people want.

Max 2 Config Migration to BPL 2.0.0

Just a quick question, I notived in the patch notes for version that

migrated, except for the Lovense Max, which you will need to reconfigure. Your old config will be backed up to backup_config_v2.toml, in the config directory.

How would one go about prepping or migrating the tags over? Ive tried just copy and pasting my Config settings from version 1.0.0 to the new config and the cmd line keeps giving me a prompt for

buttplug_server: Attempting to load config from "C:\Users\[Redacted]\AppData\Roaming\runtime-shady-backroom\buttplug-lite\config\config.toml"
falling back to default config due to error: Error { inner: ErrorInner { kind: Custom, line: Some(5), col: 15, at: Some(77), message: "invalid type: string "Vibration", expected internally tagged enum MotorTypeV3", key: ["tags", "1", "feature_type"] } }

Hopefully im just over looking one little thing in the config.

Configuration GET request

It would be nice if we could do a GET request for getting the config details of all the motors.
The Value's i would like to get per motor are:

  • Tag
  • Device name
  • Feature type (e.g. Vibration, Contraction, Rotation ...)

This would be similar to what is already stored in the config file in AppData

The formatting for it shouldn't matter too much but just something that would be nice to parse in Neos

Lovense Connect

It would be very nice if this could work with Lovense connect so multiple devices can work with it.

Connected vibrators no longer responding

Describe the bug
Vibrators connected to Buttplug Lite will display a solid status light and no longer respond to any command until disconnected from Buttplug Lite.

To Reproduce
Steps to reproduce the behavior:

  1. Start Buttplug Lite client
  2. Power on vibrator devices.
  3. Verify connected devices connect and show in Buttplug Lite client. (Tested Gush and Diamo)
  4. Observe status light change on Lovense devices from blinking to solid.
  5. Send commands via the appropriate websocket (3031, in this case)
  6. After no response from Lovense device, shutdown Buttplug Lite client.
  7. Device will resume blinking status light and properly connect to other clients (Intiface & Lovense App)

Expected behavior
Expect Buttplug Lite client to connect and control Lovense devices.

Screenshots
NA

Desktop (please complete the following information):

  • OS: Windows 10
  • Buttplug Lite Version: 2.4.1

Additional context
This worked fine only a few days ago, not sure if something changed in the windows bluetooth or the way websockets are run.
I usually use my devices via Resonite with a Vibe Panel (by Beaned) but even other panels and manual commands will no longer work.
The panel still receives the connected device info from Buttplug.io, so there is definitely some types of communication, just no command to the Lovense toys.

Rename the project

The program is now standalone and no longer proxies commands to intiface-desktop, so the name "intiface-proxy" is clearly no longer valid. I've tentatively renamed the project to "buttplug-lite" to better reflect what the program currently does. I'm not sold on the name yet, though.

Once a new name is decided upon I'll rename the repository itself. The current Github repository links will continue to work, and will redirect to the new repository.

Logging framework

Currently the logs go to stdout/stderr and nowhere else. A real logging framework that logs to disk is needed for error reporting.

Alternatively, logging to the GUI would be a nice easy way for people to see what's happening, and I can be lazy and do less GUI wok.

Rotation/Linear motor support

The current version of the program only supports vibration motors, but buttplug-rs supports rotation and linear motors as well. This will require additions to the protocol in order to implement, as these motors are more complex than vibration's single scalar value.

Binary Protocol

A secondary binary protocol can be implemented alongside the current text protocol. As websockets can distinguish between binary and text messages, this can be done as a non-breaking change.

API Plans?

Hey! buttplug.io author here.

I'm currently compiling a list of repos using the library (https://github.com/buttplugio/awesome-buttplug) and happen to run into this. Funny enough, I actually need something exactly like this for NeosVR support, as it's REALLY difficult to form JSON in their in-world language, so having a simpler string parsing system would be handy.

Just curious what your plans are for using the simplified interface? Would be happy to discuss here, or if you want to jump on our discord, it's at https://discord.buttplug.io

Also: Thanks for using the library! If you have any input please let me know, almost everyone uses the FFI so I'm always looking for feedback on the Rust ergonomics.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.