GIFT: Game Interface For Toys (Skyrim LE + SE + AE + VR | Fallout 4)

[sirah forgot their email]

Nice work! There's been some similar stuff done in

and some more recent work as well on https://discord.gg/4482jFApGC, if you want to chat about toy integrations. I'll give yours a test, since my old script that basically does the same log scraping hasn't been adapted for Skyrim VR yet, and does a terrible job with multiple toys.

 

Are you aware of https://buttplug.io/ , incidentally? Using that instead of the Lovense interface would give compatibility with most bluetooth toys (I'd personally love to see an integration with the DG Labs Coyote, too, if you're taking any requests...)

[Min]

On 6/10/2022 at 11:14 PM, bondageloverxxx69 said:

 

I have two Qiui devices coming later this month. If you can walk me through the how of figuring it out, then I would be happy to provide the information you need.

Sure, DM me when you get them and I'll look in to it.

 

On 6/11/2022 at 12:49 AM, sirah forgot their email said:

Nice work! There's been some similar stuff done in

and some more recent work as well on https://discord.gg/4482jFApGC, if you want to chat about toy integrations. I'll give yours a test, since my old script that basically does the same log scraping hasn't been adapted for Skyrim VR yet, and does a terrible job with multiple toys.

 

Are you aware of https://buttplug.io/ , incidentally? Using that instead of the Lovense interface would give compatibility with most bluetooth toys (I'd personally love to see an integration with the DG Labs Coyote, too, if you're taking any requests...)

I was not aware of buttplug.io. I'll look in to it. I actually have a DG labs arriving literally today. Planning on adding support for that one.

 

Also! Joined the discord. Let's chat.

[Shirya]

hello ^^

first of all, thx for sharing ur work. Since i have somes lovense toys i wanted to try to connect them to skyrim for more fun ^^

Starting the python script seem ok, but nothing happen at all when i start a sexlab scene. I made somes screen for let u see this.

 

First, my setting in the file, with the name of my char ingame, im playing on VR skyrim.

When i start ur script, everything seem ok

But on the 2 last screens u can see sexlab starting with my char name and reset at the end, but my toy don't started vibrate at all.

 

i tested my toy, making it vibrate before start ur script and when i start it, my toy stop vibrate, so it seem to be connected and response to ur script. So i don't know why nothing happen in a sexlab scene. Maybe u can help me to understand where im wrong in my configuration?

 

Btw, im using my game in french version, i don't know if that can be an issue since the log it still in english

[Min]

5 hours ago, Shirya said:

hello ^^

first of all, thx for sharing ur work. Since i have somes lovense toys i wanted to try to connect them to skyrim for more fun ^^

Starting the python script seem ok, but nothing happen at all when i start a sexlab scene. I made somes screen for let u see this.

 

First, my setting in the file, with the name of my char ingame, im playing on VR skyrim.

When i start ur script, everything seem ok

But on the 2 last screens u can see sexlab starting with my char name and reset at the end, but my toy don't started vibrate at all.

 

i tested my toy, making it vibrate before start ur script and when i start it, my toy stop vibrate, so it seem to be connected and response to ur script. So i don't know why nothing happen in a sexlab scene. Maybe u can help me to understand where im wrong in my configuration?

 

Btw, im using my game in french version, i don't know if that can be an issue since the log it still in english

It shouldn't matter that you're using the french version. Thanks for the screenshots, they contain a fair bit of good diagnostic info.  When the script starts, you're getting a 200 back from the api, so your toys are set up correctly, and it's able to talk to the Lovense interface. Looking at your screenshots, it looks like the regular expressions a aren't matching the line for sexlab to start. I think I might have an idea why. I'll upload a new version, let me know if it fixes your issue.

[Min]

New version is up: Alpha 3

• Added support for Naked Defeat.
• Changed SexLab pattern to better match the start of the scene, and nothing else.
• Fixed an issue preventing the matching of SexLab scenes for some users.
• Added support for physical feedback from Chaster's "Spin the Wheel" feature. Add the following entries to your wheel of fortune to trigger effects locally!
  • "slsi_shock1": Placeholder for planned estim integration
  • "slsi_shock2": Placeholder for planned estim integration
  • "slsi_dice": Activate the "Roll the dice" extension.
  • "slsi_plug": Assign a task to yourself.
  • "slsi_clamps": Assign a task to yourself.
  • "slsi_overstimulate": Crank up toys to the limit for 5 mins.
  • "slsi_tease": Activate toys on a very low setting for 5 mins.
