OpenEOS - Open source EOS player

[Triple Alfa]

Bug Report:
When I just started https://oeos-player-preview.herokuapp.com/?id=47926 the first text bubble was hidden. I had to scroll down to see it. I've seen this error before, but just like then I cannot reproduce it by reloading the page or opening a new tab and starting it there.

The text colors look the same now and the background looks much better. Might I suggest you also make the background of the buttons and prompts a darker grey to achieve the same effect. (Or consider adding a gradient effect like EOS uses)

Could you try making the size of the text(and button text) just a bit larger? I still find the EOS version easier to read.

I'm actually unsure about your implementation of a much smaller timer. It opens up more real estate for wide images, but it makes it more difficult to glance over on larger screens. After a bit of testing I find the EOS version more comfortable if I only move my eyes. The OEOS version requires me to move my eyes uncomfortably far, thus encouraging me to move my head. The EOS version is also positioned further away from the corner which adds to the difference.

Edit 1:

I just thought of something. Would it be possible to use evals to execute code that only works in OEOS? This way you could use the existing editor and still enable all kinds of extra features.

Edit 2:

After looking at it a few times now I think the opening title screen should be centered in the middle of the screen rather than at the top.

Edit 3:

I just opened https://oeos-player-preview.herokuapp.com/?id=47978 and the same bug occurred as before where the first textbox was hidden and required scrolling down to become visible. Again reloading the page or loading it in a new tab did not reproduce the problem. I did notice when I reloaded the page the first time that the text seemed to have its spacing adjusted after becoming visible. So the letters were closer together on load and then visibly moved further apart.

Edit 4:

Bug Report:
Twice now I've seem a visual glitch where there are two transparant horizontal grey bars across the entire screen that appear and disappear for about half a second. It happened on loading the first image just now.

[fapnip]

When I just started https://oeos-player-preview.herokuapp.com/?id=47926 the first text bubble was hidden. I had to scroll down to see it. I've seen this error before, but just like then I cannot reproduce it by reloading the page or opening a new tab and starting it there.

I've noticed this as well. Still trying to get to the bottom of it.

Might I suggest you also make the background of the buttons and prompts a darker grey to achieve the same effect. (Or consider adding a gradient effect like EOS uses)

Probably wont add a gradient, since I don't like the way that looks. I may change the default BG color slightly, but it needs to be different enough from the default say background.

Could you try making the size of the text(and button text) just a bit larger? I still find the EOS version easier to read.[/quote]
I've always found the EOS font size a touch too big, especially when trying to fit enough verbiage in the small space below the image before being masked, especially on smaller screen devices. I going to leave it at 1rm instead of 1.1rem for now, just to see how many more complaints I get.

I'm actually unsure about your implementation of a much smaller timer. It opens up more real estate for wide images, but it makes it more difficult to glance over on larger screens. After a bit of testing I find the EOS version more comfortable if I only move my eyes. The OEOS version requires me to move my eyes uncomfortably far, thus encouraging me to move my head. The EOS version is also positioned further away from the corner which adds to the difference.

Made a couple adjustments to the timer's display. I'd like to keep it smaller, again because covers up a great deal of the image on, say, a phone. I may eventually make it responsive -- larger, increased margin, when there's more room, less when there's not. I also plan on giving authors more control over timers (position, size, color, stroke width, etc.)

I just thought of something. Would it be possible to use evals to execute code that only works in OEOS? This way you could use the existing editor and still enable all kinds of extra features.

That's currently possible by wrapping your expressions in an if:

Code: Select all

if (pages.oeosVersion) {
  ... do oeos stuff ...
}

Or, if dependent on a particular version of oeos:

Code: Select all

if (pages.oeosVersion && pages.oeosVersion('0.5.0') >= 0) {
  ... do oeos 0.5.0 or greater stuff ...
}

[Triple Alfa]

As always more edits above ^^^^

Bug Report:
In tease https://oeos-player-preview.herokuapp.com/?id=47978 after a short introduction the Lisa character asks you to beg. After clicking that button EOS continues automatically after the following text "AGAIN LOUDER". OEOS does not.

