GuideMe (TeaseMe v2.0) - Current Build 0.4.4

[PlayfulGuy]

Spoiler: show

If I understand how Guideme works, I think the globaljavascript code gets executed for each page, resetting any global variables defined.

Not quite true.

Global javascript (and then the javascript for your current page) gets executed once for every time a function is called. If you have any page javascript whatsoever, then that will all get run as part of calling pageLoad. If you have a timer that calls a function, same thing. If you have a button that does some javascript, same thing.

This was designed deliberately. Global variables are a pain and lead to bad programming practices and code that is hard to maintain / understand.
The purpose of the scriptvar object is to hold state between pages.
Global javascript was meant to be used for reusable functions, it was never designed to be used to hold state.
There was a bug where that was not cleared down in some circumstances, but was inconsistent, so setting a global variable worked by accident some of the time, that was fixed

Spoiler: show

The design is supposed to give a clean state for each time you run a script.
It should run global javascript to set up any re-usable code.
It should then run the actual javascript for that event.
You can take a copy of a variable from the scriptvars and use it locally.
You can update a variable in scriptvars if you want to change the value.

I would recommend keeping that model, however you may want to rethink the implementation of scriptvars to make them easer to use / understand.

Okay, that's basically what I recalled and fills in the blank on why it was done.

While I agree that global variables are not necessarily the best practice, the fact remains that they are valid javascript, and they do get used. I agree with RemiHiyama that scriptVars seem to just betaking the place of global variables, but the main difference is it forces them to be explicit, and communicates to GuideMe what needs to be saved in the guide state between sessions. Come to think of it, if javascript required explicit globals some of my issues would be greatly reduced.