• Added a short vibration on script start for validation that toys are working before playing.

 

Planning on adding DG-lab support to next release. Will require a bluetooth adapter on your PC.

[Shirya]

17 hours ago, Min said:

New version is up: Alpha 3

 

Hello ^^ so i tested this new version and work like a charm for me ^^

for more info, im using a hush and it started to vibrate like a hell haha

 

I wonder if u could make something for call to the toy to play a vibrate sequence? at least something in the script (as we do with name of our char) for tell to the script the max value we allow for the vibrate power, cuz set up my hush to 86 was a crazy experience ! lol

 

btw, nice update, and loved the test at the start

I tested some toy mods but this is the first one who works while playing sex scene (maybe im too noob with others XD)

good job

[dingdingdinggo]

Hi!

 

I really like the idea and can't wait to try out this kind of immersion.

 

 

 

Is it planned to react to the different log outputs of plugs? As far as I remember the game prints messages like 'plugs teasing you',  'your plugs send you over the edge' or 'your plugs bringing you to a thunderous climax'. Those could lead to different intensities.

I think it would also be cool if front end rear could be triggered seperately.

 

Thanks for your efforts and sharing!

 

 

Edited June 16, 2022 by dingdingdinggo

[Min]

2 hours ago, dingdingdinggo said:

Hi!

 

I really like the idea and can't wait to try out this kind of immersion.

 

 

 

Is it planned to react to the different log outputs of plugs? As far as I remember the game prints messages like 'plugs teasing you',  'your plugs send you over the edge' or 'your plugs bringing you to a thunderous climax'. Those could lead to different intensities.

I think it would also be cool if front end rear could be triggered seperately.

 

Thanks for your efforts and sharing!

Currently DD doesn't log that sort of information. I put in a request with Kimy to let me modify the log output with that info so that we can react to it. We'll see if she's open to it. If not, well - DD does send mod events at the start / end of vibrations, as well as when when the player orgasms. I could write a little esp for Skyrim to pair with this script that listens for those mod events and logs an appropriate line.

 

5 hours ago, Shirya said:

 

Hello ^^ so i tested this new version and work like a charm for me ^^

for more info, im using a hush and it started to vibrate like a hell haha

 

I wonder if u could make something for call to the toy to play a vibrate sequence? at least something in the script (as we do with name of our char) for tell to the script the max value we allow for the vibrate power, cuz set up my hush to 86 was a crazy experience ! lol

 

btw, nice update, and loved the test at the start

I tested some toy mods but this is the first one who works while playing sex scene (maybe im too noob with others XD)

good job

Yeah. I think what I want to do for that is to add support for playing patterns (Like Lovense supports) to the script, and play different patterns in different scenarios. You would then be able to control whatever intensity you wanted by the patterns you set up.

[dingdingdinggo]

Thank you.

 

I understand that the script is a proof of concept and I am happy that you are open for suggestions.

 

 

An own esp/mod would be a great way to deal as interface between the game and the python log reader. You would be way more independent of other mods and could define the output of log-text and the logs semantic to react on. Also a configurable MCM menu is possible. I guess that's what you meant?

 

Last thing: pls implement a short 100% intensity burst on the toys in case of a shock event.

 

Edited June 16, 2022 by dingdingdinggo

[DeWired]

4 minutes ago, Min said:

Currently DD doesn't log that sort of information. I put in a request with Kimy to let me modify the log output with that info so that we can react to it. We'll see if she's open to it. If not, well - DD does send mod events at the start / end of vibrations, as well as when when the player orgasms. I could write a little esp for Skyrim to pair with this script that listens for those mod events and logs an appropriate line.

Well, all previous iterations of this idea had an esp made at some stage. It is only logical as it allows for greater flexibility of data flow from inside the game - some examples are getting step events, hit events, detecting game pause (to pause devices), etc. And modifying libraries to send more log data isn't fair to all users. What we really need to push forward is more events in the libraries and more granularity - for example, right now viration events have intensity, but shock doesn't.

[Min]

12 hours ago, DeWired said:

