Is the sidebar required for those special passages?
If the sidebar were actually gone, as in removed from the DOM, the processing for those special passages could very well error out. That said.
I'm assuming that you're asking because of the penchant some have for hiding the sidebar via CSS (e.g. #sidebar { display: none; }). Doing so does not actually remove the sidebar, so the functioning of those special passages is unaffected.
The same is true of SugarCube's UI bar (#ui-bar). Though in SugarCube, I'd likely suggest using PassageReady/PassageDone for such things (or the prerender/postrender task objects).
In the case brought up by mykael, I'd probably echo Leon. If you need some arbitrary code to run before the normal code in your StoryMenu special passage, just put it at the top of that passage in a <<silently>> or something.
[quote]The current intended process is to put all such macros inside StoryMenu (or StorySubtitle, StoryAuthor etc.), in a <<nobr>> if necessary. Is there anything in particular that this can't accomplish?
First off, how often does StoryMenu get called? Once per turn or whenever the screen gets redrawn? I assume that someone fiddlling with clickable text (but not a link) isn't going to count as a turn - does/can it redrive StoryMenu?
If it's once per turn, then it probably will work ok, although I have a strong aversion to putting internal gubbins like timer management in an apparently optional part of the GUI.
I tell a lie. If I'm in a passage triggered out of StoryMenu, how do I print something so it turns up in the main play window rather than the sidebar?
First off, how often does StoryMenu get called? Once per turn or whenever the screen gets redrawn?
Yes, once per passage transition. Technically, each time state.display() is successfully called, however that is accomplished.
mykael wrote:
I assume that someone fiddlling with clickable text (but not a link) isn't going to count as a turn - does/can it redrive StoryMenu?
If the click handler initiates a successful call to state.display(), directly or indirectly, then it will drive StoryMenu.
mykael wrote:
I tell a lie. If I'm in a passage triggered out of StoryMenu, how do I print something so it turns up in the main play window rather than the sidebar?
That would be an issue. It can be done, but you'd have to supply a target for it within the main passage container, unless you only need it to be appended to the container.
Timing could be another issue, the UI bits are driven after the passage has been rendered and output to the main passage area. If your code needed to be called beforehand, then you'd have to use the prerender task object (assuming you're using the vanilla headers; both that and the PassageReady special passage are options in SugarCube).
Is there documentation someplace for the header support python files (i.e. {header}/{header}.py)?
No, except for the comments in the base header.py file and the ones on the pull request.
I wish you had asked this yesterday as I could of sent you the sugarcube.py file I created to test the code when I created the patch, because that contained comments that directly related to your header which is the major reason I originally created the patch.
I have deleted the SugarCube test branch on github because I thought you were not interested when you did not response to my PM (on another forum) asking you to have a look at it to suggest improvement to support your header more. I still have a copy on my dev machine but I am currently sitting at an airport and wont be able to access that for a number of weeks.
FWIW the API of the header.py class is still liable to be changed, at least until 1.4.2's release (and I'm willing to make further changes if you have any requests).
Got a file generating a strange error at runtime - typeError a is Null. Build generates no error messages.
Think it's got something to do with the valley_map variable in StoryInit - I was simplifying it to see if I could work out why it wasn't initializing when this error came up.
I have a request. One of the features of Twine is that if you hover over a passage in your main window, it brings up more of the text than you can see in the tiny boxes. That is cool, but when it does that (on the Mac version, at least), it moves the view around. The delay on the hovering is just short enough that this happens to me a lot when I don't want the view moved. It would be nice to have the option to either increase the delay for hover tooltips or disable them. Definitely non-critical, but it would be fantastic.
No, except for the comments in the base header.py file and the ones on the pull request.
Ah. That looks useful. Thanks.
greyelf wrote:
I have deleted the SugarCube test branch on github because I thought you were not interested when you did not response to my PM (on another forum) asking you to have a look at it to suggest improvement to support your header more.
I don't believe I've ever received a PM from you on this subject. I just checked my PMs on the other forum and I have none from you, going as far back as July of last year. I rarely delete PMs at all and never unresolved ones, so if you sent one, I never received it.
Are you possibly thinking of a regular post? Searching now, I do see two in the SugarCube thread vaguely mentioning the feature, but you never specifically ask me for input (nor do those posts mention a repo) and it's possible that I either missed the posts altogether (that would be unusual for me, but not impossible) or forgot about them (still unusual for me, but more possible).
As a rule, I generally don't ignore people, so if I haven't responded within a reasonable timeframe, poke me again as it's likely I've either forgotten or never knew in the first place.
greyelf wrote:
I still have a copy on my dev machine but I am currently sitting at an airport and wont be able to access that for a number of weeks.
If, when writing a link for the first time, the linked-to passage name ends in a period, Twine doesn't recognize it as a broken link and so doesn't populate it in the Passage> Broken Links submenu.
The unrecognized link is then colored a light blue, rather than the red of a broken link or the dark blue of a resolvable link.
Example; none of these are recognized as broken when written for the first time in a Passage window:
[[test.]] [[test|test.]] [[test.][]]
Other punctuation or non-alphabet character at the end of linked passage work fine, like
[[test?]] [[test^]]
, etc.
This is a bummer for me because the Broken Links submenu is a big timesaver for creating and opening passages you just created links to. I even use a 3rd-party keyboard shortcut utility (Hoekey) so that I can open that submenu with a single keyboard shortcut (since Twine doesn't have a keyboard shortcut for that particular submenu built in).
If, when writing a link for the first time, the linked-to passage name ends in a period, Twine doesn't recognize it as a broken link and so doesn't populate it in the Passage> Broken Links submenu.
The unrecognized link is then colored a light blue, rather than the red of a broken link or the dark blue of a resolvable link.
Example; none of these are recognized as broken when written for the first time in a Passage window:
[[test.]] [[test|test.]] [[test.][]]
Other punctuation or non-alphabet character at the end of linked passage work fine, like [[test?]] [[test^]]
, etc.
This is a bummer for me because the Broken Links submenu is a big timesaver for creating and opening passages you just created links to. I even use a 3rd-party keyboard shortcut utility (Hoekey) so that I can open that submenu with a single keyboard shortcut (since Twine doesn't have a keyboard shortcut for that particular submenu built in).
OK. Now it'll only infer that a link is an external URL if it contains a period preceded and succeeded by non-whitespace non-periods.
mykael wrote:
Got a file generating a strange error at runtime - typeError a is Null. Build generates no error messages.
Think it's got something to do with the valley_map variable in StoryInit - I was simplifying it to see if I could work out why it wasn't initializing when this error came up.
FWIW the API of the header.py class is still liable to be changed, at least until 1.4.2's release (and I'm willing to make further changes if you have any requests).
The header.py "I really want that" list:
It would be nice to be able to add additional passages to the coloring lists and/or override passage coloring. (e.g. being able to give SugarCube-specific special passages, like PassageReady, the appropriate color)
It would be nice to be able to override the identification regexps (from tweeregex.py). (e.g. being able to properly parse SugarCube's macros, among other things)
The header.py "wouldn't that be cool" list:
It would be nice to be able to specify styling or, at least, the basic font family that some text should be in. (e.g. being able to have the contents of SugarCube's <<script>> macro in the monospace font)
The general "I really want that" list:
It would be nice to be have an option/options for specifying the tab size for the editor panels. One for each of the font settings would be nice, but one general setting would be liveable (for me anyway, since I'd simply set them all to 4). Not being able to set them is a tad bit silly, having "normal" set to 3 and "monospace" to 8 by default is just ridiculous (I don't use fullscreen, so I have no idea what that's set to).
The general commentary list:
The Flat Design(TM) mode is actually kind of nice, however, it would be better (IMO) if the story map background were a darker grey than it is currently (the contrast between it and the rest is a little too low, for my eyes anyway, YMMV).
On header.py again. If the list returned by storySettings() is empty, then that should be taken as a notification that the header does not support StorySettings, and an appropriate message should be displayed within its editor dialog. Right now, if an empty list is returned, the StorySettings editor dialog is simply blank, which isn't terribly friendly. A default message along the lines of "StorySettings is not supported by this header" would be a good start, but being able to specify a custom message would be nice (for instance, I'd like to be able to mention what they should be doing instead).
It would be nice to be able to add additional passages to the coloring lists and/or override passage coloring. (e.g. being able to give SugarCube-specific special passages, like PassageReady, the appropriate color) It would be nice to be able to override the identification regexps (from tweeregex.py). (e.g. being able to properly parse SugarCube's macros, among other things)
I've added the former. The latter I want to hold off for the moment because I feel TweeRegex.py in its current state isn't really a stable API.
TheMadExile wrote:
The header.py "wouldn't that be cool" list:
It would be nice to be able to specify styling or, at least, the basic font family that some text should be in. (e.g. being able to have the contents of SugarCube's <<script>> macro in the monospace font)
Hmmm, I'll think about it, even though I'm not readily sure what the API for this would look like.
TheMadExile wrote:
The general "I really want that" list:
It would be nice to be have an option/options for specifying the tab size for the editor panels. One for each of the font settings would be nice, but one general setting would be liveable (for me anyway, since I'd simply set them all to 4). Not being able to set them is a tad bit silly, having "normal" set to 3 and "monospace" to 8 by default is just ridiculous (I don't use fullscreen, so I have no idea what that's set to).
I think I might set them to just 4 all rather than put in an option.
TheMadExile wrote:
On header.py again. If the list returned by storySettings() is empty, then that should be taken as a notification that the header does not support StorySettings, and an appropriate message should be displayed within its editor dialog. Right now, if an empty list is returned, the StorySettings editor dialog is simply blank, which isn't terribly friendly. A default message along the lines of "StorySettings is not supported by this header" would be a good start, but being able to specify a custom message would be nice (for instance, I'd like to be able to mention what they should be doing instead).
I see there is a "create link from selected text" keyboard shortcut (Ctrl-L). It would be cool if one could do the same for bold, italic, and underline. I see Ctrl-B builds the story; I'd just make it Ctrl-Shift-(Letter) for the build shortcuts. Just a little suggestion.
I'm transferring a Twee project into Twine 1.4.2b3. I'm trying to use StoryIncludes to make a distinction between game content and support code--I want all of the support code to be included via StoryIncludes, both so that I can continue to work with it in a proper text editor, and so that it doesn't
Unfortunately, TME tells me that the following passages are excluded from being loaded via StoryIncludes: StoryMenu, StoryTitle, StoryAuthor, StorySubtitle, StoryInit, StoryIncludes, StorySettings. A few of these, particularly StoryInit, are places where code would go, but all of these seem to be things that you wouldn't want to muck up your Twine window with. Would it be possible to allow all of these (other than StoryIncludes, of course) to be included via the special passage? There restrictions seem somewhat arbitrary.
Hi, I was just wondering either how stable the current beta candidate is, or when the release version is due.
The reason that I ask is that the school at which I work creates a disk image of the software for the forthcoming academic year - this is in the process of being compiled in the next week or so for deployment in September 2014. Anything that doesn't go into this image won't be updated/installed until Sept 2015
I'd like, therefore, to go with the most up to date version - is there a time-scale please that I can give to the network admin?
It's due to the fact that the tech department build a single disk image per year, and that any software not included in the image that is currently being put together now (for deployment this september), will consequently not get to the users until Sept 2015.
They create the disk image with all the required software once per school year, then simply mirror it out to all the machines on the network. Local installations of software are not possible, nor is modifying the image once it is created.
Hi, I was just wondering either how stable the current beta candidate is, or when the release version is due.
The reason that I ask is that the school at which I work creates a disk image of the software for the forthcoming academic year - this is in the process of being compiled in the next week or so for deployment in September 2014. Anything that doesn't go into this image won't be updated/installed until Sept 2015
I'd like, therefore, to go with the most up to date version - is there a time-scale please that I can give to the network admin?
Thanks in advance for your help.
I'll try and push out a "release candidate" over the next few days.
* My proposed "passage" HTML attribute (for making Twine internal links using raw HTML) is in as "data-passage". * A new StorySetting which disables most of the CSS used for each built-in story format, leaving only the core positioning stuff. You can then write clearer CSS on top of this bare slate. You can also trigger this within an individual stylesheet by adding the comment "blank stylesheet" to it. (The intent of this is to allow people to copy-paste full "stylesheets" into their stories without having to manually change the StorySettings.) * A new StorySetting which brings back the persistent URL hash that 1.3.5 had. This was added on request, solely as an alternative to the Bookmark link and the bookmark() function. * The story state serialisation functions have been rewritten to allow basic JS functions to be stored. So, you can store functions in variables and their values will be preserved by the Back button and bookmarking. (Of course, this relies on function decompilation, so bound and native functions will silently fail. And, when recompiling them, their original scope is lost.) * The Story___ passages are no longer forbidden from being included via StoryIncludes. Plus some minor things.
If there's anything I said I'd do but apparently forgot to, do say.
Again, look hard for bugs, make sure everything's working with your stuff, and so forth.
Could you confirm how to use the bookmark() function?
Placing this in a passage
[[Bookmark|bookmark()]]
seems to open a new window in chome, with the bookmark url in the address bar...but how would I use this to restore a game other than copying and pasting the URL (or is that the only way?).
[[bookmark()]] creates a link that's largely identical to the Bookmark link in the sidebar. You "save" your game like you would save a link to a page - by bookmarking the opened page, saving the URL, right-clicking the link and selecting "Bookmark this link" (in Firefox), and so forth using your browser's features. (You can also share it with others to refer to or reference specific parts of a story/game.)
The fact that it opens in a new window is perhaps a bit of an inconvenience, given that the Bookmark link doesn't do this. Hmm.
BUG REPORT: There are instances where Twine becomes highly unresponsive. The current snafu happens when attempting to add HTMLI could swear it's also happened with macros before, but it's been a while. I assume the cause is probably some code attempting to parse the passage contents and choking on them, highlighting code or something like that I'd imagine.
To reproduce, add the following markup to a passage:
Then go to the beginning of the second image tag (i.e. <img id="token">) and insert an opening angle bracket (less-than sign), as if you were going to wrap it in an <a> or something. Twine should now be highly unresponsive.
The effect grows worse with greater amounts of markup, say for instance if there were more <area> tags in the <map>. For example, with an additional three areas defined in the map, Twine becomes the next best thing to completely unresponsive and has to be killed.
@L I noticed that you are adding brand new features to what was release candidate 1, does this mean that version 1.4.2 is being delayed so that it can be retested?
Comments
If the sidebar were actually gone, as in removed from the DOM, the processing for those special passages could very well error out. That said.
I'm assuming that you're asking because of the penchant some have for hiding the sidebar via CSS (e.g.
#sidebar { display: none; }). Doing so does not actually remove the sidebar, so the functioning of those special passages is unaffected.The same is true of SugarCube's UI bar (
#ui-bar). Though in SugarCube, I'd likely suggest usingPassageReady/PassageDonefor such things (or theprerender/postrendertask objects).In the case brought up by mykael, I'd probably echo Leon. If you need some arbitrary code to run before the normal code in your
StoryMenuspecial passage, just put it at the top of that passage in a<<silently>>or something.First off, how often does StoryMenu get called? Once per turn or whenever the screen gets redrawn? I assume that someone fiddlling with clickable text (but not a link) isn't going to count as a turn - does/can it redrive StoryMenu?
If it's once per turn, then it probably will work ok, although I have a strong aversion to putting internal gubbins like timer management in an apparently optional part of the GUI.
I tell a lie. If I'm in a passage triggered out of StoryMenu, how do I print something so it turns up in the main play window rather than the sidebar?
Yes, once per passage transition. Technically, each time
state.display()is successfully called, however that is accomplished.If the click handler initiates a successful call to
state.display(), directly or indirectly, then it will driveStoryMenu.That would be an issue. It can be done, but you'd have to supply a target for it within the main passage container, unless you only need it to be appended to the container.
Timing could be another issue, the UI bits are driven after the passage has been rendered and output to the main passage area. If your code needed to be called beforehand, then you'd have to use the
prerendertask object (assuming you're using the vanilla headers; both that and thePassageReadyspecial passage are options in SugarCube).{header}/{header}.py)?No, except for the comments in the base header.py file and the ones on the pull request.
I wish you had asked this yesterday as I could of sent you the sugarcube.py file I created to test the code when I created the patch, because that contained comments that directly related to your header which is the major reason I originally created the patch.
I have deleted the SugarCube test branch on github because I thought you were not interested when you did not response to my PM (on another forum) asking you to have a look at it to suggest improvement to support your header more. I still have a copy on my dev machine but I am currently sitting at an airport and wont be able to access that for a number of weeks.
Think it's got something to do with the valley_map variable in StoryInit - I was simplifying it to see if I could work out why it wasn't initializing when this error came up.
Ah. That looks useful. Thanks.
I don't believe I've ever received a PM from you on this subject. I just checked my PMs on the other forum and I have none from you, going as far back as July of last year. I rarely delete PMs at all and never unresolved ones, so if you sent one, I never received it.
Are you possibly thinking of a regular post? Searching now, I do see two in the SugarCube thread vaguely mentioning the feature, but you never specifically ask me for input (nor do those posts mention a repo) and it's possible that I either missed the posts altogether (that would be unusual for me, but not impossible) or forgot about them (still unusual for me, but more possible).
As a rule, I generally don't ignore people, so if I haven't responded within a reasonable timeframe, poke me again as it's likely I've either forgotten or never knew in the first place.
I'd be happy to look at it then.
sugarcube.pyfile?If, when writing a link for the first time, the linked-to passage name ends in a period, Twine doesn't recognize it as a broken link and so doesn't populate it in the Passage> Broken Links submenu.
The unrecognized link is then colored a light blue, rather than the red of a broken link or the dark blue of a resolvable link.
Example; none of these are recognized as broken when written for the first time in a Passage window: Other punctuation or non-alphabet character at the end of linked passage work fine, like , etc.
This is a bummer for me because the Broken Links submenu is a big timesaver for creating and opening passages you just created links to. I even use a 3rd-party keyboard shortcut utility (Hoekey) so that I can open that submenu with a single keyboard shortcut (since Twine doesn't have a keyboard shortcut for that particular submenu built in).
This is a bummer for me because the Broken Links submenu is a big timesaver for creating and opening passages you just created links to. I even use a 3rd-party keyboard shortcut utility (Hoekey) so that I can open that submenu with a single keyboard shortcut (since Twine doesn't have a keyboard shortcut for that particular submenu built in).
OK. Now it'll only infer that a link is an external URL if it contains a period preceded and succeeded by non-whitespace non-periods.
Fixed - thanks.
The
header.py"I really want that" list:- It would be nice to be able to add additional passages to the coloring lists and/or override passage coloring. (e.g. being able to give SugarCube-specific special passages, like
- It would be nice to be able to override the identification regexps (from
ThePassageReady, the appropriate color)tweeregex.py). (e.g. being able to properly parse SugarCube's macros, among other things)header.py"wouldn't that be cool" list:- It would be nice to be able to specify styling or, at least, the basic font family that some text should be in. (e.g. being able to have the contents of SugarCube's
The general "I really want that" list:<<script>>macro in the monospace font)- It would be nice to be have an option/options for specifying the tab size for the editor panels. One for each of the font settings would be nice, but one general setting would be liveable (for me anyway, since I'd simply set them all to 4). Not being able to set them is a tad bit silly, having "normal" set to 3 and "monospace" to 8 by default is just ridiculous (I don't use fullscreen, so I have no idea what that's set to).
The general commentary list:header.pyagain. If the list returned bystorySettings()is empty, then that should be taken as a notification that the header does not support StorySettings, and an appropriate message should be displayed within its editor dialog. Right now, if an empty list is returned, the StorySettings editor dialog is simply blank, which isn't terribly friendly. A default message along the lines of "StorySettings is not supported by this header" would be a good start, but being able to specify a custom message would be nice (for instance, I'd like to be able to mention what they should be doing instead).I've added the former. The latter I want to hold off for the moment because I feel TweeRegex.py in its current state isn't really a stable API.
Hmmm, I'll think about it, even though I'm not readily sure what the API for this would look like.
I think I might set them to just 4 all rather than put in an option.
Unfortunately, TME tells me that the following passages are excluded from being loaded via StoryIncludes: StoryMenu, StoryTitle, StoryAuthor, StorySubtitle, StoryInit, StoryIncludes, StorySettings. A few of these, particularly StoryInit, are places where code would go, but all of these seem to be things that you wouldn't want to muck up your Twine window with. Would it be possible to allow all of these (other than StoryIncludes, of course) to be included via the special passage? There restrictions seem somewhat arbitrary.
I was just wondering either how stable the current beta candidate is, or when the release version is due.
The reason that I ask is that the school at which I work creates a disk image of the software for the forthcoming academic year - this is in the process of being compiled in the next week or so for deployment in September 2014. Anything that doesn't go into this image won't be updated/installed until Sept 2015
I'd like, therefore, to go with the most up to date version - is there a time-scale please that I can give to the network admin?
Thanks in advance for your help.
It's due to the fact that the tech department build a single disk image per year, and that any software not included in the image that is currently being put together now (for deployment this september), will consequently not get to the users until Sept 2015.
They create the disk image with all the required software once per school year, then simply mirror it out to all the machines on the network. Local installations of software are not possible, nor is modifying the image once it is created.
Feel me?
I'll try and push out a "release candidate" over the next few days.
I'll post later (once the project is up and running) on how it's going.
http://l.j-factor.com/twine/TwineBetaWin.zip
http://l.j-factor.com/twine/TwineBetaMac.zip
The main differences:
* My proposed "passage" HTML attribute (for making Twine internal links using raw HTML) is in as "data-passage".
* A new StorySetting which disables most of the CSS used for each built-in story format, leaving only the core positioning stuff. You can then write clearer CSS on top of this bare slate. You can also trigger this within an individual stylesheet by adding the comment "blank stylesheet" to it. (The intent of this is to allow people to copy-paste full "stylesheets" into their stories without having to manually change the StorySettings.)
* A new StorySetting which brings back the persistent URL hash that 1.3.5 had. This was added on request, solely as an alternative to the Bookmark link and the bookmark() function.
* The story state serialisation functions have been rewritten to allow basic JS functions to be stored. So, you can store functions in variables and their values will be preserved by the Back button and bookmarking. (Of course, this relies on function decompilation, so bound and native functions will silently fail. And, when recompiling them, their original scope is lost.)
* The Story___ passages are no longer forbidden from being included via StoryIncludes.
Plus some minor things.
If there's anything I said I'd do but apparently forgot to, do say.
Again, look hard for bugs, make sure everything's working with your stuff, and so forth.
Placing this in a passage
[[Bookmark|bookmark()]]
seems to open a new window in chome, with the bookmark url in the address bar...but how would I use this to restore a game other than copying and pasting the URL (or is that the only way?).
The fact that it opens in a new window is perhaps a bit of an inconvenience, given that the Bookmark link doesn't do this. Hmm.
There are instances where Twine becomes highly unresponsive. The current snafu happens when attempting to add HTMLI could swear it's also happened with macros before, but it's been a while. I assume the cause is probably some code attempting to parse the passage contents and choking on them, highlighting code or something like that I'd imagine.
To reproduce, add the following markup to a passage: Then go to the beginning of the second image tag (i.e.
<img id="token">) and insert an opening angle bracket (less-than sign), as if you were going to wrap it in an<a>or something. Twine should now be highly unresponsive.The effect grows worse with greater amounts of markup, say for instance if there were more
<area>tags in the<map>. For example, with an additional three areas defined in the map, Twine becomes the next best thing to completely unresponsive and has to be killed.Edit: This happens since commit bcea4c4b from last night; using the previous version of the regex the test program takes 20 ms on my PC.
I'm not really in the mood to decode a regex right now, so I'll leave the actual fixing to someone else.
The bug seems (to me) that [^>] in the regex should be [^'"\\>].
I noticed that you are adding brand new features to what was release candidate 1, does this mean that version 1.4.2 is being delayed so that it can be retested?