[Triple Alfa]

I've always found the EOS font size a touch too big, especially when trying to fit enough verbiage in the small space below the image before being masked, especially on smaller screen devices. I going to leave it at 1rm instead of 1.1rem for now, just to see how many more complaints I get.

You're already gaining a lot of space by having much smaller spacing between the elements and between the bottom elements and the edge of the screen. I do understand your point though. It's tough to balance between large high resolution PC screens and tiny phone screens.

That's currently possible by wrapping your expressions in an if:

Code: Select all

if (pages.oeosVersion) {
  ... do oeos stuff ...
}

Or, if dependent on a particular version of oeos:

Code: Select all

if (pages.oeosVersion && pages.oeosVersion('0.5.0') >= 0) {
  ... do oeos 0.5.0 or greater stuff ...
}

That's really cool as that makes it quite easy for creators to use simple features such as the special sounds I suggested earlier. Even if you are not familiar with coding you could just copy-paste a standard code snippet and it just works.

[fapnip]

After looking at it a few times now I think the opening title screen should be centered in the middle of the screen rather than at the top.

I was wondering if that would bother people. I'll get to it eventually.

Twice now I've seem a visual glitch where there are two transparant horizontal grey bars across the entire screen that appear and disappear for about half a second. It happened on loading the first image just now.

What browser? Do you have the developer console open (cache disabled)? (If cache is disabled, I would expect to see issues like that. OEOS is very dependent on browser caching, and requires it for preloading. I'm not positive, but it sounds like you're seeing the background texture image load.)

[Triple Alfa]

What browser? Do you have the developer console open (cache disabled)? (If cache is disabled, I would expect to see issues like that. OEOS is very dependent on browser caching, and requires it for preloading. I'm not positive, but it sounds like you're seeing the background texture image load.)

I'm running Chrome Version 87.0.4280.88 (Official Build) (64-bit)
I did not have the dev console open.
Where do I check if cache is enabled?

Edit 1:

It might be important to note that I'm running in incognito mode.

[notSafeForDev]

Alright, I'm sold after seeing proper support for gifs.

Rather than making a completely new editor to support new features, perhaps we could use something like tampermonkey to add to the existing one:

Code: Select all

// ==UserScript==
// @name        New script - milovana.com
// @namespace   Violentmonkey Scripts
// @match       https://milovana.com/eos/editor/*
// @grant       none
// @version     1.0
// @author      notSafeForDev
// @description Adds additional fields to the EOS editor to support OpenEOS features: https://milovana.com/forum/viewtopic.php?f=26&t=23558
// ==/UserScript==

let lastPageText = "";

onRequestAnimationFrame();

function onRequestAnimationFrame() {
  requestAnimationFrame(onRequestAnimationFrame);
  
  const loader = document.getElementsByClassName("MuiCircularProgress-root")[0];
  if (loader !== undefined) {
    return;
  }
  
  const page = document.querySelector("#root > div > main > header > div > h6");
  if (page !== null && page.textContent !== lastPageText) {
    lastPageText = page.textContent;
    onPageEnter(page.textContent);
  }
}