Well, all previous iterations of this idea had an esp made at some stage. It is only logical as it allows for greater flexibility of data flow from inside the game - some examples are getting step events, hit events, detecting game pause (to pause devices), etc. And modifying libraries to send more log data isn't fair to all users. What we really need to push forward is more events in the libraries and more granularity - for example, right now viration events have intensity, but shock doesn't.

Yeah, makes sense. I think it's what I'm going to end up having to do. Still might contribute to the DD framework to add more events to hook in to, at least.

[MongooseFront]

On 6/15/2022 at 4:47 PM, Min said:

New version is up: Alpha 3

 

[...]

 

Planning on adding DG-lab support to next release. Will require a bluetooth adapter on your PC.

 

Hello,

 

Many thanks for your hard work, Min. I am very excited to try it out for myself!

 

As luck would have it, I've actually been working on this exact problem but from the completely opposite direction: I've written a python script capable of communicating with the DG-Lab Coyote e-stim device over Bluetooth, but I've struggled to figure out how to make it react to in-game Sexlab/Devious Devices events.

 

So, attached you will find a prototype for a DG-Lab Coyote interface class dg_interface.py that should neatly slot into your existing codebase (see attached modified version of your script SkyrimToyInterface-alpha3.py).

 

In essence, the CoyoteInterface class implements the same vibrate() and stop() methods as the LovenseInterface class, but has additional logic behind the scenes to pair and communicate with the DG-Lab Coyote device over Bluetooth.

 

Importantly, the class uses a simple multiplier value to translate between the "vibration strength" values and the DG-Lab Coyote box's native power intensity. This value needs to be tweaked and balanced according to what kinds of vibration speeds the interface can expect. Currently, the Coyote interface expects a minimum vibration strength of 0 and a max vibration strength of 600, and the multiplier translates this maximum to about 37.5 % of the box's max power intensity. (I haphazardly gleaned the number 600 from your own script, so this is very preliminary.) The class also caps any e-stim intensity at 37.5 % as a fail-safe because, as you may know, the DG-Lab Coyote is very, very powerful.

 

The code is rudimentary at the moment, but it should be enough as a foundation. For future work I would love to make the DG-Lab Coyote box output different e-stim patterns and intensities according to different in-game events, for instance, or have it output different patterns on the two different channels for differentiated and more immersive stimulation.

 

Apropos e-stim patterns: They are not difficult to write by hand, but I haven't gotten around to making any interesting ones. There are currently only two placeholder patterns in the code, but the script contains more info on how to get one started on making new ones.

 

The code relies on the "bleak" package from pypi for its Bluetooth functionality. Of course, you need a Bluetooth 4.0+ adapter built-in in your computer or available externally as a USB dongle. You need to know the UID or address of your particular DG-Lab Coyote box in order to connect to it. Also, be warned that the process of establishing a connection is not always reliable: You might need to alternately "unpair" and "pair" the device in your windows Bluetooth settings in order to make bleak recognise the device. bleak is also an inherently asynchronous library, which is a coding paradigm I am not clever enough to understand, and this is why the code makes liberal use of a work-around with local event loops in order to make synchronous use of the asynchronous library. If anyone knows of a better way, please be my guest!

 

As opposed to the Lovesense device, which exposes a REST API for fire-and-forget commands, the DG-Lab Coyote needs to be constantly fed e-stim pattern and intensity data from the user's computer. This means that the CoyoteInterface class blocks the entire program while it loops through its e-stim pattern, and it means that SkyrimScriptInterface will not be able to read the log file for that period of time. I doubt that this would be big issue, unless several in-game events are happening at once, which would probably lead to a kind of buffering effect, where vibration events are stacked and executed immediately after each other. A solution would be to delegate the communication with the device to an entirely separate thread, but I've found that getting async code to work with python threading is surprisingly difficult.

 

UX-wise, I believe the Coyote should really be providing continuous e-stimulation when in-game, with in-game events (such as a DD plug vibrating deviously) constituting moments of increased e-stim intensity, rather than only zapping the user every time a particular Sexlab/Devious Devices/etc. event happens. Experienced e-stimmers will know that sudden, unexpected e-stimulation is felt much more sharply than an increase in intensity during continuous stimulation. In short, the current version is probably only good for masochists. Handling DG-Lab Coyote device communication in a separate thread with autonomous, continuous e-stimming, would be a good first step towards allowing—pardon the expression—a hands-free enjoyment of the Loverslab Skyrim experience.

 