So (and correct me if I'm wrong) it seems the source of the issue is that EOS and Guideme use slightly different models and assumptions.

In Guideme it's assumed that all pages are essentially independent and scriptVars() are used to share information between pages, while at the same time keeping Guideme informed of what needs to be saved between sessions, and saving of the session state is done automatically.

In EOS it's assumed that pages are all related, and global variables hold the state while a session is active, and allow shared data between pages, then the teaseStorage() module is used to explicitly save selected variables between sessions, and this must be explicitly done by the programmer.

So in summary:
Guideme requires manual communication between pages, but provides automatic saving of the state between sessions.
EOS = provides automatic communication between pages, but requires manual saving of the state between sessions.

I'll sleep on it a bunch more times and see what other ideas come up, and what happens when I start re-writing the affected portion of my downloader. I guess it may just never be perfect, but if I just take it one issue, and one step at a time it will continue to get better.

Thanks for the replies guys!

PG

[PlayfulGuy]

If I understand how Guideme works, I think the globaljavascript code gets executed for each page, resetting any global variables defined.

Not quite true.

Global javascript (and then the javascript for your current page) gets executed once for every time a function is called. If you have any page javascript whatsoever, then that will all get run as part of calling pageLoad. If you have a timer that calls a function, same thing. If you have a button that does some javascript, same thing.

Every time seems to start with a fresh context, although I'm not really sure from looking at it where it does that. I'd have to hunt down the commit where that was changed again, I think.

In any case, the intent was to be able to script each page completely independently, without having to worry about name collisions and so forth. I'd be very surprised if just changing back to the old behavior doesn't break some teases.

What I do think would be worthwhile is having an optional configuration setting that makes all the resetting not happen and only runs global javascript once. Page javascript probably has to be rerun every time, and pageLoad would need to be used with caution. (If a page didn't have it defined, but did have other page javascript, it would run the last version of the function to be defined - not necessarily ideal!) This seems like it'd do what would be "expected" in most cases, though some things would require cautious handling.

I believe such an option would cover your needs, but I'm not sure exactly how to do all of it.

Yeah, that makes sense and helps clarify my understanding. I can see how there could be issues with the page level javascript, and reading that brought to mind times in the past where stuff was happening in a tease that I could not explain, or stuff was working and I could not understand how it was working because it seemed like it shouldn't. Given my experience level now I can see how both cases were clearly examples of the issues philo was addressing with the change.

Not the answer I wanted but it is what it is, right?

Thanks,

PG

[philo]

All the javascript code should be in the jscript.java class.
There were two competing jscript libraries at the time Rhino and node.js, Rhino was supported by Mozilla and node.js was some obscure entity so I assumed Rhino was more likely to succeed
I do remember Rhino was not particularly well documented and scopes were particularly obscure and it took a lot of trial and error to get it working.
I think there were 3 scopes in the end, one common one stored in guidesettings, I think one that isn't used by Guidme but needed to be there and one created for each run.
The way the scopes inherit and what it uses from each was a bit arcane from what I remember, but you may be able to implement global variables in the guide scope and have them inherited by all scripts.

Code: Select all

Scriptable globalScope = guideSettings.getGlobalScope();

That line for instance gets the global scope from guide settings in the script class

[EroticDevelopment]

This was designed deliberately. Global variables are a pain and lead to bad programming practices and code that is hard to maintain / understand.

I definitely feel that comment.. I've spent a lot of time in my professional development career working with PHP. In recent versions globals are very much discouraged, but that wasn't always the case. In working with several applications that were inherited from other developers, I ran into a ton of this. I can say without hesitation that having a ton of global variables used throughout an application was a guarantee I'd find other bad programming practices, and the code was always more difficult to understand, debug, and maintain. In the end nearly all of this was re-written into an object-oriented architecture without globals.

All of that said, I'm really conflicted on how to move forward from here. Philo has made some excellent points and it's great to hear why some of this was built the way that it is. However, many of the newer teases are written in EOS or use some kind of architecture that nearly requires the use of global variables. I really want to say we really should discourage and not support globals in the way EOS does, but it also concerns me that doing so raises the bar for the amount of development and technical knowledge needed to write teases compatible with GuideMe. As much as I hate the overuse of globals, it's significantly easier for users just getting started with JavaScript and I don't want to ignore that.

I guess my confliction really comes down to is it better to keep globals completely removed and require better practices, or is it better to allow globals and perhaps lower the bar to entry and have more content available for GuideMe?

As others have said, switching GuideMe to use globals by default is a non-starter because of how much it would break, however it does seem feasible to have a config option in the tease XML that enables the global scope and changes behavior. Whether or not this is a good idea is yet to be determined.

you may want to rethink the implementation of scriptvars to make them easer to use / understand.

Browser oriented JS has the concept of the "window" object, and I suppose something like that could work as well. Keep one variable, say "global" for explanation purposes, in the global scope and the rest per-page. That would allow things like "global.varOne = 5" to set and keep a global, and could then be used as-is like "myFunction('page1', global.varOne)" etc. Any variables not part of the global object would be destroyed, but the global object would be persisted between pages. My only concern with something like this is I don't think it solves the problem of porting EOS teases to GuideMe. It would still be difficult to rename variables that needed persisted to all be in the global scope.

It does feel like there's room to make this easier to use / understand, but I really can't think of any great ways to do this that are solving an issue rather than just re-working the implementation to say we did.

[philo]

In hindsight, I am not so convinced restricting global variables was the right design decision.
Not having them in the actual Guideme java programming is correct.
Not having them in the tease JavaScript was probably a step too far.
The chances of someone maintaining someone else's tease JavaScript is pretty low, so if the author wants to use globals and EOS makes extensive use of them, it makes sense to allow them.
As EroticDevelopment says it lowers the entry level for writing the tease.
I doubt it would break many teases if they were introduced, but having a tease option to turn it off at a tease level so a tease can be made backward compatible would help.

[RemiHiyama]

I guess my confliction really comes down to is it better to keep globals completely removed and require better practices, or is it better to allow globals and perhaps lower the bar to entry and have more content available for GuideMe?

Part of the way I look at it is "Why, these are globals, nor am I not using them." Someone using scriptVars as it exists now still has to take most of the same cautions as someone working with plain globals, just with different syntax.

On a more general philosophical level, I think it's better for a language to provide tools that make good programming easier rather than trying to make bad programming hard, because that's always going to be a moving target. But we're kind of limited here, because of how we've got to work around the limitations of other parts of the engine. Images in EOS are a major example of this kind of thing. One of the things you just can't do with javascript in EOS is display an image by filename. You've got to have a page load it. So you start getting teases that have little stub pages that do little but show an image, then jump to another page that does the actual game logic. The inability to have a true loop within a single page also leads to some odd design choices sometimes.

GuideMe lets you get way "closer to the metal"; I can't think of anything quite as hinky in it at the moment. But there is still a structure imposed by how the non-scripting parts work that mean you can't necessarily do things the way you would if you were coding the whole thing from scratch. There's always going to be workarounds required. But we can make it easier for people to code things in ways that make sense to them.


As others have said, switching GuideMe to use globals by default is a non-starter because of how much it would break, however it does seem feasible to have a config option in the tease XML that enables the global scope and changes behavior. Whether or not this is a good idea is yet to be determined.

Browser oriented JS has the concept of the "window" object, and I suppose something like that could work as well. Keep one variable, say "global" for explanation purposes, in the global scope and the rest per-page. That would allow things like "global.varOne = 5" to set and keep a global, and could then be used as-is like "myFunction('page1', global.varOne)" etc

That seems like a useful middle-of-the-road addition. Make a NativeObject at the appropriate time and stick it an a javaside Object variable, and I don't think it would cause any problems with backwards compatibility even, and javascript objects give you pretty easy access at that point.

A couple questions do occur to me. One, should places that interpolate scriptVars also look in this new object? I'm leaning to yes, because it's useful, though as a secondary to checking scriptVars. (And it'll need to check to make sure the entire object hasn't been replaced with something else for safety.) Two, should it's contents be saved? I'd prefer not here, since right now I'm not aware of any way to have values that persist between pages but not between runs.

[PlayfulGuy]

Question for the devs / feature request:

Is it possible to dynamically enable/disable TTS in a guide?

I had an idea for a tease mixing traditional follow along on screen segments with other segments that give audio instruction using TTS, but would need to be able to turn that on/off. As far as I recall TTS is an all or nothing setting at the application level.

It would be nice if this could be a tease level setting, and to have the ability to turn it on/off in javascript/xml

PG

[EroticDevelopment]

Question for the devs / feature request:

Is it possible to dynamically enable/disable TTS in a guide?

I had an idea for a tease mixing traditional follow along on screen segments with other segments that give audio instruction using TTS, but would need to be able to turn that on/off. As far as I recall TTS is an all or nothing setting at the application level.

It would be nice if this could be a tease level setting, and to have the ability to turn it on/off in javascript/xml

PG

Hi PG,

It's definitely possible, but I'm a bit curious as to what types of teases would be using this and how? The current TTS implementation was mostly used to copy text to the clipboard for other utilities to read it aloud as far as I'm aware. With the recently added Audio2 tag, is this something where you could just have audio instructions read on the Audio2 player? That would allow them to be read simultaneously with video and a second music or e-stim track if needed.

[PlayfulGuy]

Question for the devs / feature request:

Is it possible to dynamically enable/disable TTS in a guide?

Hi PG,

It's definitely possible, but I'm a bit curious as to what types of teases would be using this and how? The current TTS implementation was mostly used to copy text to the clipboard for other utilities to read it aloud as far as I'm aware. With the recently added Audio2 tag, is this something where you could just have audio instructions read on the Audio2 player? That would allow them to be read simultaneously with video and a second music or e-stim track if needed.

I don't think the Audio2 tag could help here. I'm not looking for multiple audio tracks, just the ability to switch TTS on/off.

For cumming teases I'm typically doing the tease in my play room where I have a computer connected to a larger TV, and when it's time to cum I usually go lay down on the bed, which is in another room. What I had in mind was modifying a typical text based tease that works me up to cumming, then for the "finish" switch on TTS so the commands for final few edges and cumming get converted to voice. And I would probably throw on my wireless headset at that point.

It's hard to find audio clips that have suitable text, are all in the same voice, etc. TTS just seemed like a simple way to achieve the desired result, but I only really want it for a small part of the tease.

Or maybe I just need to figure out how record all those bits once and just use audio files.

PG

[Trusfrated]

Question for the devs / feature request:

Is it possible to dynamically enable/disable TTS in a guide?

Hi PG,

It's definitely possible, but I'm a bit curious as to what types of teases would be using this and how? The current TTS implementation was mostly used to copy text to the clipboard for other utilities to read it aloud as far as I'm aware. With the recently added Audio2 tag, is this something where you could just have audio instructions read on the Audio2 player? That would allow them to be read simultaneously with video and a second music or e-stim track if needed.

I don't think the Audio2 tag could help here. I'm not looking for multiple audio tracks, just the ability to switch TTS on/off.

For cumming teases I'm typically doing the tease in my play room where I have a computer connected to a larger TV, and when it's time to cum I usually go lay down on the bed, which is in another room. What I had in mind was modifying a typical text based tease that works me up to cumming, then for the "finish" switch on TTS so the commands for final few edges and cumming get converted to voice. And I would probably throw on my wireless headset at that point.

It's hard to find audio clips that have suitable text, are all in the same voice, etc. TTS just seemed like a simple way to achieve the desired result, but I only really want it for a small part of the tease.

Or maybe I just need to figure out how record all those bits once and just use audio files.

PG

Are you using TTS now?

As I'm sure you know from all your great work on the Downloader, GuideMe doesn't play or read any of the TTS audio natively. It just copies the spoken text of the tease to the clipboard so that another piece of software (a "TTS Reader") can watch the clipboard and read whatever shows up on it. If it were me in your situation, I would just manipulate that software. Either don't open it until you are ready for the end, or have it open the whole time but just mute its independent audio control. That way you won't hear spoken words until you choose to, and it really has nothing to do with GuideMe (other than having the TTS preference checked to enable the clipboard copying).

[PlayfulGuy]

Are you using TTS now?

As I'm sure you know from all your great work on the Downloader, GuideMe doesn't play or read any of the TTS audio natively. It just copies the spoken text of the tease to the clipboard so that another piece of software (a "TTS Reader") can watch the clipboard and read whatever shows up on it. If it were me in your situation, I would just manipulate that software. Either don't open it until you are ready for the end, or have it open the whole time but just mute its independent audio control. That way you won't hear spoken words until you choose to, and it really has nothing to do with GuideMe (other than having the TTS preference checked to enable the clipboard copying).

Yeah, maybe I didn't think that all the way through. I generally do not use TTS, so just turning it when I want it makes sense.
However, if I leave it enabled in GuideMe, then it is always copy stuff to the clipboard raising potential privacy issues, and I also found it a major PITA when working on developing a tease.

Often I have the XML open in my editor with the tease open in another window for testing. Many times I've ended up pasting text that GuideMe copied to the clipboard when I was expecting to paste something else I copied moments earlier.

And my thinking was actually along the lines of not having it on until needed/wanted, but at the GuideMe level. As it is now, GuideMe treats it as an all or nothing thing. The assumption seems to be that you always want TTS or never want it, and it's a static setting in something that is generally designed to be a very dynamic environment. Know what I mean?

Not a big deal and there are ways to work around it, but it was worth asking.

Thanks,

PG

[forbiddendesire]

Hey guys, I'm an avid user of GuideMe (thank you so much for the awesome software). But unfortunately due to increasing lack of privacy I don't get to play as often as I'd like. I was thinking if there were any plans for porting it to android? I was planning on taking a shot at it myself, since luckily it's written in Java, I think a lot of the code should be useable on android. But I'm a fairly inexperienced developer (only been working for around a year) and quite an average one, so was wondering if there were any concerns or reasons why it wouldn't be possible?

[Spielers]

Hey guys, I'm an avid user of GuideMe (thank you so much for the awesome software). But unfortunately due to increasing lack of privacy I don't get to play as often as I'd like. I was thinking if there were any plans for porting it to android? I was planning on taking a shot at it myself, since luckily it's written in Java, I think a lot of the code should be useable on android. But I'm a fairly inexperienced developer (only been working for around a year) and quite an average one, so was wondering if there were any concerns or reasons why it wouldn't be possible?

there is an app for the previous version of guideMe "TeaseMe" the older scripts will work with it. viewtopic.php?t=20776

[forbiddendesire]

Hey guys, I'm an avid user of GuideMe (thank you so much for the awesome software). But unfortunately due to increasing lack of privacy I don't get to play as often as I'd like. I was thinking if there were any plans for porting it to android? I was planning on taking a shot at it myself, since luckily it's written in Java, I think a lot of the code should be useable on android. But I'm a fairly inexperienced developer (only been working for around a year) and quite an average one, so was wondering if there were any concerns or reasons why it wouldn't be possible?

there is an app for the previous version of guideMe "TeaseMe" the older scripts will work with it. viewtopic.php?t=20776

Oh wow interesting! Lol I guess never mind then. Thanks

[philo]

Hey guys, I'm an avid user of GuideMe (thank you so much for the awesome software). But unfortunately due to increasing lack of privacy I don't get to play as often as I'd like. I was thinking if there were any plans for porting it to android? I was planning on taking a shot at it myself, since luckily it's written in Java, I think a lot of the code should be useable on android. But I'm a fairly inexperienced developer (only been working for around a year) and quite an average one, so was wondering if there were any concerns or reasons why it wouldn't be possible?

source code for the android version

Code: Select all

https://github.com/philormand/android-tease-me

From what I remember Android tease me was the precursor to guideme and the original intention was to keep the two in line, but that never happened.
Google changed the menu system and broke the android version and I didn't have the energy/time to re-implement it, so it got dropped.
Source code is there if you want to give it a try, the teasme.xml files are a subset of the guideme ones, so teasme.xml teases should work in guideme but not the other way round. (A tease written for guidme, that only uses the teaseme features, would work)