Quest - Online SAVE Command (FIX)

I am posting this again because I've had a few people message me concerning this recently.

When saving a game online, the text will not be saved when using the SAVE command. (Everything works fine when you click the 'Save' button, though.)

This is a fix. When entering SAVE, this will check for the online player, then it will call the appropriate save function. This way, the text will be saved either way. (I got the OnlineCheck code from Pixie.)

I am slightly worried about OnlineCheck; it is basically a hack, being based on bizarre behaviour in the web player that ideally would get corrected. I am sure there must be some other way to check, perhaps some JavaScript variable we could set in the web player and see if it exists. These things tend to be hard to test.

K.V.

16 Apr 2018 15:07(edited)

1. There is a built-in JS boolean variable in playerweb.js called webPlayer.

webPlayer is an existing JS boolean variable in WebPlayer/player.js on line 2.

If the player is playing online, webPlayer will be set to "True", so the testOnline() function could just be:function testOnline(){return webPlayer;}.

I once set up a JS function which set a game attribute the first time SAVE was entered. This only ran once. After that, the scripts checked game.isonline instead of using JS to check webPlayer. This was error-prone, because sometimes things go wrong during the initial check (remember that we ARE talking about the web player, which is known to be quite error-prone). I found that using JS to check for webPlayer before every save is the safest way to do this. (I've been adding this to my games for about 5 months.)

Recently, Dcoder was having problems with doubles online. Apparently, the . is changed to a , when a double is converted to a string via concatenation. Upon seeing this, Pixie (jokingly) pointed out that we could do this:

I laughed at the time, but I've been using this instead of running a JS function (which calls an ASLEvent that calls a Save request) ever since, and it always works correctly.

if the mobile player is used?

That testMobile() function looks a lot like this:
http://textadventures.co.uk/forum/samples/topic/bzmjia3zd0qtrmaw72tkxq/check-if-player-is-on-a-mobile-device

A pull request which includes the JS function isMobilePlayer() was recently merged. So, Quest 5.8 will have this feature already, unless something is changed before it is released.

I honestly think testMobile() may be superior to isMobilePlayer(), by the way. (Both work when tested, though.)

...but it doesn't matter if the game is being played in the mobile browser as far as entering SAVE is concerned. It only matters if the player is using the desktop player or the web player.

If the player is online, WebPlayer/player.js will be loaded and webPlayer will be True.

This code works (you can play the test game to which I linked to test it out), but I bet the code posted by Pertex works just as well.

It doesn't matter to me which code is used, as long as something is done to fix the issue. [INSERT SMILEY FACE HERE]

K.V.

25 Apr 2018 05:47(edited)

The code in this post is not so good.

See my next post.

OLD CODE

Of course, the best solution would probably be adding this to WebPlayer/Mobile/playermobile.js:

var mobilePlayer = true;

Then we could just do:

if (webPlayer){
console.log("The player is playing online!");
if (mobilePlayer){
console.log("...and the player is on a mobile device, so no panes or location bar!");
}
}else{
console.log("The player is using the desktop version of Quest. (Thank goodness!)");
}

I don't know if I've said this already (and I'm too lazy to ready through my posts), but the best thing to do would be adding var mobilePlayer = true;to WebPlayer/Mobile/mobileplayer.js

The most efficient way I've found beyond that change to the source code is described below.

I added code (stolen from Pertex) to check for the mobile player.

This will return true if the mobile player setup is loaded (typeof($('#tabButton').html()) != 'undefined')

I think this might be the most efficient version of a function to check for the mobile player's display settings being set up (unless var mobilePlayer = true; were simply added to WebPlayer/Mobile/mobileplayer.js):

The only catch would be a player who opened the game in a mobile browser, opened the settings, then switched to desktop view.

The mobile browser rules would still apply, which would effect sounds the text formatting (and who knows what else).

I've tried to do this on my tablet before, and it makes it very difficult to play a game. Every time you send a command, it zooms in on the new text output and you have to zoom back out to see the entire page again.

I think this would be acceptable. If someone is switching to desktop view in a mobile browser, they're asking for trouble anyway!