Easy Device Integration for Games. EDI - Handy FW4 (BLE) & (Http) - VacuGlide2 (07/2026)

[dimnogro]

EDI is a .exe application, created in C#, that runs on Windows. Created to integrate games with Smart Sex Toys, It should be executed in conjunction with the game you whant to integrate. EDI performs three main functions:

1. Connect and control your devices.
2. Receive events and commands by Http from the game that you want to integrate
3. Manage and play funscripts galleries on the devices.

---

A new version of EDI is here. With the help of Codex, I was able to thoroughly debug it and resolve synchronization issues that had been present since the beginning of the project.

I’ve also added support for Handy Firmware 4, including Bluetooth connectivity. It was incredibly exciting to finally trigger reactions over BLE with no lag at all—even on my oldest Handy, a 2020 model running FW4. Everything now works flawlessly, and loops restart perfectly without skipping.

CAUTION— HANDY FW4 BLUETOOTH

BLE is now the best way to use a Handy running FW4 with EDI.

Do not let Intiface detect the device. Make sure EDI connects to it directly and that (BLE) appears at the end of its name, as shown in the screenshot. Otherwise, the device may connect through a legacy Bluetooth mode that suffers from the same issues as the previous Bluetooth implementation.

---

To update Edi
Downloaded Edi.exe from mega folder.

Download Edi + Example [Videos]

How to Integrate a Game with EDI

Changelog

[Version 1.0.2]

New Features

• Added Handy firmware v3 support through the HSP protocol.
• Added direct Handy Bluetooth Low Energy connection and automatic rediscovery.
• Added AutoBlow and VacuGlide 2 automatic detection and playback support.
• Added configurable device offset for Handy, AutoBlow, and VacuGlide 2.
• Added OBS recording integration to generate chapter-based funscripts.
• Added multiple configurable funscript recorders with channel and variant support.
• Added a saved game manager to add, rename, edit, remove, and switch games.
• Added per-channel playback preview and recorder controls.

Improvements

• Redesigned the WPF interface for better accessibility and playback control.
• Improved Handy v3 synchronization, time handling, reconnection, and legacy looping.
• Improved recorder output for seek, loop, range, variant, and gallery transitions.
• Galleries and repositories can now reload on demand without restarting EDI.
• Improved device lifecycle, asynchronous playback, and multi-channel synchronization.
• Added automatic UI migration for previously saved games.
• Added extensive automated coverage for devices, galleries, players, and recorders.

Bug Fixes

• Fixed device reconnection and cleanup across supported providers.
• Fixed empty OSR UDP addresses being treated as valid endpoints.
• Fixed preview range, variant, channel, and gallery refresh behavior.
• Fixed overlapping playback commands, stale timers, and pause/resume race conditions.
• Fixed application and preview window shutdown synchronization.

Contributors

• @to4st: initial OBS chapter generator, configuration, and chapter filtering.
• Kevin Liu / Seele-Vollerei32: WPF accessibility redesign and OSR UDP validation fix.

Old Changelog

[Version 1.0.1]

• Fix Expoces all files in gallery folder into Edi/Assets/[FilePath]

[Version 1.0.0]

New Features

• Implemented game selection system:
  • Select game via EdiConfig.json or Definitions.csv
  • Game configuration via EdiConfig.json
  • User configuration via UserConfig.json (located in AppData)
• Added UDP connection support for OSR devices (@to4st)
• Added Pause (?untilResume=true): ignores all play commands until /Resume, keeping sync with the last received play event
• Added “Always on top” option to the preview window
• Multi-channel system (Beta):
  • In EdiConfig: UseChannels=true and Channels=[player1, player2] (e.g., stroker, buttplug)
  • Each channel works as an independent EDI playback: gallery, filler, reaction
  • Devices can be assigned to a specific Channel
  • Playback endpoints now accept optional ?Channels=player1
  • No channel parameter → applies to all channels
• New AI endpoint and configuration (Beta)
• Various minor stability fixes
• Fully refactored playback system (Player)

Improvements

• Optimized loop detection for Funscripts

• Improved logging system:

  • Logging added to players
  • Better event tracking

• Improved bundler folder management

Games in Game Mod cateogory

GitHub - NoGRo/Edi: Easy Device Integrator

Full Feature Description

Easy Device Integration (EDI) for Videogames

Easy Device Integration (EDI) is a Windows application developed in C# that synchronizes game events with interactive sex toys. Its modular and simple architecture makes it a powerful, flexible, and easy-to-integrate tool for any game.

---

Why Use EDI?

• Compatible with Buttplug.io, Lovense, OSR, XToys, eStim via mp3 file, Handy, AutoBlow, and more.
• SOLID architecture decoupled from the game engine.
• Simple HTTP API control (Play, Stop, Pause, etc.).
• Expandable galleries synced to a single video.
• Multi-device, multi-axis support, and customizable variants.
• Smooth and synchronized funscript playback within your game.

---