I offer this piece of code with one final caveat: I haven't had the opportunity to test integration of the CoyoteInterface with your code in practice. I may first be able to test it thoroughly next week. In any case, I mainly wanted to get my prototype out there before you waste time implementing it yourself. Implementing the low-level Bluetooth communication protocol for the DG-Lab Coyote device dg_encoding.py according to the imprecise specification machine-translated from the original Chinese was pure drudgery.

 

Also, if you're on gitlab/github I'd be happy to collaborate with you on this. My code is completely open source ("MIT" is probably a good fit) so licensing shouldn't be an issue, I think.

 

One last thing for other interested parties: This is untested alpha code, so please only download and try it if you know what you are doing. I disavow any responsibility or liability stemming from any use of this software in conjunction with your e-stim device!

 

Thanks.

 

dg_interface.py

dg_encoding.py

SkyrimToyInterface-alpha3.py

 

 

 

 

 

Edited June 17, 2022 by MongooseFront
Quick last-second fix to a parameter in SkyrimToyInterface-alpha3.py

[Min]

1 hour ago, MongooseFront said:

 

Hello,

 

Many thanks for your hard work, Min. I am very excited to try it out for myself!

 

As luck would have it, I've actually been working on this exact problem but from the completely opposite direction: I've written a python script capable of communicating with the DG-Lab Coyote e-stim device over Bluetooth, but I've struggled to figure out how to make it react to in-game Sexlab/Devious Devices events.

 

So, attached you will find a prototype for a DG-Lab Coyote interface class dg_interface.py that should neatly slot into your existing codebase (see attached modified version of your script SkyrimToyInterface-alpha3.py).

 

In essence, the CoyoteInterface class implements the same vibrate() and stop() methods as the LovenseInterface class, but has additional logic behind the scenes to pair and communicate with the DG-Lab Coyote device over Bluetooth.

 

Importantly, the class uses a simple multiplier value to translate between the "vibration strength" values and the DG-Lab Coyote box's native power intensity. This value needs to be tweaked and balanced according to what kinds of vibration speeds the interface can expect. Currently, the Coyote interface expects a minimum vibration strength of 0 and a max vibration strength of 600, and the multiplier translates this maximum to about 37.5 % of the box's max power intensity. (I haphazardly gleaned the number 600 from your own script, so this is very preliminary.) The class also caps any e-stim intensity at 37.5 % as a fail-safe because, as you may know, the DG-Lab Coyote is very, very powerful.

 

The code is rudimentary at the moment, but it should be enough as a foundation. For future work I would love to make the DG-Lab Coyote box output different e-stim patterns and intensities according to different in-game events, for instance, or have it output different patterns on the two different channels for differentiated and more immersive stimulation.

 

Apropos e-stim patterns: They are not difficult to write by hand, but I haven't gotten around to making any interesting ones. There are currently only two placeholder patterns in the code, but the script contains more info on how to get one started on making new ones.

 

The code relies on the "bleak" package from pypi for its Bluetooth functionality. Of course, you need a Bluetooth 4.0+ adapter built-in in your computer or available externally as a USB dongle. You need to know the UID or address of your particular DG-Lab Coyote box in order to connect to it. Also, be warned that the process of establishing a connection is not always reliable: You might need to alternately "unpair" and "pair" the device in your windows Bluetooth settings in order to make bleak recognise the device. bleak is also an inherently asynchronous library, which is a coding paradigm I am not clever enough to understand, and this is why the code makes liberal use of a work-around with local event loops in order to make synchronous use of the asynchronous library. If anyone knows of a better way, please be my guest!

 

As opposed to the Lovesense device, which exposes a REST API for fire-and-forget commands, the DG-Lab Coyote needs to be constantly fed e-stim pattern and intensity data from the user's computer. This means that the CoyoteInterface class blocks the entire program while it loops through its e-stim pattern, and it means that SkyrimScriptInterface will not be able to read the log file for that period of time. I doubt that this would be big issue, unless several in-game events are happening at once, which would probably lead to a kind of buffering effect, where vibration events are stacked and executed immediately after each other. A solution would be to delegate the communication with the device to an entirely separate thread, but I've found that getting async code to work with python threading is surprisingly difficult.

 

