Notice
Due to a change in Chromium/Chrome v45 (and possibly any Blink-based browser synced to that version) locally opened (i.e. via file://) stories/games are no longer able to use the HTML5 history API.
What this means is that until a workaround can be implemented, most SugarCube* projects will break in the affected browsers when opened via the file:// scheme.
* Actually, all story formats which use the history API are affected by this change, though some handle the lossage better (e.g. Snowman also explodes, while the Twine 1 vanilla story formats degrade).
Twine 2.x: Included as a built-in. See the SugarCube 1.x in Twine 2 guide if you want to install another local copy (e.g. to install a newer version than is included).
Changelog highlights:
Fixed an issue where SugarCube would crash when opened locally (i.e. via the file:// scheme) in Chrome/Chromium (due to changes made in v45 of that browser).
Fixed an issue where SugarCube would crash when opened locally (i.e. via the file:// scheme) in Chrome/Chromium (due to changes made in v45 of that browser).
Added a warning alert when the player's browser is degrading basic required capabilities.
Refactored all config object passage properties to exist within the config.passages sub-object and config.updatePageElements into config.ui.updateStoryElements.
Twine 2.x: Included as a built-in. See the SugarCube 1.x in Twine 2 guide if you want to install another local copy (e.g. to install a newer version than is included).
Changelog highlights:
Added a warning alert when the player's browser is degrading basic required capabilities.
Backported SugarCube 2.x's warning gripe when the player's browser is being stupid.
Am getting a failure to execute replaceState on History javascript error again when opening my game locally. Happens with both Chrome and Opera. Works in Firefox.
Given the workaround, that's unlikely. Are you confusing the "degraded mode" warning for the error? Case in point, it works perfectly fine for me in the latest stable release versions of Chrome (v45.0.2454.93) and Opera (v31.0.1889.161).
So I have it working now, but using the latest version of Chrome (v45.0.2454.93 m) I'm still getting the "Warning: This browser sucks!" error. Any way to turn that off? It gets a little annoying and I don't know how to fix it.
I'm still getting the "Warning: This browser sucks!" error. Any way to turn that off? It gets a little annoying and I don't know how to fix it.
The "Warning: This browser sucks!" message is not an error, it is a message informing the Reader/Player know that the story/game they are about to read/play may not work as well as it would if they were using a more modern or different web-browser. It lets them know that some features of the story/game may not work correctly or at all.
Yes but all the features of the game do work correctly, so the warning is erroneous.
Given that my game is designed to be played all local as a node.js app, I'm worried it's just going to be spamming players on start for no reason at all, with no way to change browsers, obviously.
Notification, not error. And no, it cannot be turned off. It wouldn't be much good if authors were allowed to disable it, because I feel confident that most would, to the detriment of players. And let me be clear, the notification is a service to players.
How to be rid of it (I assume for non-NW.js testing):
greyelf has posted, within several threads IIRC, an option which will force Chrome to unbreak the History API.
Well if it is still present on NW.js I'll just have to hack into the story file myself to disable it I suppose. It's not a service to players on a NW.js app since if the story is tested and works fine, and they can't do anything about it, it's just badgering them for no reason.
Yes but all the features of the game do work correctly, so the warning is erroneous.
No, it is not. SugarCube is, at that point, having to do daft things to keep the game running (e.g. using the location hash). While these failovers do work, yes, they are almost universally much more severely limited than the primary/preferred systems. Running in a degraded mode is not a good position to be in, hence the warning to players.
Every story format (save Harlowe, which doesn't use the History API) is degraded in Blink/Chromium-based browsers in some fashion when opening local files. SugarCube just happens to be the only one, currently, which informs the player of this sad fact.
The warning also isn't browser or issue specific, so IE gets moaned about as well for various reasons.
Given that my game is designed to be played all local as a node.js app, I'm worried it's just going to be spamming players on start for no reason at all, with no way to change browsers, obviously.
Have you built a NW.js-based released and tested to see if it does pop the warning?
If it does, I'd be surprised if there were no way re-enable the History API. I haven't built any NW.js apps myself, but I know developers are given options to control various app preferences (e.g. recently CK had to enlarge the Web Storage quotas in the NW.js-based version of Twine 2).
Well if it is still present on NW.js I'll just have to hack into the story file myself to disable it I suppose. It's not a service to players on a NW.js app since if the story is tested and works fine, and they can't do anything about it, it's just badgering them for no reason.
I would not recommend doing that for the reasons stated above. You, and you players, would be better off if you focused yourself on rectifying the issue in NW.js, if it pops up there at all. Breaking SugarCube does no one any favors.
I'm just confused as to why the story would fail to work "properly" in Chrome.
BTW, I get the exact same error if I create a new story from scratch, switch to SugarCube, and test play using the latest Chrome release.
Hence why I say the error is there for no reason. What could possibly be going wrong with a new story with no custom js or css?
The warning is there because SugarCube, like most story formats, uses the HTML5 History API to manage their story/game history as their primary mode of operation. Chromium v45, and any browsers based on it, intentionally break* the History API for locally opened files. This has been explained ad nauseam (seriously, I'm not being hyperbolic).
* And I mean exactly that. They could have simply disabled it, which even older releases of SugarCube would have handled. But, no. They decided to make it throw a bloody exception. WTAF?!
Okay thanks. I get it now. I was thinking it was about something I did specifically in my story, rather than the simple act of playing it locally.
I'm sorry for being argumentative on the point, must have been a bad mood.
On the extra flip side, the testing I had to do to confirm NW.js also shows it handles animation far better than the browser too (less hitches, more capable of playing more animations at once). So now I know to test in the release application more regularly.
As a heads up. I'm likely to be publishing updates for both SugarCube 2.x and 1.x soon (say in a day or two).
For SugarCube 1.x, it'll be a fairly minor update. The recently added "your browser is totes the worst" message will be adjusted so that it only pops up once during a session.
For SugarCube 2.x, it'll be a fairly major new alpha release. Yes, I said alpha (though I only expect that to last a release or two before jumping back to beta). So, why alpha? Because the next release will feature a rewritten story history engine. While I'm pretty sure everything is working as intended, it's a scary enough jump (for me anyway) to warrant an alpha or two.
Why the rewrite? Primarily to purge the HTML5 History API (this has multiple benefits: it was recently broken by Chromium, WebKit-/Blink-based browsers are totes slow at adding states to the History API which made loading huge saves absolute torture in those browsers, etc). Though while I was at it, I also decided to purge the Hash API, which streamlined story history engine down to a single mode of operation. This also allowed me to enable the long desired (by some) ability to specify the maximum size of the story history stack and other changes (e.g. the Rewind menu/dialog morphing into the Jump To menu/dialog, which allows arbitrary movement within the story history, backward and forward; I thought about calling it Time Machine).
It's not all guns and roses though, depending on your perspective. For example, the <<back>>/<<return>> macros saw some, necessary, changes, which resulted in the loss of some functionality (it's stuff which was probably never used by anyone), though they also gained a little.
For SugarCube 1.x, it'll be a fairly minor update. The recently added "your browser is totes the worst" message will be adjusted so that it only pops up once during a session.
Thanks, that totally solves my problems with the message. The main problem being that when you have to constantly reload the game every time you want to check a minor css adjustment, which is sometimes multiple times a minute, it can get annoying.
Thanks, that totally solves my problems with the message. The main problem being that when you have to constantly reload the game every time you want to check a minor css adjustment, which is sometimes multiple times a minute, it can get annoying.
I'll just note that you never mentioned that this was why you were complaining about the warning in the first place. Had you, I probably would have made the change I'm about to publish sooner. That you're receiving it now is pure happenstance (basically, it's another backport from 2.x). Clarity is important.
Twine 2.x: Included as a built-in. See the SugarCube 1.x in Twine 2 guide if you want to install another local copy (e.g. to install a newer version than is included).
Changelog highlights:
Changed the browser capability degradation message so that it only pops up once a session.
All non-session history modes have been removed. In particular, the HTML5 History API (source of the recent kerfuffle with Chromium-based browsers) is no longer used.
The config.history sub-object has changed. The config.history.tracking property is now config.history.maxStates and config.history.mode has been removed (see the documentation for more information).
New history navigation controls are at the top of the UI bar.
Significant internal refactoring and cleanup (beyond the story object party, for realsies).
Macro library updates:
Fixed a bug in the <<widget>> macro where attempting to overwrite an existing widget would fail with an error.
The <<back>> and <<return>> macros have undergone changes (see the documentation for more information).
Removed all version objects from the built-in macros as they never have been, nor will be, used.
Added the <<=>> macro as a completely equivalent <<print>> macro alias.
Added the <<->> macro as a <<print>> macro alias which also encodes HTML special characters.
Added the PassageHeader and PassageFooter special passages which are prepended/appended to the rendering passage.
Map and Set objects are now fully supported, including basic printing defaults.
Changed the browser capability degradation message so that it only pops up once a session.
Changed Save.slots.length() to Save.slots.length (method to getter).
Bundled library changes:
es5-shim: Updated to v4.1.13.
es6-shim: Updated to v0.33.4.
UUID.js: Removed, since it's no longer used.
Other improvements.
The Bleached style for 2.x was also updated.
This is a fairly significant update. Please report any regressions or other issues so they may be addressed.
Something which slipped my mind about SugarCube v2.0.0-beta.8.
Exported saves are now universal, meaning that you can move them, at will, between browsers (i.e. play a game in Firefox, save to disk, open the game in Chrome, load save from disk, play some more).
Comments
Downloads & documentation for all Twine versions: http://www.motoslave.net/sugarcube/2/
Changelog highlights (since 2.0.0-beta.5):
Due to a change in Chromium/Chrome v45 (and possibly any Blink-based browser synced to that version) locally opened (i.e. via file://) stories/games are no longer able to use the HTML5 history API.
What this means is that until a workaround can be implemented, most SugarCube* projects will break in the affected browsers when opened via the file:// scheme.
* Actually, all story formats which use the history API are affected by this change, though some handle the lossage better (e.g. Snowman also explodes, while the Twine 1 vanilla story formats degrade).
I had to switch to Opera for testing.
----
Announcing SugarCube v1.0.29:
Changelog highlights:
Announcing SugarCube v2.0.0-beta.7:
Downloads & documentation for all Twine versions: http://www.motoslave.net/sugarcube/2/
Changelog highlights (since 2.0.0-beta.6):
Changelog highlights:
Edit: I mean the compiled version, obviously. Also, what version of Chrome (and bitness) are you using?
Given that my game is designed to be played all local as a node.js app, I'm worried it's just going to be spamming players on start for no reason at all, with no way to change browsers, obviously.
How to be rid of it (I assume for non-NW.js testing):
Every story format (save Harlowe, which doesn't use the History API) is degraded in Blink/Chromium-based browsers in some fashion when opening local files. SugarCube just happens to be the only one, currently, which informs the player of this sad fact.
The warning also isn't browser or issue specific, so IE gets moaned about as well for various reasons.
I'm just confused as to why the story would fail to work "properly" in Chrome.
BTW, I get the exact same error if I create a new story from scratch, switch to SugarCube, and test play using the latest Chrome release.
Hence why I say the error is there for no reason. What could possibly be going wrong with a new story with no custom js or css?
Maybe I'm confused as to the reasons for the warning and the purposes for it. I don't want to be argumentative if I don't know what I'm talking about.
The warning is there because SugarCube, like most story formats, uses the HTML5 History API to manage their story/game history as their primary mode of operation. Chromium v45, and any browsers based on it, intentionally break* the History API for locally opened files. This has been explained ad nauseam (seriously, I'm not being hyperbolic).
* And I mean exactly that. They could have simply disabled it, which even older releases of SugarCube would have handled. But, no. They decided to make it throw a bloody exception. WTAF?!
I'm sorry for being argumentative on the point, must have been a bad mood.
On the extra flip side, the testing I had to do to confirm NW.js also shows it handles animation far better than the browser too (less hitches, more capable of playing more animations at once). So now I know to test in the release application more regularly.
For SugarCube 1.x, it'll be a fairly minor update. The recently added "your browser is totes the worst" message will be adjusted so that it only pops up once during a session.
For SugarCube 2.x, it'll be a fairly major new alpha release. Yes, I said alpha (though I only expect that to last a release or two before jumping back to beta). So, why alpha? Because the next release will feature a rewritten story history engine. While I'm pretty sure everything is working as intended, it's a scary enough jump (for me anyway) to warrant an alpha or two.
Why the rewrite? Primarily to purge the HTML5 History API (this has multiple benefits: it was recently broken by Chromium, WebKit-/Blink-based browsers are totes slow at adding states to the History API which made loading huge saves absolute torture in those browsers, etc). Though while I was at it, I also decided to purge the Hash API, which streamlined story history engine down to a single mode of operation. This also allowed me to enable the long desired (by some) ability to specify the maximum size of the story history stack and other changes (e.g. the Rewind menu/dialog morphing into the Jump To menu/dialog, which allows arbitrary movement within the story history, backward and forward; I thought about calling it Time Machine).
It's not all guns and roses though, depending on your perspective. For example, the <<back>>/<<return>> macros saw some, necessary, changes, which resulted in the loss of some functionality (it's stuff which was probably never used by anyone), though they also gained a little.
Overall, I'm pretty happy how it's turning out.
Thanks, that totally solves my problems with the message. The main problem being that when you have to constantly reload the game every time you want to check a minor css adjustment, which is sometimes multiple times a minute, it can get annoying.
Changelog highlights:
Downloads & documentation for all Twine versions: http://www.motoslave.net/sugarcube/2/
Changelog highlights (since 2.0.0-beta.7):
This is a fairly significant update. Please report any regressions or other issues so they may be addressed.
Exported saves are now universal, meaning that you can move them, at will, between browsers (i.e. play a game in Firefox, save to disk, open the game in Chrome, load save from disk, play some more).