Gallery Types in EDI

This section describes how EDI handles different types of galleries, which represent key game moments that trigger device actions.

• Gallery: main type. Plays immediately with Play, used for primary or long scenes.
• Reaction: short events or quick responses (e.g., clicks, hits). Plays instantly and then EDI resyncs with the previous gallery.
• Filler: plays when no other gallery is active, simulating background or passive motion.

All types support the loop property as true or false.

---

Key Integration Features

Gallery Definition

• Galleries are defined using a Definition.csv file, chapters in OFS, or can be auto-generated as definition_auto.csv based on filenames.
• Auto-generation can be enabled in the config file (EdiConfig.json ).
• Supported types: gallery, reaction, filler.
• If no type or loop is specified, EDI assumes gallery with loop = true.
• You can also define gallery types using tags in the file name to avoid editing the CSV manually.

Chapters or Filename Tag Examples:

• filler_3[filler].funscript → type filler, loop true
• golpe_critico[reaction][nonLoop].funscript → type reaction, loop false
• go_home[filler][nonLoop] → chapter of type filler, loop false

Tags can be placed in any order and override default behavior.

Gallery Variants

• Variants can be defined in the filename (enemy_attack2.intense.funscript) or in the containing folder (intense/enemy_attack2.funscript).
• Variants can also be defined per device (e.g., enemy_attack2.vibrator.funscript).

Multi-Axis Support

EDI allows full use of multi-axis or multi-motor devices via naming conventions in funscript files.

• Axes are declared in the filename: .linear, .twist, .roll, .vibrate, etc.
• EDI auto-detects and applies these axes for compatible devices like OSR.

Examples:

• ataque_fuerte.intense.linear.funscript → variant intense, axis linear
• ataque_fuerte.intense.twist.funscript → axis twist

---

Bundle Management for Handy and AutoBlow

EDI groups all galleries into bundles for efficient loading into devices like Handy and AutoBlow.

• Bundles reduce latency by grouping related galleries.
• Defined in BundleDefinition.csv under C:\Users\{User}\AppData\Local\Edi
• The default bundle contains all galleries not explicitly grouped.
• When a gallery from another bundle is needed, EDI uploads that bundle dynamically.
• A gallery can be in multiple bundles (useful for filler or reaction).
• If a bundle exceeds 1MB, split it into smaller ones.

Example:

-Intro
intro1
intro2

-Missions
attack1
attack2
reaction_click

---

Configuration File (EdiConfig.json)

Gallery Section

• GalleryPath: folder path containing funscripts.
• GenerateDefinitionFromChapters: true to generate Definition.csv from chapters.
• GenerateChaptersFromDefinition: generates chapters from Definition.csv.

GalleryBundler Section

This section controls auto-repeat and timing between galleries. All values are in milliseconds.

• MinRepeatDuration: minimum time before a command is resent to the device (e.g., Handy) during loop (increases bundle size).
• RepeatDuration: extra duration to offset lag between commands (increases bundle size).
• SpacerDuration: pause between one gallery ending and the next starting (does NOT increase bundle size).

Edi Section

• Toggle active gallery types: Filler, Gallery, Reactive
• ExecuteOnReady: launches the game when EDI is ready.
• UseHttps, UseLogs: debugging and security options.

Devices Section

• Devices are configured individually by name.
• You can assign a Variant, and define Min and Max intensity.

---

HTTP API Control

This API lets your game control playback, intensity, and device settings using simple HTTP commands. All endpoints accept both POST and GET requests.

Playback

• POST /Edi/Play/{name}?seek=0: plays a gallery by name, optionally from a specific point (milliseconds).
• POST /Edi/Stop: stops current playback.
• POST /Edi/Pause: pauses device output.
• POST /Edi/Resume?AtCurrentTime=false: resumes from pause. With AtCurrentTime=true, syncs to current video time.

Intensity

• POST /Edi/Intensity/{max} (0–100%): sets global intensity across devices.

Devices

• GET /Devices: lists connected devices.
• POST /Devices/{deviceName}/Variant/{variantName}: assigns a variant to a device. Using None stops that device.
• POST /Devices/{deviceName}/Range/{min}-{max}: sets device intensity range. If both values are 0, the device is stopped.

Content

• GET /Edi/Definitions: returns all available galleries.
• GET/POST /Edi/Assets: upload or list funscripts and audio files.

---

Graphical Interface (EDI Launcher)

EDI includes a user-friendly GUI to manage essential functions easily.

• Select connected devices and assign variants.
• Toggle active gallery types: Gallery, Filler, Reaction.
• Adjust intensity with slider.
• Manual playback controls.
• Live preview of device response, useful for testing without hardware.
• Link to API Swagger for testing and debugging.

Device Control Model in EDI

All interaction with devices in EDI is handled through pre-written galleries. When a command is sent to a device, it’s almost always the name of a gallery, such as sex_scene_mari-1 , final_boss_fight-3 , or filler-5 . Each device implementation within EDI knows how to retrieve and play that gallery.