UX-wise, I believe the Coyote should really be providing continuous e-stimulation when in-game, with in-game events (such as a DD plug vibrating deviously) constituting moments of increased e-stim intensity, rather than only zapping the user every time a particular Sexlab/Devious Devices/etc. event happens. Experienced e-stimmers will know that sudden, unexpected e-stimulation is felt much more sharply than an increase in intensity during continuous stimulation. In short, the current version is probably only good for masochists. Handling DG-Lab Coyote device communication in a separate thread with autonomous, continuous e-stimming, would be a good first step towards allowing—pardon the expression—a hands-free enjoyment of the Loverslab Skyrim experience.

 

I offer this piece of code with one final caveat: I haven't had the opportunity to test integration of the CoyoteInterface with your code in practice. I may first be able to test it thoroughly next week. In any case, I mainly wanted to get my prototype out there before you waste time implementing it yourself. Implementing the low-level Bluetooth communication protocol for the DG-Lab Coyote device dg_encoding.py according to the imprecise specification machine-translated from the original Chinese was pure drudgery.

 

Also, if you're on gitlab/github I'd be happy to collaborate with you on this. My code is completely open source ("MIT" is probably a good fit) so licensing shouldn't be an issue, I think.

 

One last thing for other interested parties: This is untested alpha code, so please only download and try it if you know what you are doing. I disavow any responsibility or liability stemming from any use of this software in conjunction with your e-stim device!

 

Thanks.

 

dg_interface.py 22.78 kB · 1 download

dg_encoding.py 5.5 kB · 1 download

SkyrimToyInterface-alpha3.py 13.96 kB · 1 download

Cool, thanks for sharing. I had just started poking at this, and your implementation will save me a bunch of time. Cheers.

 

Honestly, the whole estimming thing makes me anxious. I'm fairly new to it, and your link is definitely concerning. I'm interested in playing with it, but definitely need to build some failsafes / robustness in to the application in order to use it in this manner. I have some ideas as to how we can modify the script to make it safer to use. DM me. I don't have a github set up for this project, though I do have an older github account I used to use for adult content / devious devices. I have a discord account set up for using with this community; DM me if you'd like, and we can talk more real-time about the project there.

 

I'm quite familiar with asynchronous / multithreaded development patterns. I think a good follow-up to this would have a worker running that manages estim output that the main process sends signals to for control.

[DeWired]

11 hours ago, Min said:

Yeah, makes sense. I think it's what I'm going to end up having to do. Still might contribute to the DD framework to add more events to hook in to, at least.

When/if you would get to making an esp, please consider adding generic modevent listener that just takes arbitrary string and logs it. That would allow simple patching of other mods in the future.

 

And about DD framework.. There is a simple idea - patch Notify function to either send it's data to modevent, or directly to log. Maybe make it configurable. I think many, if not all events right now go through notifying player about themself through text message with this function.

 

[Min]

4 hours ago, DeWired said:

When/if you would get to making an esp, please consider adding generic modevent listener that just takes arbitrary string and logs it. That would allow simple patching of other mods in the future.

 

And about DD framework.. There is a simple idea - patch Notify function to either send it's data to modevent, or directly to log. Maybe make it configurable. I think many, if not all events right now go through notifying player about themself through text message with this function.

 

Yeah. I'm planning on having this be extensible. About DD: I wish I had added more modevent's when I wrote those events, but such is life. I considered patching the notify function, but that would break on localized copies of the mod.

[MongooseFront]

@Min

 

Quote

Cool, thanks for sharing. I had just started poking at this, and your implementation will save me a bunch of time. Cheers.

 

Of course, you’re welcome.
 

Quote

Honestly, the whole estimming thing makes me anxious. I'm fairly new to it, and your link is definitely concerning. I'm interested in playing with it, but definitely need to build some failsafes / robustness in to the application in order to use it in this manner. I have some ideas as to how we can modify the script to make it safer to use. DM me.

 

Indeed, your misgivings are understandable and warranted. I think the idea—"Devious Skyrim, but you feel everything the Dragonborn does!"—has potential, especially in a SkyrimVR context, but it needs to be executed very carefully.
 

No matter how robust the code may be, any software interfacing with any e-stim device requires a written disclaimer disavowing any liability. You may even have to have the user actively accept this disclaimer through a pop-up or command line prompt before running the script.

 

I’ll be happy to hear your thoughts on potential fail-safes (hard caps on intensity etc. seem to be an obvious option), but there is ultimately only so much we can do on the software end to ensure user safety when interfacing with foreign e-stim hardware. Moreover, if a user decides in the heat of the moment to play with strong current across the chest, for example, there’s nothing we can do to prevent that.
 

