Thank you for sharing the extra details; they were really helpful.
I managed to implement EDI successfully into my latest game integration. I’ve also included some infos and comments in the code, for those who are interested.
https://discuss.eroscripts.com/t/dieselmine-milking-farm-succubus-farm/117745
True to its name, using EDI was rather straightforward and the extra features it offers, are great.
I do have a few remarks and possible requests based on what I noticed tho:
-
It appears that when the “Reload Gallery” option is used (more than once), the program stops responding or crashes.
-
It would be great to have some logging functionality. For instance, in FunscriptPlayer, there was at least a “Status” message that showed the name that the injected code was able to pull, or whether it was detecting anything at all. I have now integrated a local logging for the detected gallery names and EDI-Server requests, but it would be nice to have something like this natively integrated, maybe in the Swagger UI.
-
Another small idea is to have a different “definitions.csv” file for each gallery variant. The way I see it, EDI offers three main scripting approaches for the gallery:
a. Combining all scenes into a single video and making a long script.
b. Dividing the script into multiple parts (like one for each game stage).
c. Making several smaller scripts for each animation.
Since different users might prefer different scripting methods for the same game, having separate .csv files for each variant ensures all versions can be used.
There are many games that already have most of their animations as separate video files. So I was able to create an automation script that generates the .csv file and allows for each case to be easily generated as well. -
Probably an issue with the transmission limitation, but if a bluetooth connection is used and the script is too detailed, it will cause big delays on the EDI itself, where even the processing of the http calls (start/stop, ect.) will lag behind and are perform later than they should.
-
The “pause” function stops the device, but actually continues playing the script in the background, essentially skipping parts of it, instead of completely staying idle. I’m not sure if that’s intentional.
The current issue with this is, if the pause duration lasts longer than the actual script duration for that part, EDI will crash. I’m guessing since the pause only stops the playback and not the script seeking, when it tries to resume, it calls a seek time that doesn’t exist and the program doesn’t like that.
Regardless, the function itself can be useful in some cases, but would need to be fixed, and having an option to completely halt the script temporarily and then seamlessly resume where it left off, would be great as well (especially for game pausing, etc.).
Thanks again for this awesome tool. I’m looking forward to hopefully seeing more game integrations with it soon 