Raw device commands like vibrate or linear movement are isolated inside the device implementation. The game never needs to issue low-level commands—just the gallery name.

This architecture makes the control layer entirely independent from the game itself. For example, one can add a full set of galleries in a FullGalleries.mp3 file to support an eStim device without touching the integration or modifying any code.

The same principle allows adding future devices (e.g., a brainwave stimulator) by simply preparing galleries and placing files in the folder—no code changes needed.

EDI also solves common funscript playback issues like overly persistent strokes or inconsistent behavior across devices. Since devices all use the same unified player, improvements benefit all integrations automatically.

Limitation: EDI cannot play dynamic content. Everything must be pre-scripted. However, this can be worked around by preparing multiple gallery variants with varying intensities, such as:

• Lori_Attack-level-1
• Lori_Attack-level-2
• Lori_Attack-level-3

---

[99DM]

My gameCG scripting wasn’t in vain!!!

[99DM]

I have a question

Can it apply it to the visual Nobel part?

For example, in the case of milking farm, in addition to moving scenes, there are parts with pictures&text

Can it be applied in a way that calls pictures or certain voice mp3?

[dimnogro]

Yeah! Ideally you can report anything you want to edi and it would only react to events that are defined in the csv.
In any case, you still have to mod the game so that it reports those events interfering key methods. something that I had thought to apply in Maga, was to interfere with the dialogue scenes and that each enemy has its own filler when speak

[dimnogro]

@Falafel, I answer you here. Yes, it would be a problem if your script is one second long and you have a 500ms delay, it will reproduce badly, so if a gallery lasts a few seconds and does not loop, you should mark it as reaction type, so the user could disable reactions if they have a lot of latency.
that is exactly why the reaction type exists

[funscriptguy]

Hoping to see some more game integrations real soon!

[Midevil]

would this in theory work with https://discuss.eroscripts.com/t/game-integration-pure-onyx-buttplug-intiface-integration/108156/11 ?
@dimnogro

[batmaee]

Stoked for this to get implemented into some of the stuff already on here, great work!

[dddddddsdfsdf]

From what I read from the author’s above posts, I don’t believe so. Pure Onyx’s animations seem to be looping <1 second animations with semi random varying speeds. So I’m unsure of the effectiveness of calling predefined scripts for this game.

[dimnogro]

yes, in theory can use edi inside de integration to replace the current divice control method
if this method has names of individual animations, could use edi

[dddddddsdfsdf]

getting animation names should be no problem, I mainly have two concerns: How can edi handle a single animation that has changing playbackspeeds and what would be the easiest way to compile all the unity animations(I have a very surface level understanding of the systems)?

[dimnogro]

well precisely the limitation of edi is the interpolated content. but there are still things you can do to cope with it.
For example, you can pre-process the scripts at 3 or 4 different speeds, and use the one that best suits the playback.
like:
Lori-Attack-punch-speed_1
Lori-Attack-punch-speed_2
Lori-Attack-punch-speed_3 …
also if you are hacking into the game maybe you could even adjust the speed in the game so that it matches the speed of the scripts

As for the assets, most of the cases someone already made the compilation and uploaded it to pornhub or something like that hehe.
I actually found this in a few seconds https://es.pornhub.com/view_video.php?viewkey=ph63a26d5644dd9 I’m pretty sure someone in the community would be willing to do the script.
If that was what you were asking me, you should make a definition.csv for this file, marking the milliseconds of each asset and the name with which it appears in the game.

[dddddddsdfsdf]

I was hoping there was a way to extract the animations, since finding start/end points in this case will be a bitch, but I guess I’m not that lucky. I’ll dig down and do some more research since scripting seems to be the best way to improve quality. As well as look into hacking the speeds to be more normalized as well, didn’t consider that.

thanks for the help and making the tooling big dawg

[dimnogro]

ooh i see, yes in fallen angel I used a few lines of code making send key to go through the galleries in a programmed way while recording the screen with obs streamlabs. unfortunately I lost that code.

another advantage of edi is the division of labor. with the complete gallery video someone could do the funscript in any time. and then you can tune the definition file to fit.

we should do the integration with onyx it would be great, the game uses unity. so having edi on uniti will be useful for many more games.
It would also be great if you manage to interfere with the damage receives, it would be spectacular like vibration in every puch recibed lol

[dimnogro]

It seems to me that it is time to make the games category outside of the software category. Can someone tag an admin?

[hugecat]

imo this still belongs in the software category, and I just made a separate Game mod category just for the modded games. This is a software tool for modding games.

[dimnogro]

Edi launcher is already taking shape and begins to show capabilities never seen before
how to select different funscripts for individual vibrators on the same device

[Wilmer]

[smeedler]

this tool looks great, I just haven’t the slightest idea on how to mod the games I’d like to attempt to use it with (nscripter, era)

[dimnogro]

this is getting serious