Jump to content

Recommended Posts

14 hours ago, Min said:

 

 

Copy/paste from GIFT's output window around an event where a vibration should have occurred, and I'll take a look

stack:
    <empty stack>
[12/13/2022 - 10:57:22AM] [Helpless]: Suspending scenes, called from: [SF_SlutsHaul_SetUp_0A06AEA3 < (7B06AEA3)>], ()
[12/13/2022 - 10:57:22AM] [SLUTS] Payment = 14449
[12/13/2022 - 10:57:22AM] [SLUTS] Haul Preparations done, SetStage 5
[12/13/2022 - 10:57:24AM] [Zad]: OnSpellCast()
[12/13/2022 - 10:57:25AM] [SkyrimToyInterface]: OnVibrateStart()
[12/13/2022 - 10:57:28AM] [Zad]: Maintenance_ABC()
[12/13/2022 - 10:57:31AM] [SkyrimToyInterface]: OnVibrateStop()
[SkyrimToyInterface] Toy Vibrate - stop
[12/13/2022 - 10:57:31AM] [Zad]: OnVibrateStop(tyi, tyi)
[12/13/2022 - 10:57:31AM] [slautilscr <sla_Framework (1104290F)>]: tyi got -32 exposure for 
[12/13/2022 - 10:57:32AM] [DCUR] Scanning for followers
[12/13/2022 - 10:57:38AM] [Zad]: Set slot mask to [0]: 0
[12/13/2022 - 10:57:38AM] WARNING: Assigning None to a non-object variable named "::temp20"

Link to comment
  • 2 weeks later...

This is pretty sweet, so far it seems to work smoothly. Only issue I see so far is that Max only half works (vibration is fine but no contraction/pump), which isn't surprising since I've only seen like 1 integration where that does work.
Looking through the Github and API though I really don't know why it wouldn't work, since it looks like sending 'F:vrp' should handle it. I did notice something telling though, if I manually hit the button to turn on the pump it works but once the next stage of the pattern starts it turns off the pump. Kind of makes it seem like it's either getting nothing but 0's for the pump or it's getting something out of range.

 

Using GIFT 1.1.3

Tried with 'Use new API' checked and unchecked

 

Link to comment

After an hour of trying to get it to work, finally managed, but even that, just partially.
Apparently what I had to do, was to turn on the debug logging in DD settings in MCM, which did actually make at least DD themselves work, as for SexLab, I still dont know even now what makes the papyrus write info from sexlab, if those settings are from Skyrim.ini / SkyrimCustom.ini, the Papyrus section

Spoiler

[Papyrus]
bEnableLogging=1
bEnableProfiling=1
bEnableTrace=1
bLoadDebugInformation=1
fPostLoadUpdateTimeMS=2000

 

I say, the mod is a really interesting technological advance, in its own unique "loverslab" way and its awesome, but, PLEASE give us a detailed information on setup and installation, its quite easy to get lost while trying to get this this thing to work.

 

Edit: Tried esl-ifying the .esp, worked fine without any warnings/errors in xEdit, anyone tried this? If not, ill reply results later.
Edit2: Tried it as pseudo-esl, worked fine, but also, didnt try it that much for this info to be completely valid.

Edited by Inquizit0r
Link to comment
31 minutes ago, greg136 said:

This is pretty sweet, so far it seems to work smoothly. Only issue I see so far is that Max only half works (vibration is fine but no contraction/pump), which isn't surprising since I've only seen like 1 integration where that does work.
Looking through the Github and API though I really don't know why it wouldn't work, since it looks like sending 'F:vrp' should handle it. I did notice something telling though, if I manually hit the button to turn on the pump it works but once the next stage of the pattern starts it turns off the pump. Kind of makes it seem like it's either getting nothing but 0's for the pump or it's getting something out of range.

 

Using GIFT 1.1.3

Tried with 'Use new API' checked and unchecked

 

