Closed selden closed 4 years ago
1. The version of SugarCube used to produce the story
The version.long()
method is likely what you want.
Console example:
/* Need to prefix it with the `SugarCube` namespace. */
console.log(SugarCube.version.long());
<<print>>
example:
<<= version.long()>>
2. The version of tweego or Twine used to compile the story
When compiled against the Twine 2 release of SugarCube, then that information should be part of the <tw-storydata>
element's content attributes—specifically, creator
and creator-version
.
Console example:
console.log($('tw-storydata').attr('creator') + " v" + $('tw-storydata').attr('creator-version'));
<<print>>
example:
<<= $('tw-storydata').attr('creator') + " v" + $('tw-storydata').attr('creator-version')>>
When compiled against the Twine 1 release of SugarCube, that information may not exist—it depends on the compiler. No one should be using the Twine 1 release, though, so let's forget about it.
3. The version of OS where the story was compiled
That information is simply not available anywhere, nor should it be useful if it were.
4. The version of OS where the the story is being run 5. The version of browser being used to run the story
Your best bet here is likely to check the navigator.userAgent
property, though you'll have to sift through the dross, or outright lies, to find the information you want—assuming it exists.
Console example:
console.log(navigator.userAgent);
<<print>>
example:
<<= navigator.userAgent>>
It'd be helpful for bug reporting if a description of the compile- and run-time software environment could be made available within a story, so it could be shown in a screengrab rather than the user perhaps providing the wrong information.
In particular, it'd be nice if SugarCube could provide any of the following items:
I might have overlooked them, but I've been searching for a while and haven't found any of these possibilities mentioned in the docs.