Buttplug C# v0.2.0 and Buttplug JS v0.5.0 Released!


#1

Buttplug C# 0.2.0 Updates

Features

  • Added Hardware Support
    • Youcups Warrior II Masturbator
    • Erostek ET312B
    • Wevibe 4
    • OhMiBod/Kiiroo Fuse
    • Lovense Edge/Hush/Domi (new firmware versions)
    • Individual Vibrator support for Lovense Edge
  • Now uses v1 of the Buttplug Protocol spec, adds new generic messages, as well as feature counts for device messages
  • Supports message downgrading, meaning older clients can connect to newer servers
    • Newer clients cannot connect to older servers, though
  • Moved code to .Net Standard 2.0 compatibility
  • Moved testing to NUnit

Bugfixes

  • Game Router process select button disabled until process selected
  • Fix SynchronizationContext crash in client

Buttplug JS v0.5.0 Updates

https://www.npmjs.com/package/buttplug

  • Added Buttplug Spec v1 implementation
    • More generic message types (VibrateCmd, RotateCmd, LinearCmd)
    • Message attributes (device feature counts)
    • Message downgrading capabilities
  • Added tests. So many tests.
  • Divided devtools into core and web directories
  • Updated devtools to depend on buttplug as an external library (makes file sizes smaller)
  • Library now uses es6 by default
  • Lots of bug fixes due to aforementioned tests (Wevibe control issues, missing error message, etc…)

#2

Hi, running the example code from the Readme in the buttplug-js repo to start the server returns an error. That error is correct because the ButtplugNodeWebsocketServer class is never exported and thus not available to instantiate.

Error:

 var server = new Buttplug.ButtplugNodeWebsocketServer();
                 ^
    TypeError: Buttplug.ButtplugNodeWebsocketServer is not a constructor

#3

… Whoops.

Expect 0.5.1 out this evening. With native node tests this time. :expressionless:


#4

Ok, so, the reason this wasn’t exported is that I mistakenly thought that I could have entry point relative includes. i.e. my entry point right now is “dist/main/src/index.js”, so I was hoping I could have developers do something like require(“buttplug/node”) whenever they specifically wanted to bring in node websocket libraries, which are in dist/main/src/node/index.js. Having read up on that now, I realize the only way to do “multi-module” npm packages is to pollute root, which is gross as hell and also means I have to be super careful about how I name things, but looks like it may be my only solution.

The reason I was avoiding exporting the src/node directory in the entry point is that it’s not needed for web stuff, and causes webpack to throw errors if you don’t ignore the library (and having webpack/rollup specific blocks people have to include to use the module sucks). I’m also doing this with the devtools. I didn’t actually test modules post-build though, so that’s why this happened.

I’m gonna poke at some solutions for this, but for now, you can bring in the node libraries with require(“buttplug/dist/main/src/node/”). That really sucks though. :frowning:


#5

Welp. Thanks to a combination of typescript REALLY needing to keep an out-of-source build directory and node not being real amiable to entry point relative includes, I’m gonna kick the node websocket classes back out to their own package. Luckily, that package already exists (I’d made this before trying the current “everything in one module” method):

https://www.npmjs.com/package/buttplug-node-websockets

I’ll be publishing buttplug-js v0.5.1, but it’ll just be buttplug-js v0.5.0 minus the node websockets stuff, so no real need to worry about updating.

What I wouldn’t fucking give for Rust Cargo style Features in npm. :frowning:


#6

Ok, buttplug-js 0.5.1 is out, same as 0.5.0, just no longer has the node stuff in it, so not real pressing to update that part. Cleaned up and wrote tests for buttplug-node-websocket, just pushed 0.0.2 of that now (https://www.npmjs.com/package/buttplug-node-websockets). Note that I’m having really weird issues with https servers stalling, even though they say they’re shut down (all tests exit). Still working on that. I tried debugging it to see what’s stuck in the node loop, but didn’t have much luck.


#7

Thanks for the quick replies and fix. Haven’t worked much with webpack to know why it gives your errors. It is possible though to remove unused imports and exports from your build using tree shaking in webpack. That way front-end devs creating a browser app can easily leave out the parts they don’t need in their final build.

Are you open to pull requests / help with the Javascript implementation? I’ve been going through the Typescript code to figure out how messages are composed and devices and clients communicate with the server. Not quite there yet in terms of understanding all of it but getting there :slight_smile:. I think I can help developing / maintaining the JS libraries. Will be native Javascript instead of Typescript though.


#8

Yeah, I figured tree shaking should take out the unused code, but that didn’t seem to be the case. Also, I foresee there being far fewer developers using the node websocket portion of the library than the web browser focused stuff, so I’m fine splitting those off into their own module anyways. Means I can update node dependencies without having to update the main library, with only minimal build work. I’ve got a small CLI interfaces for a native buttplug websocket server with bluetooth capabilities that I use for my own testing, I’ll be posting that soon, might be a good example of how I throw this stuff together.

I’m certainly open for pull requests and help, but patches will need to be in Typescript. I can’t split the code base between shaped-typing and unannotated JS, and the typing, while more implied instead of enforced, is important for me to be able to read and understand code flow quickly, especially with typescript’s nice union types. I write my examples in es6/es7 because I know a lot of users outside of the library will be using those (though Playground, Syncydink, and other applications I write are also TypeScript), but keeping the core library consistent is very important to me. That said, I’m happy to answer questions and offer advice, and TypeScript is a superset of JS, so if you’re familiar with es6/7, there may not be too much to learn on top of it.


#9

BTW, this does not imply that you have to write your own buttplug related modules in Typescript. That’s why I distribute the compiled files in the published modules. Those can be ES6/7 (I moved the libraries to compile to es6 with 0.5.0 so es5 is a no-go unless you want to babel it yourself), Elm, Dart, Purescript, or whatever else you want. I just want to keep the parts I maintain homogenous. :slight_smile: