OpenEOS - Open source EOS player

[fapnip]

Open EOS is an open source implementation of Milovana's EOS player. Currently in active development, but should be able to play most existing EOS teases in its current state.

Looking for people to test/debug.

Wiki/Help here:
https://github.com/fapnip/openeos/wiki

Source here:
https://github.com/fapnip/openeos

Demo tease/more information here:
viewtopic.php?f=2&t=23533

[fapnip]

https://www.youtube.com/watch?v=CpGtBnVZLSk

[Triple Alfa]

Don't have the time to check it out right now as it's very late here, but will tomorrow if I remember.
What are the plans for the extended features?
Also, what testing/debugging needs do you have? I have quite some (amateur) experience.

First bug report: Your wiki(https://github.com/fapnip/openeos/wiki) spells Milovana incorrectly in the first sentence

[fapnip]

What are the plans for the extended features?

For now, allowing more flexibility/control for advanced authors via scripting. You can check out the demo tease for some of the things that can be done. Depending on interest, I may add more features.

Also, what testing/debugging needs do you have? I have quite some (amateur) experience.

Just try out teases and find what doesn't work as it should.

First bug report: Your wiki(https://github.com/fapnip/openeos/wiki) spells Milovana incorrectly in the first sentence

Good catch! Fixed.

[Triple Alfa]

Feedback after playing the demo:

The gif integration is very nice and much needed. You also showed well how timing text along with it can be used for greater effect. I do wonder however if you've made it so that text waits for images to load, as that could screw up the timing.
Giving choices the option of being asynchronous is very cool and opens up possibilities.
But I'm most impressed by the "touch"-demo. How do you map the different areas of the image? Do you use a masking image? And how do you get it to recognize her back? Does every frame of the gif have a different mapping? Or is it timing based?

I have to say that something like that was not anything I would have suggested for EOS as I'd assume it out of reach.
So now I really need to think outside the box as well for feature requests.

One thing of note is that I tried to download two of the gifs that were used in the demo. One gave me a gif from an outside source and the other an mp3 file stored here on milovana. I assume that mp3 thing is your current workaround for gifs and not a final solution?


As I am writing this a few possible features pop up in my mind:

1) Use the "touch"-tech to censor images in specific areas. That way the image can be censored in any possible combination of ways without having to manually edit and upload all the images. This is of course most beneficial for images with many such areas as the number of possible combinations grows exponentially.

2) Add the option to make text, of a custom size, appear on top of the image.(Pure text, no background) Possibly with an optional fade in/fade out effect. This would allow for things such as quick commands to the player(without looking away from the image) or a hypnosis/manipulation like effect. I thought of this because giving a player a command such as "Ruin it!" or "Hands off!" while they are cumming and staring at an image is usually tricky as they are slower to read and respond to text at the bottom of the screen. Plus it requires them to look away which is undesirable. This would also combine really well with the gif integration or just in general with anything that requires timing(like a countdown) as the player wouldn't have to take their eyes off the action.

3) It would be cool if you could vary the size of the regular text as well. It would allow for much more emphasis and effect.

4) One cool little thing I've seen used in some visual novels is moving text. For example a word whos letters are waving like a flag in the wind or shaking up and down. This basically brings special effects into the text area.

5) It might be nice to have a command that clears the text off the screen. Currently you can only do this by switching to a different page. Something which is not always a possibility.


As you can tell I'm quite excited by the possibilities. I do wonder though how long you can rely on the current editor. It seems like it might already be a bottleneck for some of the features that exist in the demo.

EDIT 1:

I've just loaded up a regular tease in the OEOS player and one thing that really stands out is the much smaller text than the EOS player. My monitor has a somewhat high resolution at 2560x1440 and the text is hard to read without leaning forward.

EDIT 2 - Bug Report:

The tease that I'm testing is: https://oeos-player-preview.herokuapp.com/?id=47942
The problem that I immediately noticed upon starting the game is that the text advances when it isn't supposed to. In the original advancing the text requires user interaction. This is obviously to give the user time to execute the commands. OEOS advances the text at roughly reading speed which makes this impossible.

[fapnip]

I do wonder however if you've made it so that text waits for images to load, as that could screw up the timing.

There's an onload event so things can wait until the images are loaded. OEOS also does aggressive preloading to try to reduce load wait times.

But I'm most impressed by the "touch"-demo. How do you map the different areas of the image? Do you use a masking image? And how do you get it to recognize her back? Does every frame of the gif have a different mapping? Or is it timing based?

Thanks! It was mainly built as a way to thoroughly test event (load, click) timing.

It's a bit of a hack the way it works. By knowing how long the animation loop runs (2700ms in that animation's case), it's able to estimate what's on the screen when you click. However, the timer and gif can get out of sync, so it restarts the gif after it believes it has run for 5 loops, and also restarts when returning from another tab, etc.

(The only other way to do it is to download and decode the animation in JS, then display it frame by frame. But that's not an option for OEOS, since it doesn't use images from a domain it's able to fetch raw data from.)

So, by now knowing x, y and z (time) of the click, we can check if they are between predetermined values and estimate what was clicked on. (if x between 0.2 and 0.6, y between 0.3 and 0.4, and z between 800 and 1400, then they probably clicked on ...)

Spoiler: show

(BTW: There's a few more gifs you can get to via the hula-hoop girl, depending on when, where and how often you click.)

One thing of note is that I tried to download two of the gifs that were used in the demo. One gave me a gif from an outside source and the other an mp3 file stored here on milovana. I assume that mp3 thing is your current workaround for gifs and not a final solution?

Those are remaining from earlier tests of ways to get non-jpg images up on milovana. Turns out, you can rename them to mp3, and it'll take them, but I don't like that solution. (They won't work in a non-oeos tease, so everyone; please don't do it!) Instead, I've been uploading them to imgbb.com, and linking to those images. I should probably replace the remaining mp3 link hacks with imgbb links.

As I am writing this a few possible features pop up in my mind:

1) Use the "touch"-tech to censor images in specific areas. [...]

2) Add the option to make text, of a custom size, appear on top of the image. [...]

3) It would be cool if you could vary the size of the regular text as well. [...]

4) One cool little thing I've seen used in some visual novels is moving text. For example a word whos letters are waving like a flag in the wind or shaking up and down. This basically brings special effects into the text area.

5) It might be nice to have a command that clears the text off the screen. Currently you can only do this by switching to a different page. Something which is not always a possibility.

I'm currently adding the ability for limited (to prevent nefarious authors from exploiting XSS) DOM manipulation from the interpreted/sandboxed tease script. Once that's done, all the above and more will be possible, given enough motivation from the tease author. Unfortunately, adding it to the editor is another story...

As you can tell I'm quite excited by the possibilities. I do wonder though how long you can rely on the current editor. It seems like it might already be a bottleneck for some of the features that exist in the demo.

The current EOS editor, and milovana's image hosting limitations, are relatively large obstacles. Unless seraph0x decides to embrace OEOS, I'd probably need to write my own editor and figure out some other hosting options for media, but I'm not sure there's enough interest in OEOS to warrant it. Plus, I don't want to stick my finger in seraph0x's eye.

[Triple Alfa]

This may be a bit far away from your original idea, but the easiest solution to all these problems is to make it a local viewer instead. That way it could load whatever you wanted as files are stored locally. It could also open up the possibility of displaying videos as you would not be limited by hosting services and bandwidth. Of course you would lose the flexibility of an online service, but without the aid of seraph0x I don't really see how you could get reliable and fast hosting without significant investment.

Just a quick note, incase you didn't notice, I edited my previous post twice to give feedback.

[fapnip]

EDIT 1:

I've just loaded up a regular tease in the OEOS player and one thing that really stands out is the much smaller text than the EOS player. My monitor has a somewhat high resolution at 2560x1440 and the text is hard to read without leaning forward.

Adjusted the font a bit. Let me know if it helps.

EDIT 2 - Bug Report:

The tease that I'm testing is: https://oeos-player-preview.herokuapp.com/?id=47942
The problem that I immediately noticed upon starting the game is that the text advances when it isn't supposed to. In the original advancing the text requires user interaction. This is obviously to give the user time to execute the commands. OEOS advances the text at roughly reading speed which makes this impossible.

