[commission/paid] interface for connecting sexlab events to external apps

[outskirts1794]

Hello,

 

I've been exploring MinLL's GIFT. It's a python application that tails (follows) the papyrus log file to identify devious events, sexlab events, etc then interacts with various real-world toys. In order to accomplish that he created a small script-only mod that logs additional data.

 

I'm looking to either extend his mod/script or create a new one with more features.

 

Ideas for updating / extending his script:

• Update compatibility with sexlab variants like P+ (not sure if this is already the case, doesn't seem to work for me though)
• Log to a different file than papyrus.log
• Extend sexlab scene logging to add tags, species, and stage information
• Log orgasm events (both for player as well as other parties e.g. cum in player's orifice)
• Log device equipment changes e.g. plug insertion/removal
• MCM config?

 

If you're interested in helping let me know - we can talk specifics. As mentioned in the title I'm willing to pay for work on this.

 

Edited June 14 by outskirts1794

[traison]

On 6/14/2026 at 8:17 PM, outskirts1794 said:

Log to a different file than papyrus.log

 

This will require a dll. A build for every supported game variant (Steam, GOG, VR) and version (1.5.*, 1.6.*).

 

On 6/14/2026 at 8:17 PM, outskirts1794 said:

Extend sexlab scene logging to add tags, species, and stage information

 

Writing things to a log, then polling it like every .1 seconds to react to events is going to be inefficient and prone to errors. Doing IPC through UDP/TCP, a named pipe or memory mapped file is the way to go.

 

On 6/14/2026 at 8:17 PM, outskirts1794 said:

Log orgasm events (both for player as well as other parties e.g. cum in player's orifice)

 

SL itself is not aware of who is cumming where. It's a weird oversight IMO. I have a large function written in Papyrus that tries to estimate it, but there's still plenty of situations where it would get it wrong. PPA might expose a Papyrus API at some point which would know the answer to this, but that doesn't really help a dll mod any.

 

On 6/14/2026 at 8:17 PM, outskirts1794 said:

MCM config?

 

SKSE Menu Framework would be better for a dll, as it cuts out the Papyrus middleman.

Edited June 16 by traison

[outskirts1794]

@traison thanks you that's super helpful!

 

Sounds like a DLL would be the way to go. That would mean SKSE plugin, correct? I agree IPC would be preferable, just didn't know how feasible that is for a skyrim mod.

 

So I guess the revised plan would be

• Update compatibility with sexlab variants like P+ (not sure if this is already the case, doesn't seem to work for me though)
• Expose events via IPC. (I'm ok with any of your suggestions. Perhaps websocket would make sense)
• Extend sexlab scene logging to add tags, species, and stage information 
• Log device equipment changes e.g. plug insertion/removal
• SKSE Menu Framework config

 

Are you interested in this, or just providing feedback? Either way, thank you!

Edited Tuesday at 02:51 PM by outskirts1794

[traison]

15 minutes ago, outskirts1794 said:

That would mean SKSE plugin, correct?

 

CommonLibSSE, unless you for some reason like manually building a dll for every...single...game...version.

 

There is also FISSES which as far as I know allows full file IO from Papyrus. While this could probably be used to brick Windows and install viruses, it could also be used to write to a custom file that can be polled by external applications. Not ideal I'd say because of the polling, risk of reading partial messages (depending on how flushing is implemented and what the risk of a race condition is) and extreme security implications. But something like this might let you implement this idea entirely in Papyrus; barrier to entry would be significantly lower. FISSES has 2.5 million downloads, so clearly the vast majority of the Skyrim community does not care about my concerns.

 

16 minutes ago, outskirts1794 said:

I agree IPC would be preferable, just didn't know how feasible that is for a skyrim mod.

 

Well, that's the correct way of doing it. But lets put it this way, if I installed Community Shaders and then got shown a network access warning from my software firewall when launching Skyrim, I'd probably be shutting down my system in a hurry to do a malware scan or system restore. IPC or not, something like that might be difficult to explain. So maybe not a network port, but rather some other form of IPC would be better.

 

26 minutes ago, outskirts1794 said:

Are you interested in this, or just providing feedback?

 

No time for this unfortunately. I just dropped my initial thoughts.

[outskirts1794]

Thank you for your replies.

 

Actually I can probably do all the c++ work myself I'm just not familiar with papyrus and the skyrim-specific stuff. Getting a decent dev environment up and all the dependency sources seems tricky.

 

I guess I'll try and figure it out.

[traison]

Considering how annoyingly difficult it is to set up a bidirectional asynchonous named pipe server in Windows, if someone wants to pick this project up I suppose I can share my server written in C#. While I recall my server could technically do multi-client as well, there's something about the fundamental design of named pipes that just does not support this. There's many examples online, including from Microsoft, that seem to claim they can do this but they really don't. So while my server code is currently sitting in the "not recommended" category of my code database, I still (to my knowledge) have one of the most capable implementations.

 

For one-to-one async duplex communication named pipes are fine. Python can do pipes as well.

 

Edit: ...and pipes can be exposed over the network through some RPC service.

Edited Tuesday at 03:27 PM by traison

[outskirts1794]

I spent a considerable amount of time last year trying to get named pipes to work on windows properly with a godot project and I came to the same conclusion you did. They're just very difficult to work with. A far cry from what I'm used to on linux.