... for the explorer at heart!
https://milovana.com/forum/
If you're looking for info/help on it, the XToys dev is pretty active on it's discord.fapnip wrote: Sat Jan 02, 2021 4:41 pmhttps://xtoys.app/, pointed out by notSafeForDev here, seemed like it could be a good option, but notSafeForDev appears to have dropped off the radar since.
Thanks. Unfortunately, not having any of the devices for testing makes it kinda difficult for me to do any development on it.RemiHiyama wrote: Fri Jan 08, 2021 5:20 pm If you're looking for info/help on it, the XToys dev is pretty active on it's discord.
Not so! The way Xtoys is set up, you can test almost any device 'virtually', you just add it to your dashboard and you can see what the effects of a script would be without actually connecting it to a physical device. This doesn't work for everything, but I think it'd handle everything you'd need from a testing standpoint.fapnip wrote: Sat Jan 09, 2021 5:09 pmThanks. Unfortunately, not having any of the devices for testing makes it kinda difficult for me to do any development on it.
Nice!RemiHiyama wrote: Sat Jan 09, 2021 5:50 pm Not so! The way Xtoys is set up, you can test almost any device 'virtually', you just add it to your dashboard and you can see what the effects of a script would be without actually connecting it to a physical device. This doesn't work for everything, but I think it'd handle everything you'd need from a testing standpoint.
Yes, it gets complicated quickly.RemiHiyama wrote: Sat Jan 09, 2021 5:50 pm That being said... if the goal is to have a generic api for this, there is a question of "what things do people want to be able to do?" There are things I'm not sure are possible without per-tease scripting at this point.
The concern with direct API calls is user privacy, but it would be the best way if possible to do without risking user's privacy. I would image an API key would need to be entered, and should never be exposed to the tease's sandbox. I suppose I could just store that in local/tease storage. (oeos can't currently store to Milovana's user account, and probably never will be able to -- but I did add the ability to download/upload tease storage files.)RemiHiyama wrote: Sat Jan 09, 2021 5:50 pm There's also two different possible approaches for communication between Xtoys and OEOS. The webhook approach (OES calls a url on the xtoys web server, it passes information to the logged-in user, and if they have a script running that responds to that command, stuff happens), and the webpage monitor approach (browser extension monitors webpage for nodes events, which can then do stuff). Webpage monitor only works in chrome AFAIK, so webhook would be better for overall compatibility, but I don't know if there are other issues.
Yeah, there is a place to generate a 'webhook id' that one hopes and presumes cannot be mapped back to the username. It certainly looks like gibberish, at any rate. And it's just a push of a button to get a new one. Mumble (the dev) could probably tell you more.fapnip wrote: Sat Jan 09, 2021 7:47 pm The concern with direct API calls is user privacy, but it would be the best way if possible to do without risking user's privacy. I would image an API key would need to be entered, and should never be exposed to the tease's sandbox.
I'd need to look at the API more to see how complex adding multiple toys would be. Do each have their own ID? Do I just query and get a list of all toys?RemiHiyama wrote: Sat Jan 09, 2021 9:07 pm -Supporting multiple vibrators that can be controlled independently. I don't know what the real limit is, but having support for a few wouldn't be hard and opens up possibilities. And if someone doesn't have or want to use everything, then it's no problem, they just don't attach anything to those outputs and they just do nothing.
I'd rather not encourage TTS until browsers are good at it natively.
Eh, I can't really show you the api, because there isn't one - or rather, it's roll-your-own, you implement commands in your script that you want to be able to use for whatever you're trying to pull off. Like, take the webhook sample as it is now.fapnip wrote: Sat Jan 09, 2021 9:55 pmI'd need to look at the API more to see how complex adding multiple toys would be. Do each have their own ID? Do I just query and get a list of all toys?
It would be fairly trivial to add support for multiple devices, by sticking a device number parameter on the end or something. Though I don't know if I'd use those particular command names, or exactly the form that this takes under the hood. (Why yes, I am volunteering to do implementation for the Xtoys scripting end of things.)Control any connected toy by sending requests to either of these two URLs.
Set percent:Turn on for x seconds:Code: Select all
https://xtoys.app/webhook?id={webhookID}&action=set-intensity&intensity={percent}Replace {webhookID} with your Webhook ID generated from https://xtoys.app/me.Code: Select all
https://xtoys.app/webhook?id={webhookID}&action=temporary-on&seconds={seconds}&intensity={percent}
Replace {percent} with the percent you want to set the toy to.
Replace {seconds} with how long to turn on the toy for.
Fair enough, I'm not too interested anyway, I just thought I'd mention it because hey, it's on the list.I'd rather not encourage TTS until browsers are good at it natively.
Having a hard time wrapping my head around how webbooks interact with the scripts. Is there a doc that point it out in detail? Can't seem to find that.RemiHiyama wrote: Sat Jan 09, 2021 11:16 pmCode: Select all
https://xtoys.app/webhook?id={webhookID}&action=temporary-on&seconds={seconds}&intensity={percent}
Code: Select all
var vibes = Toys.getByType('vibe');
var analVibes = vibes.filter(function(toy){return toy.location === 'anal'});
if (!analVibes.length) {
new Say({label: "Sorry, you need to configure a vibe for your ass to continue."})
} else {
// run at 50% for 10 seconds, then goto 'my-next-page'.
analVibes[0]
.intensity(.5)
.onComplete(function () {
pages.goto('my-next-page');
})
.run(10000);
}
Well, not really. Partly because this thing is still in early days and there aren't a lot of docs yet. But take the one you quoted.fapnip wrote: Sun Jan 10, 2021 1:05 amHaving a hard time wrapping my head around how webbooks interact with the scripts. Is there a doc that point it out in detail? Can't seem to find that.
You aren't wrong. I'm pretty excited about the things that you can do with it after getting frustrated with the limits of the Lovense app, and once you get things going it works quite well. But the learning curve for actually making patterns and scripts is pretty steep. (Using a premade script, isn't that difficult when you get used to the idiom of adding blocks and then connecting your device to your blocks.)Just scratching the surface, and perhaps I'm looking at it wrong, but it seems like a complicated mess for both users and authors to get up and running.
Ehhh, I was assuming you'd be going with full abstraction anyway. But getting the script wouldn't be hard, and the only configuration is attaching each device to the script's output. Which can be named so you know what's supposed to go where. Whether you're naming by body part or by numbers.In any case, the only way I could implement something like this relatively safely is to fully abstract interaction, with a configuration dialog in OpenEos that get all information needed for toy configuration, outside of the tease. But there doesn't seem to be any standardized way to interact with the user's devices -- they need to have the correct script installed, and that script apparently needs to be configured for each their devices correctly, etc. etc.
Hmmm. The webpage monitor (If the extension is installed and the block is attached to a script) can post to web forms, but only if the user opens up that page first. Not saying it'd be impossible to send data outside of the app, but it's not obvious to me at any rate.I wouldn't be comfortable letting the tease author send arbitrary data to the xtoys webhook endpoint, since I'd need to fully trust xtoys.app, and all the given scripts running on it, since that's were real privacy issues can pop up, like a tease asking for a user's email address or phone number and firing it off to a remote host.
As long as it could take whatever abstraction you come up with and turn it into a call to something likeIdeally, I'd like to just have a drop-down in OpenEos's toy configuration dialog that allows adding one or more device with settings for; provider (select list: xToys), key (text input: webhookID), type (select list: vibe, etc.), location (select list: cock, pussy, balls, anal, nipple, etc.)
Then a tease could interact with the configured devices with something like......with OpenEos handling all abstraction.Code: Select all
var vibes = Toys.getByType('vibe'); var analVibes = vibes.filter(function(toy){return toy.location === 'anal'}); if (!analVibes.length) { new Say({label: "Sorry, you need to configure a vibe for your ass to continue."}) } else { // run at 50% for 10 seconds, then goto 'my-next-page'. analVibes[0] .intensity(.5) .onComplete(function () { pages.goto('my-next-page'); }) .run(10000); }
Code: Select all
https://xtoys.app/webhook?id={webhookID}&action=vibrate&location=anal&intensity=0.5Code: Select all
Toys.vibes.anal.intensity(.5) ((and so forth))If you, or anyone else, wants to write some scripts for xtoys, then provide me with endpoints + parameters, I'll give it a shot.RemiHiyama wrote: Sun Jan 10, 2021 3:14 am You aren't wrong. I'm pretty excited about the things that you can do with it after getting frustrated with the limits of the Lovense app, and once you get things going it works quite well. But the learning curve for actually making patterns and scripts is pretty steep. (Using a premade script, isn't that difficult when you get used to the idiom of adding blocks and then connecting your device to your blocks.)
Code: Select all
https://xtoys.app/webhook?id={webhookid}&action=vibrate&location=primary&intensity=25I'm assuming some authors will want to be able to address by location. I honestly have no idea. Perhaps just primary/secondary is enough, and authors can tell users where to put it?
Thinking it over, if there is to be a location, it's probably better to define toy location on OpenEOS side, so the xtoys side of things doesn't need that complication, but will still need some way of supporting multiple devices.RemiHiyama wrote: Mon Jan 11, 2021 6:42 am So far we've got "cock, pussy, balls, anal, nipple" as a location list. Other than the option for separate left and right nipple control, anything else?
Moving beyond just vibrator, would there need to be a different script for each toy type? OpenEOS - The Handy; OpenEOS - Vibrator, etc., with each, script allowing multiple toys added to it? (Not sure what's possible. Just want some way to uniformly address toys, to later be able to control as many toy features as is practical (stroke position, etc.,), for authors that want greater control of specific devices, along with more generic controls (intensity, etc.), and, if possible, some pattern presets until variable passing is a thing?)RemiHiyama wrote: Mon Jan 11, 2021 6:42 am And then the functions. Basic intensity control is a given. Do you think the "temporary on" function has any value in this application? Because I gotta say, unless I'm missing something that's gonna be a real sonofabitch to script in a way that allows OEOS to stop or change it before it's run it's course. (Well, maybe with variable passing, but that isn't in yet.)
I'd like to be able to do some basic (or even not so basic) oscillating patterns, but that's something where it'll be relatively trivial to implement a pretty wide range of behaviors once variable passing is implemented, and in the current state of not having that, it's essentially impossible.
Yeah, probably just intensity to start, although duration (preferably in ms) is kind of needed. Is that possible?RemiHiyama wrote: Mon Jan 11, 2021 6:42 am Support for thrusting/stroking toys... uh, I don't know, that brings in a whole new set of problems that I'm not sure how to deal with right now. Start with just getting vibration to work, I think.
Yeah, though maybe replace location with a toy id / unique name of sorts, leaving OpenEOS UI to define location?RemiHiyama wrote: Mon Jan 11, 2021 6:42 amThat look okay?Code: Select all
https://xtoys.app/webhook?id={webhookid}&action=vibrate&location=primary&intensity=25
Well, I should clarify that when I talk about primary and secondary, those are both still supposed to be "on the genitals" in some way or another, with the general idea being "primary is the location that gives me the most pleasure, and secondary is something that's still good, but not as good". So one guy might have primary for a vibrator on his penis and secondary on balls, but a guy who doesn't like vibration on his balls but finds vibration on the head of his penis vs the base of the shaft to provide different experiences could place things accordingly. And a woman who gets more out of clitoral stimulation than internal vibration can arrange things accordingly, as can one who's more the other way around. (Not that the other way around seems common, but it's not unknown.) Or maybe they have a vibrator with multiple motors in a line (I mean, I've got one, although Xtoys doesn't support it), and attach primary and secondary based on how they feel about vibration from one end vs. the other.fapnip wrote: Mon Jan 11, 2021 7:34 pmI'm assuming some authors will want to be able to address by location. I honestly have no idea. Perhaps just primary/secondary is enough, and authors can tell users where to put it?
That's actually what I thought at first, but I don't think I agree at this point. Because I don't think it actually makes the xtoys side configuration simpler, it just means they have to go back and forth between OpenEOS and xtoys to get everything hooked up properly, and also makes it a bit harder to leverage the saved layout feature so you don't have to do the whole thing again every time you want to use the same set of toys.Thinking it over, if there is to be a location, it's probably better to define toy location on OpenEOS side, so the xtoys side of things doesn't need that complication, but will still need some way of supporting multiple devices.
It's possible that, given a possible future Buttplug provider, that people would want to control some toys with one provider and some the other, since their support lists don't fully overlap. I'd suggest a list of locations, with each location having a dropdown or radio buttons for provided devices, and a checkbox for the user to say "I've actually got one hooked up". And above or below that is where you can put in your provider configuration stuff (like your webhookid for xtoys).I'm thinking the OpenEOS UI will need, for each toy:
- Toy control provider: (Only "XToys Webhook" ATM)
[xtoys specific]
- webhookId (provided by xtoys)
- toyId (variable in xtoys script?)
It certainly seems possible to use separate scripts by feature type, and I can see some arguments for doing so. I just did some testing, and two webhook scripts will coexist and function together just fine as long as they have different action names.Moving beyond just vibrator, would there need to be a different script for each toy type? OpenEOS - The Handy; OpenEOS - Vibrator, etc., with each, script allowing multiple toys added to it?
Honestly I'd rather not unless it looks like variable passing won't be coming anytime soon, which I'm hoping will not be the case based on the course of development so far. It would represent a -lot- of extra work.if possible, some pattern presets until variable passing is a thing?)
There's two things that can be done with the handy right now, from my understanding of things.Yeah, probably just intensity to start, although duration (preferably in ms) is kind of needed. Is that possible?
I've received a number of requests for supporting the handy, so it would be nice to be able to support that.
Thanks! I'll take a look next time I free up some time to work on OpenEOS.RemiHiyama wrote: Tue Jan 19, 2021 11:33 pm I've published a script using my suggested API under the name "OEOS Bridge Script". Currently only basic vibration is supported. I thought I had a workaround to do some pattern stuff, but... it didn't work.