Quote

 

I don't have a github set up for this project, though I do have an older github account I used to use for adult content / devious devices. I have a discord account set up for using with this community; DM me if you'd like, and we can talk more real-time about the project there.

 

I'm quite familiar with asynchronous / multithreaded development patterns. I think a good follow-up to this would have a worker running that manages estim output that the main process sends signals to for control.

 

 

Excellent. I planned on giving a threaded version a go myself as a learning experience, but you are welcome to take the lead. Let’s talk on Discord.

 

Cheers.

[DeWired]

1 hour ago, MongooseFront said:

 

I’ll be happy to hear your thoughts on potential fail-safes (hard caps on intensity etc. seem to be an obvious option), but there is ultimately only so much we can do on the software end to ensure user safety when interfacing with foreign e-stim hardware. Moreover, if a user decides in the heat of the moment to play with strong current across the chest, for example, there’s nothing we can do to prevent that.

As I understand those notes on Coyote, we can actually calculate how many power it outputs at any given setting - current, duty cycles, and all that. So, we can not only cap intensity - we can also manipulate patterns somewhat to provide safety margin. Like, not operating with zero pauses, or very long pulses. This is if we interface with it directly. We can also try to do what SKStim was doing - output audio and link it to native DG-Lab app, thus relegating safety issues.

 

Personally, I would try to separate estim interaction (BLE code) and offload it into ESP32. Theoretically, it would provide more stability and independence. Also, I don't have good history with Windows BT stack, so there's that..

[MongooseFront]

3 hours ago, DeWired said:

As I understand those notes on Coyote, we can actually calculate how many power it outputs at any given setting - current, duty cycles, and all that. So, we can not only cap intensity - we can also manipulate patterns somewhat to provide safety margin. Like, not operating with zero pauses, or very long pulses. This is if we interface with it directly. We can also try to do what SKStim was doing - output audio and link it to native DG-Lab app, thus relegating safety issues.

 

Personally, I would try to separate estim interaction (BLE code) and offload it into ESP32. Theoretically, it would provide more stability and independence. Also, I don't have good history with Windows BT stack, so there's that..

 

Indeed, it is a good point. It should be possible to linearly optimise for safe value ranges for each setting. Moreover, the undertaking need not be wholly theoretical: I have a multimeter and could definitely make a few controlled, empirical amperage tests without risking life and limb!

 

I am not sure, however, that an audio-based solution would work all that great with the DG-Lab Coyote box. The electronics engineer I linked to above has lambasted the device's audio processing capabilities and supposed "strange behaviour" of the official app. Directly interfacing with the Coyote box might actually be more reliable, as counter-intuitive as that sounds, because we then remove two unknown and potentially troublesome intermediaries (Game log-->Python-->Bluetooth-->Coyote instead of Game log-->Python-->Audio-->App-->Bluetooth-->Coyote) from the equation entirely.

 

On the other hand, support for audio output would undoubtedly make SkyrimToyInterface immediately compatible with more e-stim equipment like the Erostek or Estim Systems Ltd. line-ups, which is good for user adoption.

 

On introducing an ESP32 into the mix: Sounds intriguing! How would that work, though? Do you see the EPS32 being connected with the Coyote while locally serving an API over Wi-Fi?

[DeWired]

33 minutes ago, MongooseFront said:

On the other hand, support for audio output would undoubtedly make SkyrimToyInterface immediately compatible with more e-stim equipment like the Erostek or Estim Systems Ltd. line-ups, which is good for user adoption.

I think using audio files is a desirable goal, because it not only allows more equipment compatibility, but also bring more ready made patterns. It is just that first it's better to focus on building minimal viable pipeline from game event to end device, and then inserting more options.

38 minutes ago, MongooseFront said:

On introducing an ESP32 into the mix: Sounds intriguing! How would that work, though? Do you see the EPS32 being connected with the Coyote while locally serving an API over Wi-Fi?

Well, ideally - yes. But I tried this kind of setup with Lovense, and only managed BLE+Serial for now, as BLE+WiFi took too much space on board. I still think it's a problem of me using Arduino IDE, though, as on the same ESP32 I can install EspHome, that does WiFi, BLE, touchpads, and OTA. It's just that integrating needed capabilities into EspHome is more complex then writing Arduino sketch...