Hmmm. Are you using the Lovense interface directly, or the Buttplug.io interface? Looking at the documentation (https://developer.lovense.com/#step-3-command-the-toy-s ), I believe that anything using a pattern should fully work, as I'm sending vrp, as you mentioned. If we're just doing a basic vibration though, I'm not sending the pump action, so that makes sense.

 

25 minutes ago, Inquizit0r said:

After an hour of trying to get it to work, finally managed, but even that, just partially.
Apparently what I had to do, was to turn on the debug logging in DD settings in MCM, which did actually make at least DD themselves work, as for SexLab, I still dont know even now what makes the papyrus write info from sexlab, if those settings are from Skyrim.ini / SkyrimCustom.ini, the Papyrus section

  Reveal hidden contents

I say, the mod is a really interesting technological advance, in its own unique "loverslab" way and its awesome, but, PLEASE give us a detailed information on setup and installation, its quite easy to get lost while trying to get this this thing to work.

 

Edit: Tried esl-ifying the .esp, worked fine without any warnings/errors in xEdit, anyone tried this? If not, ill reply results later.

I haven't tried esl-ifying the .esp, but I see no reason why that wouldn't work. Sexlab should just write that info when logging is enabled (Or it does for me, anyways). We had some indepth installation instructions, but they're a bit out of date after gift 1.0, so they've been taken down at the moment. Basically, it comes down to:

1) Enable logging.

2) Configure GIFT to use the right types of toys.

3) Configure GIFT to watch the right log.

4) Install the skyrim plugin included with GIFT through your mod manager of choice.

5) Run the game.

Link to comment
23 minutes ago, Min said:

Hmmm. Are you using the Lovense interface directly, or the Buttplug.io interface? Looking at the documentation (https://developer.lovense.com/#step-3-command-the-toy-s ), I believe that anything using a pattern should fully work, as I'm sending vrp, as you mentioned. If we're just doing a basic vibration though, I'm not sending the pump action, so that makes sense.

Lovense interface, just downloaded Initface Central and gave it a try.
With the Initface, it acted the same way however if I manually turned on the pump it wasn't turned when the pattern changed.
 

Considering some of the API doc said to send values between 1 and 3 for some pump commands, and the fact that Initface only used 1-3 for the air pump control I was wondering if the values sent to the pump were just too high, so I edited the 'pattern_dict.json' to pull all the values between 1 and 3.
With Lovense I saw no change, but it was using the lower values

Initface didn't seem to be using that pattern file and used the normal values

This was all using the 'Test Sex' button

Link to comment
1 hour ago, greg136 said:

Lovense interface, just downloaded Initface Central and gave it a try.
With the Initface, it acted the same way however if I manually turned on the pump it wasn't turned when the pattern changed.
 

Considering some of the API doc said to send values between 1 and 3 for some pump commands, and the fact that Initface only used 1-3 for the air pump control I was wondering if the values sent to the pump were just too high, so I edited the 'pattern_dict.json' to pull all the values between 1 and 3.
With Lovense I saw no change, but it was using the lower values

Initface didn't seem to be using that pattern file and used the normal values

This was all using the 'Test Sex' button

Yeah, the Initface implementation currently does not have pattern support (I've only written that for the Lovense interface, Lovense is better supported overall).

 

I also just got my Max out, and tested - the pump seems to work as expected. I'm using Game Mode on my phone to connect rather than the local Lovense Desktop app. Try that, and see if it works? Might be a difference in how the apps are implemented.

Link to comment
2 minutes ago, greg136 said:

Interesting there would be a discrepancy there. I will, respectfully, not be installing the Lovense mobile app on my company phone though.

Yeah, definitely would not advise installing that on a company phone. I have a spare phone that I use for that sort of thing.

Link to comment

I tried to set this up. I have a lush but I have never been very knowledgeable with networking stuff... Im also not a native speaker. I don't want to bother anyone either.

 

So I have intiface central in my phone, It recognizes and paires with my lush, I can use it to interact with the lush. That part works.

 

Then, I assumed I had to type my server address (which is in the top part of my phone intiface app) into "Buttplug.io server address". 

 

GIFT outputs: "192.xxx.xx.xx:port" isnt a valid URL: scheme isnt ws or wss

 

I googled around a bit (and read this comment section) but I dont really know much about what a ws or wss address is, although I've tried some (dumb) things

 

 intiface configuration documentation is very lacking, sadly

I think they just updated their app to 2.0 (not even a month ago) 

 

Im sorry if this is something obvious that I am not noticing, but so far I have not been able to 

 

 

Link to comment
6 hours ago, albyznts said:

I tried to set this up. I have a lush but I have never been very knowledgeable with networking stuff... Im also not a native speaker. I don't want to bother anyone either.

 

So I have intiface central in my phone, It recognizes and paires with my lush, I can use it to interact with the lush. That part works.

 

Then, I assumed I had to type my server address (which is in the top part of my phone intiface app) into "Buttplug.io server address". 

 

GIFT outputs: "192.xxx.xx.xx:port" isnt a valid URL: scheme isnt ws or wss

 

I googled around a bit (and read this comment section) but I dont really know much about what a ws or wss address is, although I've tried some (dumb) things

 

 intiface configuration documentation is very lacking, sadly

I think they just updated their app to 2.0 (not even a month ago) 

 

Im sorry if this is something obvious that I am not noticing, but so far I have not been able to 

 

 

What do you have for the buttplug.io server address value? It should be something like this (Replace the IP with the IP of your phone): ws://127.0.0.1:12345

 

Link to comment
16 hours ago, Min said:

What do you have for the buttplug.io server address value? It should be something like this (Replace the IP with the IP of your phone): ws://127.0.0.1:12345

 

 

It was just the ws:// I think I only missed the colon.

Thank you, it works perfectly and it does what it was supposed to do.

I expected it to have some delay, but it absolutely does not.

 

I will definitely have to tweak the values, otherwise, it works flawlessly.

 

Link to comment
7 hours ago, naaitsab said:

Small headsup on another project that leverages SKSE to interface with the game. Might be a bit quicker than polling log files? If so could be worth a look to implement the plugin approach in GIFT.

 

 

Hey, I saw this. Looks like a cool approach. I'm not going to move GIFT over to it for a few reasons:

1) I'm not super convinced on the speed benefits - I imagine it's faster, but I'm not sure that it's noticabely so. I think most of the delay is likely from Papyrus, which that approach also has to deal with. I'll probably benchmark the two at some point though to figure out how significant this is.

2) It's not game agnostic; I like being able to support multiple games (Even if it's only two, right now).