Thanks for the report! Looks like I had my autodetect mode use "autoplay" (try to estimate how long it'll take to read) when the next action is a say. Switched it to "pause" to match EOS.

[fapnip]

This may be a bit far away from your original idea, but the easiest solution to all these problems is to make it a local viewer instead.

Some other developers have expressed interest is using OEOS as a basis for their offline EOS players, and I think it would be a great addition. However, I think the ease of access for online players is required.

but without the aid of seraph0x I don't really see how you could get reliable and fast hosting without significant investment.

Unless trying to host video, cost for hosting images isn't that big of a deal -- the main problem is liability. That said, if I did set this up on my on host, I'd probably just use imgbb.com for hosting the images and require authors to get their own account/api key from there and enter it in to OEOS, letting imgbb.com deal with all the takedown requests. (I'm sure I'd have to forward a number of them.) Not sure what to use for audio/video. redgif,com may work for video, but no API yet -- and I'm not sure they support direct linking.

However, creating an EOS editor clone, plus the back-end to support it, isn't exactly a small task. I'd like to see what kind of support the player gets first.

Just a quick note, incase you didn't notice, I edited my previous post twice to give feedback.

Yes! Thank you! Keep them coming!

[Triple Alfa]

It's great to see that you already have some possible solutions for the hosting issues.
One thing that I would recommend to alleviate some of the audio pressure is the integration of commonly used audio cues such as metronome sounds, slaps, whips, etc. Not only would this make it a lot easier for creators, but it would also lower the priority for custom audio support a lot.

I just opened the same tease again as before to check on the text and I don't really see much of a difference. It is still significantly smaller than the EOS version I have open in another tab.
The problem with the automatic text advancing seems to be gone.

Edit 1:

An interesting difference I just noticed between EOS and OEOS is that OEOS has a (disabled) scrollbar on the right. I'm not sure if there are situations where it is actually useful, but it does screw up the centering on the screen and looks a lot less nice.

One minor detail that could be improved is the smoothness of the text rising from the bottom of the screen. In EOS it's perfectly smooth while OEOS has a faster, slightly more jarring, application.

Bug Report: After entering text in a prompt the output text shown in the faded out textbox is in ALL CAPS even though only the first letter of the entered word was capitalized.

Edit 2:

Bug Report: A timer that started at one minute was shown as 0:60 instead of 1:00.

Edit 3:

Bug Report:
I am testing this tease https://milovana.com/webteases/showtease.php?id=47926
After a short introduction there is a one minute timer for stroking purposes. After that timer the sentence "Now stroke at a medium speed for my thighs" is shown. In EOS the following timer is started automatically in OEOS it does not start without player interaction. The same is true for the sentence and timer after that. It seems like it is true all the way until the next button. EOS requires no interaction at all OEOS requires constant interaction.
The problem also persists after the next button.

[fapnip]

integration of commonly used audio cues such as metronome sounds, slaps, whips, etc. Not only would this make it a lot easier for creators, but it would also lower the priority for custom audio support a lot.

That's not a bad idea. Would need to write an editor first before I could add in easy actions for pre-built sounds, but it would be nice to have a selection of built-in sounds and patterns.

It is still significantly smaller than the EOS version I have open in another tab.

Funny story... The EOS browser tab I was using as a reference for OEOS was set to 80% zoom. No wonder EOS looked so small to me. Made some more adjustments.

OEOS has a (disabled) scrollbar on the right

Default browser behavior. Should be hidden now.

output text shown in the faded out textbox is in ALL CAPS even though only the first letter of the entered word was capitalized

Thanks. Should be fixed now.

Keep them coming!

[Triple Alfa]

Funny story... The EOS browser tab I was using as a reference for OEOS was set to 80% zoom. No wonder EOS looked so small to me. Made some more adjustments.

That actually made me laugh.

I made a bunch of edits again to the other post. Don't want to keep replying to myself for every bug I find.

Bug Report?:
It might be an optical illusion because OEOS uses a grey background for the text instead of a black background, but it looks like the color of the text is not the same as in EOS. This is troublesome even if it is an illusion as, at least currently, teases are created in the EOS editor and thus optimized to look good in the EOS environment.
Personally I also think the black EOS background looks better than the grey OEOS background as it makes the text pop out more.

[fapnip]

A timer that started at one minute was shown as 0:60 instead of 1:00.

Thanks. Should be fixed on next release.

EOS the following timer is started automatically in OEOS it does not start without player interaction.

Another issue related to the wrong decision for a Say's auto mode. Should always be instant if the next command is a timer now.

It might be an optical illusion because OEOS uses a grey background for the text instead of a black background, but it looks like the color of the text is not the same as in EOS.

Default text color in OEOS has a slight transparency to it instead of a hard-coded gray like EOS. This is to account for adjustable say bubble background colors in OEOS. Made it a little less transparent and forced default background to black. Let me know if it helps.

[fapnip]

smoothness of the text rising from the bottom of the screen. In EOS it's perfectly smooth while OEOS has a faster, slightly more jarring, application.

Adjusted scroll speed in v0.5.5

[fapnip]

Fixed recently introduced audio bug. (Sounds wouldn't work in many cases.)