Milovana.com

Marno wrote: Fri Dec 22, 2017 11:28 am
Your current logic for a single image is, I assume, like this…

• Randomly choose a speed — let's say 90 bpm.
• Randomly choose a number of strokes — let's say 300 beats.
• The total time in seconds is beats × 60 ÷ bpm — in this example, 300 × 60 ÷ 90 = 200 seconds.

So far, so good. This will play a single image at 90 bpm for 300 beats, which will take 200 seconds (3⅓ minutes).

But, if the optional minimum and maximum times are specified, the logic would go a bit further…

• Check the minimum time. If the minimum time is more than the total time, extend the number of beats. In this example, if the minimum time is 100 seconds, ignore it; but if it's 300 seconds, the number of beats would be increased to 450 beats.
• Likewise, check the maximum time. If the maximum time is less than the total time, reduce the number of beats. In this example, if the maximum time is 300 seconds, ignore it; but if it's 150 seconds, the number of beats would be reduced to 225 beats.

This does make more sense--thanks for the further elaboration. I actually took a different route for logic. The number of strokes is the key.

• Count number of strokes
• Pick a time within bounds
• Calculate and set the timer

It is explicitly designed to honor the bounds of the game in all of the gore an glory. (Sometimes my owner likes gauntlets.) So what you're asking for is fundamentally contrary to how the game figures values. Indeed, I did it this way to avoid the if-then logic you describe. It is also designed to not actually count time passed so the game will need to make some assumptions. I'll work it out.

The application is event driven. When the timer is up, it counts down independent of anything else happening. The metronome for example is doing its own thing independent of the timer or image loader. This has strengths and weaknesses. For example, I don't have to ensure the timing is perfect for any given object, just that the metronome ends before the slide does, and provide a short fuse. Otherwise, I'd be counting seconds and looking through an event queue which is a serious PITA when things fall out of sync! JavaScript can be prone to that when too many timers are running.

What does make sense based on your explanation is to add a safety limit where regardless of settings, the game could never exceed x seconds. And, to ensure the desired effect, don't let slides fall below x seconds in length.

Thank you for the feedback. I'll digest it and see if I can't see how to implement. Cheers!

I wanted to provide a brief update. I haven't gone away. I've been working to implement Buttplug.io support. Running an application on your computer and adjusting personal settings on the EM Trainer site will allow users to have their vibrators and other sex toys controlled by EM Trainer. A growing list of sextoys are supported by the platform.

More to come...

Big thanks for your EM Trainer Keep up the great work!
It inspired me for the game mechanics for basic exploration in "My Succubus".