3) That mod doesn't solve all of our use-cases (Supporting patterns, estim, chaster, etc). I'd need to port GIFT's codebase to C++ in order to have feature parody.

 

 

I do however, think that the approach taken by that mod is superior for really tight usecases, such as movement related triggers (Supported in the current dev version). Anyways, I'm happy to see more work being done on this area, and may take advantage of them for things like this. :)

Link to comment
1 hour ago, Min said:

Hey, I saw this. Looks like a cool approach. I'm not going to move GIFT over to it for a few reasons:

1) I'm not super convinced on the speed benefits - I imagine it's faster, but I'm not sure that it's noticabely so. I think most of the delay is likely from Papyrus, which that approach also has to deal with. I'll probably benchmark the two at some point though to figure out how significant this is.

2) It's not game agnostic; I like being able to support multiple games (Even if it's only two, right now).

3) That mod doesn't solve all of our use-cases (Supporting patterns, estim, chaster, etc). I'd need to port GIFT's codebase to C++ in order to have feature parody.

 

 

I do however, think that the approach taken by that mod is superior for really tight usecases, such as movement related triggers (Supported in the current dev version). Anyways, I'm happy to see more work being done on this area, and may take advantage of them for things like this. :)

I guess 2 is the most 'killer feature'. As the DLL is game and even version specific (looking at you AE)

For 3 it could be a in between, like referencing a DLL in a Windows exe. But that might also nullify any speed advantages over the native Python text reader

 

Any updates on the Estim expansion we spoke about before?

Link to comment
13 minutes ago, naaitsab said:

I guess 2 is the most 'killer feature'. As the DLL is game and even version specific (looking at you AE)

For 3 it could be a in between, like referencing a DLL in a Windows exe. But that might also nullify any speed advantages over the native Python text reader

 

Any updates on the Estim expansion we spoke about before?

Not yet! I haven't been working on the mod recently. I am planning on putting some more work in soon, though. There's another idea that a few of us are playing around with, which would be syncing the vibrations to the animations themselves. I'm likely to work on the estim stuff + this in the next release.

Link to comment
21 hours ago, Min said:

Hey, I saw this. Looks like a cool approach. I'm not going to move GIFT over to it for a few reasons:

1) I'm not super convinced on the speed benefits - I imagine it's faster, but I'm not sure that it's noticabely so. I think most of the delay is likely from Papyrus, which that approach also has to deal with. I'll probably benchmark the two at some point though to figure out how significant this is.

2) It's not game agnostic; I like being able to support multiple games (Even if it's only two, right now).

