And therefore be able to set a Boolean (flag) on it?

I'm sure I asked this before and it got lost in the mists of time. Such is Quest's self-imposed online/offline/mobile browser nightmare, it's useful at this end to code specifically to those ends also for certain stuff. If I could set an online/offline flag it would help in at least one scenario. I'm not even gonna bother thinking about mobile Quest. Although it's probably similar to online Quest I think.

You could try GetFileURL. That will return a different string either way (but you may need to experiment to find out what it is).

You can use JS to test it:

	if( window.location.hostname != "local") {
		online=true;
	} 

And with the following you can check if the game is played with the mobile player:

    var elem = document.getElementById('tabButton');
    if (elem!=null){
      mobile=true;
    }  

Cheers, that'll come in useful!

Ugh, that's horribly hacky. You shouldn't need to test if a game is running online - if you do, it's a sign that you're doing something wrong (or, more likely, Quest is doing something wrong - in which case, please let me know about it).

Don't desecrate my software!!!!1!!

Seriously though, I was considering getting rid of the save icon that appears completely out of place on my game and include it in a UI of my own imagining. When someone clicks it I was going to print a message telling them the game had saved, which would look ridiculous if they were playing in the offline app and still had the file window open. So I was enquiring about a way to differentiate between the two.

Ah ok, I see it already does print a message after checking on another game. It doesn't on mine though although the parser moves as if it has. This is probably due to something that has been done in my game with a css script. It wants to print 'save successful' in black text on a black background.

Alex wrote:Ugh, that's horribly hacky. You shouldn't need to test if a game is running online - if you do, it's a sign that you're doing something wrong (or, more likely, Quest is doing something wrong - in which case, please let me know about it).

Sorry, Alex, there are several bugs in the mobile player which are known for years now and I don't think they will not be corrected in the next future. No, I even hope you will not work on them, I hope you will find more time to work on QuestKit. There the problem with the mobile player should be gone.

And in my game you need to be online because you are accessing external ressources so I must test thisbefore

I'll still be maintaining Quest, as existing games will still need to run well. I know there are various issues with the mobile WebPlayer, but please report them! Otherwise they will definitely not get fixed!

I'm going to create a simple responsive layout for WebPlayer which will eliminate the separate mobile version - that should get rid of a lot of the issues.

I've removed the side panes etc (novella theme I think) from the game but you can access a UI in the mobile browser by clicking on a cross which allows things like 'undo' which I want even less lol. Surely the novella theme should get rid of that too? (actually I think the theme might be Typewriter but it removes the side panels anyway).

If you don't want the "undo" feature, the best thing to do is override the "undo" command.

Well I don't really want that UI because most of it is redundant as I'm implementing my own UI in an object. But obviously I'll override the undo feature as it sounds like it's a core game command lol.

I had a case where I had to test whether the game was running online or not in my title screen. I have a simple check if anyone really needs it (it's the realization of The Pixie's GetFileURL approach). My use case was ASLEvent being called from a Javascript click event, where I wanted to abandon the title screen and move onto the game if the player clicked anywhere. It worked fine on the desktop, but in the online player, none of the text during that call would print out, and the game ended up in a strange state. Since it seemed such an edge case (who else is going to do that besides me?), I didn't bother filing a bug, and I wanted to get my game out, and even if I had filed a bug, who knew how it would be prioritized - would it even be fixed - or how long it would take to get fixed if it was deemed fixable and a priority? So... sometimes in the trenches, you have to work around issues.

Yeah, hit us with it. Presently I'm trying to understand JS. I've managed to get my head around small bits of jquery as I want to fade text at some points and between some online tutorials and Alex's blog post bits are slowly starting to sink in.

if (GetFileURL("foo").StartsWith("quest://")) {
    // it's the desktop version
} else {
    // it's the online version
}

I've only tested it on those versions. I haven't tried mobile. Note that you can use whatever parameter you like to GetFileURL. It doesn't have to be a file that actually exists.

Cheers, I'll test that out.