To update Edi
Due to significant changes, all files must be downloaded again from mega folder and replace it on the existing integration, except for the EdiConfig.json(do not replace it).
EDI is a .exe application, created in C#, that runs on Windows. Created to integrate games with Sex Toys, It should be executed in conjunction with the game you whant to integrate. EDI performs three main functions:
- Connect and control your devices.
- Receive events and commands from the game that you want to integrate
- Manage and play funscripts galleries on the devices.
Download Edi + Example [Videos]
How to Integrate a Game with EDI
new features in the latest version
OSR Multi-axie implemented. Thanks to @to4st for integrating OSR devices with multi-axis scripts after months of work. a big Thanks for his contribution!
12/2024
- fix in https Certificate by To4st, config disable https default true,
- Fixes in OSR devices by to4st, connectivity issue, Rotor devices(beta), extra https port in 5001
- Enhanced Variant Detection: Files and folders are now compatible with OFS, recognizing formats “{name}.{variant}.{axie}.funscript”. [Surge Sway Twist Roll Pitch Vibrate Valve Suction Rotate]
- Intensity endpoint: reduces the intensity (range) of all devices, 0-100%. Allows reducing strokes to 50% or any value from the game.
- Custom Range for devices in EdiConfig.json file.
- Nueva configuracion:
- minRepeatTime: defines the minimum time a script should loop within the Handy bundle. Useful for having scripts with a single stroke.
- motorInertialDelay: adds a delay to vibration channels to compensate for motor startup.
- Device endpoints: list devices, choose variants, and configure ranges via the Api or configuration file.
prev Version
- Auto Blow IA Compatibility Added, put your Key in “Devices Keys”
- “ExecuteOnReady” in config file put the exe path of the game it will AutoStart when device ready
– - Button bar for control and test
- Upload & Download Assets (beta)
– - BundleDefinition.csv Support: Enables large galleries over 1MB to be efficiently managed.
- ‘Resume at Current Time’ Feature: Allows the device to pause while the video continues playing and then resume in sync with the video.
- Automatic Generation of Definition_auto.csv: Now effortlessly created from Funscripts and Chapter information.
Full game Working:
Why use Edi?
Edi has unique features that no other integrator or even videoplayer has.
- Handles all funscripts and plays them on any device
- Allows multiple variants of funscripts (simple, detailed, slow, intense, etc.)
- Upload scripts to Handy for detailed or vibrant scripts
- Multi Device, choose a different Variant for each device
- straight path of workflow based on division of labor
- Ability to expand to new devices non-existent devices
- a SOLID and clean architecture
To integrate a game 3 main tasks must be completed
- make videos with all the elements of the game with funscript.
- Mod the game to report when these elements occur in the game via http post to Edi.
- marks the funscripts with chapters with the names of the elements as they are reported from the game.
how it works
Edi, only has 4 methods
- Play(string Name, long Seek = 0), plays a gallery
- Stop, ends the reproduction of the gallery.
- Pause, completely stops the devices.
- Resumes, replays the last gallery right where you stopped when pausing
from the game that we want to integrate we will only call one of these 4 methods. Therefore, the work that must be done on the game to integrate it is greatly reduced.
the integration with the devices becomes a single output player on which we report events. without more parameters than the name of a specific gallery.
Galleries
To make the galleries of a game, you must first make a video compilation of all the elements of the game that actívate the device, then in a CSV put the name of each gallery in and from what second to what second each element appears in the video, next to the type of gallery and if it is played in a loop.
a gallery is a segment of the video, its name, type and if it plays in loop .
Repositories
the Definition.csv file can be consumed with the DefinitionRepository class.
implementing IRepository you can create repositories for any type of content.
currently exist
- FunscriptRepository, funscripts to consume from various devices, also controls different variants of the same script.
- IndexRepository, compiled and indexed funscripts into a single file for Upload to Handy.
- AudioRepository, MP3 audio tracks for Estim.
it is very easy to create new repositories and can be added later without modifying code or recompiling the solution. allows the decentralized contribution of content created later.
Device Control
all interaction with the device is through pre-written galleries. This means that when one sends a command to the device it is almost always the name of a gallery that must be played. like “sex_scene_mari-1” or “final_boss_fight-3” or “filler-5”. a device implementation within edi must know how to retrieve the gallery and play it. The raw commands of each device, such as vibrate or linear movement, are now restricted to exist only within the implementation of the device, which only receives names of galleries that it must play.
This makes the control of the device totally separate from the integration with the game, so that we could for example to an existing integration that uses edi, add a FullGalleries.mp3 that contains all the galleries of the game to incorporate an eStim device without have to touch the code.
in the same way a new device could be programmed, if in the future someone invents something that directly sends waves to the brain. you could make these waves on the compilation video for all game galleries and incorporate it into an already existing integration by simply leaving files in the folder. without having to program anything extra in the integration or in the game itself.
edi also fix commond issue in funscript players like detailed scripts that Keep playing after he should or múlti device, multi channel capabilities. playing funscripts becomes something now improves with each implementation and not something that each developer does as they can in each integration
the limitation is that you cannot make dynamic content that changes on the fly, everything has to be pre-scripted. However there are ways to get around it, if your galleries have variable speed or intensities, you can pre-procces the galleries with a number of different intensities such as:
Lori_Attack-level-1
Lori_Attack-level-2
Lori_Attack-level-3
Gellery Reaction Filler
In the definitions.csv file there is a “type” field, it can have 3 filler/gallery/reaction values, apart from that we have a “loop” column,
- Gallery, plays immediately when the Play command is sent
- Reaction, is designed for short elements of just a few seconds, which are activated by user actions. it is played immediately when the Play command is sent. when stop if an gallery was playing it will continue playing without losing synchronization. it may not work very well if the device is controlled by the internet has latency.
- Filler, when the Play command is sent, it is not played immediately, when an gallery or a Reaction stops, it starts playing the last filler sent.
Each type can be turned ON and OFF by the user. If you are controlling the device over the internet and there is a lot of latency, you can disable the reactions. Or turn off the filler if you don’t like it.
Loop, applies to all types, if it is marked as true the element will be played over and over again until the Stop method is called. if it is marked as false the element will stop when it completes its reproduction.