3) That mod doesn't solve all of our use-cases (Supporting patterns, estim, chaster, etc). I'd need to port GIFT's codebase to C++ in order to have feature parody.

 

I do however, think that the approach taken by that mod is superior for really tight usecases, such as movement related triggers (Supported in the current dev version). Anyways, I'm happy to see more work being done on this area, and may take advantage of them for things like this. :)

 

1) I didn't do benchmarks either, so I don't know how big of an effect it really has on the delay.  It's entirely plausible that the performance difference is neglectable. I think what could cause a difference (in theory) is the delay between logging a debug message and the message being written to the file system. If that is really fast, I don't think there should be much difference, because just observing a file system file for changes (and then doing something) is really fast.

 

When I started Telekinesis I only knew of the old (Skybutt?) implementation from 2014. When I noticed Mins project, my implementation was almost done, so I just figured it would make sense to publish it because of the different approach and not requiring any external applications. Right now I see it merely as a proof of concept/prototype.

 

2) I use CommonLibSSE NG, which (in theory) should have automatic binary compatibility to VR, SE and AE, I didn't test that yet though, because I only run SE with the best of two world patch.

 

3) Buttplug doesn't have a C++ FFI (yet), so you would partially have to use Rust (or use Websockets in C++). To achieve my all-in-one-dll solution I basically had to write parts of the application in Rust. Edit: You can look at what I had to do in my source.

Edited by gerroth
Link to comment
3 hours ago, gerroth said:

 

1) I didn't do benchmarks either, so I don't know how big of an effect it really has on the delay.  It's entirely plausible that the performance difference is neglectable. I think what could cause a difference (in theory) is the delay between logging a debug message and the message being written to the file system. If that is really fast, I don't think there should be much difference, because just observing a file system file for changes (and then doing something) is really fast.

 

When I started Telekinesis I only knew of the old (Skybutt?) implementation from 2014. When I noticed Mins project, my implementation was almost done, so I just figured it would make sense to publish it because of the different approach and not requiring any external applications. Right now I see it merely as a proof of concept/prototype.

 

2) I use CommonLibSSE NG, which (in theory) should have automatic binary compatibility to VR, SE and AE, I didn't test that yet though, because I only run SE with the best of two world patch.

 

3) Buttplug doesn't have a C++ FFI (yet), so you would partially have to use Rust (or use Websockets in C++). To achieve my all-in-one-dll solution I basically had to write parts of the application in Rust. Edit: You can look at what I had to do in my source.

Happy new year!

 

2) Yeah, that should make it compatible with all versions of Skyrim anyways; I also currently support Fallout, and intend to add other entirely new games in the future, since log scraping is such an easy integration point.

 

3) I think it's a cool approach. Like I mentioned previously, I think it's probably a superior approach for things that are short lived / require tight timing (Like movement events). These sorts of events are typically high frequency, and we don't want to spam the log too badly. I could definitely see myself using your mod for those sorts of situations.

Link to comment

Release 1.2.0 is up:

  • Split events out, so that they are no longer hard-coded. Users can now configure what lines trigger what responses from the script via the included yaml files (GUI to come at some point). If you add any cool triggers, please share here! :)
  • Improved pattern support for vibrations.
  • Added support for Movement related triggers. Walking, running, jumping, etc with plugs is now a more stimulating experience!
  •  Added Maximum Strength setting to the DG-Lab. Still limits device output to not exceed safe settings.
  • Added XBox Controllers as a supported device type (Thanks Zoollcar!)
  • Added support for automatic DG-Lab device detection (Thanks Polite Paddemelon!)
  • Added support for playing a sound when stack dumps occur (Thanks Zoolcar!)
Link to comment
1 hour ago, Radahn said:

.io version keeps disconnecting, but I dont know how to connect to the lovense host and make it functional... how do you connect to the lovense host directly without .io? Does lovense connect app on phone work? Explain this pls

 

I just wrote a basic README for the project. Take a look here, and see if this answers your questions: https://github.com/MinLL/GameInterfaceForToys/tree/master

Link to comment
5 hours ago, Min said:

 

I just wrote a basic README for the project. Take a look here, and see if this answers your questions: https://github.com/MinLL/GameInterfaceForToys/tree/master

Yes thanks it answer my question, so it was lovense remote app on mobile as well not lovense connect app which is more basic and not have features... and didnt know about game mode option... Was able to connect it successfully so thanks

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use