function onPageEnter(pageTitle) {
  const actionTitle = document.querySelector("#root > div > main > div > div > div.MuiGrid-root.MuiGrid-item.MuiGrid-grid-xs-12.MuiGrid-grid-md-7.MuiGrid-grid-lg-6 > div > div.MuiCardHeader-root > div.MuiCardHeader-content > span");
  
  if (actionTitle !== null && actionTitle.textContent === "Image") {
    const form = document.querySelector("#root > div > main > div > div > div.MuiGrid-root.MuiGrid-item.MuiGrid-grid-xs-12.MuiGrid-grid-md-7.MuiGrid-grid-lg-6 > div > div.MuiCardContent-root > div");
    const formInput = form.querySelector("input");
    
    const formGif = form.cloneNode(true);
    const formGifInput = formGif.querySelector("input");
    const formGifLabel = formGif.querySelector("label");
    
    const formOutput = form.cloneNode(true);
    const formOutputInput = formOutput.querySelector("input");
    const formOutputLabel = formOutput.querySelector("label");
    
    form.parentNode.appendChild(formGif);
    form.parentNode.appendChild(formOutput);
    
    formGifLabel.textContent = "Gif/Webp URL";
    formGifInput.value = "";
    
    formOutputLabel.textContent = "Paste this in Locator field";
    formOutputInput.value = ""
    
    const updateOutputForm = () => {
      const gifUrlStart = "+(|oeos:";
      const encodedUrl = encodeURIComponent(formGifInput.value);
      let locatorBase = formInput.value;
      
      if (formInput.value.includes(gifUrlStart) === true) {
        locatorBase = formInput.value.substr(0, formInput.value.indexOf(gifUrlStart));
      }
      
      formOutputInput.value = locatorBase + "+(|oeos:" + encodedUrl + ")";
    }
    
    addInputChangeListener(formInput, updateOutputForm);
    formGifInput.addEventListener("input", updateOutputForm);
  }
  
  if (pageTitle === "Share") {
    const form = document.querySelector("#root > div > main > div > div > div > div");
    
    if (form === null) {
      return;
    }
    
    const formOpenEOS = form.cloneNode(true);
    const formOpenEOSInput = formOpenEOS.querySelector("input");
    let link = formOpenEOS.value;
    
    form.parentNode.appendChild(formOpenEOS);
    formOpenEOSInput.value = formOpenEOSInput.value.replace("https://milovana.com/webteases/showtease.php", "https://oeos-player-preview.herokuapp.com/");
    
    formOpenEOS.onclick = () => {
      formOpenEOSInput.select();
      document.execCommand("copy");
    }
  }
}

function addInputChangeListener(input, callback) {
  var currentValue = input.value;
  
  // Since text inputs can also be changed by code, we don't use native addEventListener
  setInterval(() => {
    if (currentValue !== input.value) {
      callback(input.value);
    }
    currentValue = input.value;
  }, 16);
}

This script adds additional text fields when picking image, one where you can paste a url to a gif/webp and another that gives you an output text to use as the locator. That way you don't need to use a url decoder. I tried making it update the locator text field through code, but as far as I can tell, that field can only be updated through user input.

Also, it adds an OpenEOS link in the share page.

Something I really would like to see from this is support for https://xtoys.app/. It allows you to control multiple different sex toys, including theHandy. As well as chock collars. You can create custom scripts such as every time you receive a message on a website, it interacts with the toys in some way, like changing their speed.

So it would be great if XToys could get information from a metronome on OpenEOS, so that the speed of the toys can match the beats per second, for example.

[fapnip]

In tease https://oeos-player-preview.herokuapp.com/?id=47978 after a short introduction the Lisa character asks you to beg. After clicking that button EOS continues automatically after the following text "AGAIN LOUDER". OEOS does not.

Attack of the f'ing command look-ahead for auto mode says again.

I've refactored the look-ahead code path. Let's see if I got it this time -- or if I've made it worse.

[fapnip]

Rather than making a completely new editor to support new features, perhaps we could use something like tampermonkey to add to the existing one:

As a short term solution it could be helpful, but the largest problem with tampermonkey is that it will be a constantly moving target, from the changing security model of browsers to potential changes in EOS, and everything in-between. Add to that a number of restrictions and validations on EOS's backend, and it becomes a less productive endeavor.

(Teases can be saved with invalid locators, but not restored from backup, for example. Hence the URL encode to get around that.)

that field can only be updated through user input.

You'd have to trigger a change event on the input element somehow -- and that basically cuts Firefox support off.

Also, it adds an OpenEOS link in the share page.

Nice!

Something I really would like to see from this is support for https://xtoys.app/. It allows you to control multiple different sex toys, including theHandy. As well as chock collars. You can create custom scripts such as every time you receive a message on a website, it interacts with the toys in some way, like changing their speed.

