EDI is an .exe application, developed in C#, designed to run on Windows as a RestApi and WPF. It should be launched prior to starting the game you wish to integrate with. EDI integrates through buttplug.io with multiple devices and is also compatible with others such as estim audio, the handy, or various Strokes devices. Unlike other software for device integration, EDI relies on pre-written multimedia content (primarily funscript) which can be accessed using names, eliminating the need to handle commands like vibrate, move, or frequency.
EDI performs some main functions:
Connect and control your devices.
Manage and play galleries on the devices.
Receive commands from the game that you want to integrate.
b6a367bb64291429fb67004a34eed0b3433feb74.png (27.36 KiB) Viewed 2493 times
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.