[dingdingdinggo]

Hi!

 

I recognized some beep beeps and I guess stack_overflow was called by this:

[06/21/2022 - 04:59:55PM] [Zad] ((WARNING)): SetVibrating(126) received out of range value
[06/21/2022 - 04:59:55PM] [Zad]: VibrateEffect(4 for 999). VibrateMult: 1.000000

 

Unfortunately I'm not sure. The logs aren't loud enough for debugging.

 

Just in case:

I fixed my problem and had a blast with XDFF.

    def vibrate(self, duration, strength):
        info("Vibrate - start(duration={}, strength={})".format(duration, strength))
        if strength > 100:
            strength = 100
        self.interface.vibrate(duration, strength)

Edited June 21, 2022 by dingdingdinggo

[Koozie]

Maybe support for SLSO can be integrated, orgasming can trigger higher vibration, also milk mod econamy can trigger vibration or slap that ass electricity.

[VirginMarie]

Now that Toys&Love 2.2 is out (released yesterday), it works with this mod. Will pick up climax in love scenes, the pulsating toys, and more.

 

Min your DL page does not list which mods are supported, beyond the tags, which I think many don't pay attention to. If you end up listing, you might mention requires v2.2+. I have your mod listed here... Toys Family of Mods

 

I've tested how this behaves using the other solution that we've had for a while, but only with an XBox Controller. So I don't know personally what it's like with a real toy, and would love to hear from someone trying it, if the settings in the Toys&Love MCM give you enough control to make it good.

[Min]

On 6/29/2022 at 1:55 PM, VirginMarie said:

Now that Toys&Love 2.2 is out (released yesterday), it works with this mod. Will pick up climax in love scenes, the pulsating toys, and more.

 

Min your DL page does not list which mods are supported, beyond the tags, which I think many don't pay attention to. If you end up listing, you might mention requires v2.2+. I have your mod listed here... Toys Family of Mods

 

I've tested how this behaves using the other solution that we've had for a while, but only with an XBox Controller. So I don't know personally what it's like with a real toy, and would love to hear from someone trying it, if the settings in the Toys&Love MCM give you enough control to make it good.

Thanks - I'll mention that when I update.

 

 

For anyone interested: A few of us have been working on an updated version for this, which supports the DG-Lab Coyote, many more types of sex toys (Through Buttplug.io support), and has an in-game plugin to allow the toys to react to various events (Such as being hit in combat). You can follow along here if you're interested: https://github.com/MinLL/SkyrimToyInterface

 

This version adds new dependencies on Bleak, and Buttplug.io. Thanks to @sirah for the buttplug.io integration, and @MongooseFront for writing the DG-Lab library. I intend to release a package here which contains everything, but I figure that installation is probably getting a bit complex for users, given that we have new dependencies.... Going to put together a simple UI for the script, and package it into an exe before releasing it here again. In the meantime, feel free to check out the github if you're inclined.

 

[Min]

On 6/21/2022 at 10:23 AM, dingdingdinggo said:

Hi!

 

I recognized some beep beeps and I guess stack_overflow was called by this:

[06/21/2022 - 04:59:55PM] [Zad] ((WARNING)): SetVibrating(126) received out of range value
[06/21/2022 - 04:59:55PM] [Zad]: VibrateEffect(4 for 999). VibrateMult: 1.000000

 

Unfortunately I'm not sure. The logs aren't loud enough for debugging.

 

Just in case:

I fixed my problem and had a blast with XDFF.

    def vibrate(self, duration, strength):
        info("Vibrate - start(duration={}, strength={})".format(duration, strength))
        if strength > 100:
            strength = 100
        self.interface.vibrate(duration, strength)

Cool, thanks for the fix. I'll merge that. What's XDFF? Is that Deviously Cursed Loot's dominant follower system?

 

On 6/26/2022 at 8:05 AM, Koozie said:

Maybe support for SLSO can be integrated, orgasming can trigger higher vibration, also milk mod econamy can trigger vibration or slap that ass electricity.

Yeah, not a bad idea. I don't use either of those mods though, and don't have room in my load order currently. If you can provide the appropriate lines for the script to trigger on, I'll add support.

[dingdingdinggo]

XDFF is an extension for Devious Followers. The follower has some devious fun with the PC. Especially with plugging and teasing.