I don't have any way of testing it, but if you can point me to some JS implementations, and whatever keys/tokens I'd need to make sure things work, I'll see what's possible.

[fapnip]

I did not have the dev console open.
Where do I check if cache is enabled?

If the console wasn't open, cache is enabled by default, so that shouldn't be the issue.

It might be important to note that I'm running in incognito mode.

Possibly, but caching should still work (Just all from ram, no disk IIRC, so less room for cache.)

If you're able to capture a short video of the issue occurring, and you think it's a large enough issue to warrant doing so, please do.

[notSafeForDev]

As a short term solution it could be helpful, but the largest problem with tampermonkey is that it will be a constantly moving target, from the changing security model of browsers to potential changes in EOS, and everything in-between. Add to that a number of restrictions and validations on EOS's backend, and it becomes a less productive endeavor.

(Teases can be saved with invalid locators, but not restored from backup, for example. Hence the URL encode to get around that.)

Yeah, it's definitely not a long term solution. I'm just thinking for the time being, to make the transition from EOS to OpenEOS easier. As for url encoding, what I meant is that the tampermonkey script does it for you, so you don't need to use a seperate website for it.

You'd have to trigger a change event on the input element somehow -- and that basically cuts Firefox support off.

I tried dispatchEvent with both "input" and "change", but it didn't make a difference. When Inspecting the html element, it would also only change the textContent of the shadow-root element, and not the value of the actual field element.

I don't have any way of testing it, but if you can point me to some JS implementations, and whatever keys/tokens I'd need to make sure things work, I'll see what's possible.

It's actually using visual scripting. So in a custom script, you select the domain to listen on, an element to look for on the page, and a specific text on that element. So there just need to be a html element on OpenEOS that it can read from.

Script 2.PNG (44.58 KiB) Viewed 10531 times

[fapnip]

So there just need to be a html element on OpenEOS that it can read from.

In that case, once I finish off DOM abstraction (limited ability to modify the tease DOM from the interpreter sandbox), you should have all you need?

Edit: some of that abstraction is already there. For example:

Code: Select all

var myNotification = new Notification({
  ready: function (el) {
    el.innerHTML = '<div class="myDiv">I replace all of my notification!</div>'
  }
})

(Something like that should work. Untested. All node/element changes are sanitized for XSS attempts.)

[notSafeForDev]

In that case, once I finish off DOM abstraction (limited ability to modify the tease DOM from the interpreter sandbox), you should have all you need?

Edit: some of that abstraction is already there. For example:

Code: Select all

var myNotification = new Notification({
  ready: function (el) {
    el.innerHTML = '<div class="myDiv">I replace all of my notification!</div>'
  }
})

(Something like that should work. Untested. All node/element changes are sanitized for XSS attempts.)

While that can definitely work, I'm just thinking about something where you don't need to create a tease specifically to support XToys.

So the idea is that every tease that uses metronomes, would ideally work with XToys by default. So for example, there could be a hidden element that is added to the dom every time a sound is playing, with the name of the current sound file. So XToys could just query that element and check the text, in order to trigger different speeds.

There are some metronome sounds shared here: Tutorial which are named ###bpm.mp3. So for all the teases that are using those sound files, it would work.

Also, another great use for XToys, would be to sync strokers such as theHandy, with the movement in gifs.

[fapnip]

there could be a hidden element that is added to the dom every time a sound is playing, with the name of the current sound file.

Look for the children of the #oeos-sounds (was: #oeos-active-sounds) element in 0.6.1

Edit: Adding/removing the elements has a fair amount of overhead. It would be better if I could just add/remove an "is-active" class to them.

Edit2: 0.6.2 has changed the parent element to #oeos-sounds, and the children will now have an "is-active" class when they are playing.

[fapnip]

]1)[/b] 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.

DOM abstraction is now functional enough to do this kind of thing, though takes a bit of code to make happen.
See this demo tease as an example:
https://oeos.ml/?id=48073&key=e893ae8fa5

Script source (look in tease init script for core functions, and start eval for use of them.):
https://milovana.com/webteases/geteossc ... e893ae8fa5