@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?
Yes, I really should have bit my tongue and held off on adding that loading bar and the data-setter property. Nonetheless, I already need to do another release candidate to deal with various other bugfixes. This is for real now - no more extras.
Differences: * Fixed macro syntax regexes badly hindering performance. * Added SugarCube's data-setter property, to complement data-passage. * Fixed highlighting for the bold/italic/underline syntax, which got broken in RC1. u_u * Altered the error messages of certain macros to be slightly more consistent. * A rudimentary HTML loading bar, which I feel is necessary when producing especially large HTML files with several embedded assets. * Variable/function links such as [[back|previous()]] are no longer regarded as 'broken' on the Story Map. * Other minor fixes.
Not, 100% sure this is an rc2 problem, but I can't see what I'm doing wrong.
Code fragment:
<<print JSON.stringify($terra,null,4)>> <<if $trnn neq $here>> <<print "JOE">> <<print $terra.descn>> to the <<print $dir>>. <<else>> <<print "FRED">> <<print $terra.descc>> to the <<print $dir>>. <<endif>>
This is in a passage with a nobr tag.
What I'm getting out is:
{ "name": "Grasslands", "traveltime": 15, "colour": "lime", "desc": "You are travelling across wide open grasslands, swept by the wind.", "descc": "The grasslands continue", "descn": "There are grasslands", "maxrsq": 25 }
> FREDThe grasslands continue to the North.
{ "name": "Lake", "traveltime": 30, "colour": "blue", "desc": "You are travelling across the clear blue waters of a lake.", "descc": "The lake continues", "descn": "There is a lake", "maxrsq": 25 }JOEThere is a lake to the South.
The JOE path (when the if is true - shown second) is working fine, but the FRED path is generating some line breaks and a stray close angle bracket. I'm running out of ideas about where it could be coming from other than out of the else macro.
Yeah, tried a different game with rc2 and I'm seeing it on other else statements as well.
BUG/ANNOYANCE REPORT: Build Story Build Story's open file dialog throws an error every single time it's used. Specifically: [quote] You can't open this location using this program. Please try a different location.
I haven't had the time (or motivation) to dig through the code to find the problem, but is it using the full path there (incl. the file name), rather than simply the full directory path (i.e. sans the file name), or something like that perhaps?
Notes:
System: Windows 7, English (United States).
Twine is installed to a non-default location (in: D:\Games\Twine\).
The paths in question contain no non-ASCII characters, nor do they change (e.g. an example path might be: C:\devel\local\src\sugarcube\_testing\).
but is it using the full path there (incl. the file name), rather than simply the full directory path (i.e. sans the file name), or something like that perhaps?
A quick answer to your question is that it depends on if you have built that story in the past or not.
As you can see it passes the value of either self.buildDestination or os.getcwd() depending on if self.buildDestination has a value to the FileDialog as the default location.
a. If no previous build has been done then self.buildDestination equals an empty string so the current working directory is used:
eg. (str:) C:\home\twine
b. If there has been a previous build then self.buildDestination will have a value. (which is stored within the TWS pickle file) The data type of the value of self.buildDestination on my machine is unicode instead of a string and includes the file name.
It's definitely the use of the full path then, as I suspected. According to the wx.FileDialog() specs, the third parameter specifies the default directory only, the fourth parameter is for specifying the default file name.
It seems like the obvious solution would be to change it to something like: (notionally, of course)
I submitted a fix for this and a few other issues. (I was already doing an unplanned fix of a more serious issue anyway, so it didn't make sense for me to not fix this too while I was in there.)
Could we not conflate header (run time) and compiler options, please. Case in point, the new'ish "description" story setting, which is a compiler option, cannot be used by SugarCube because it's been stuffed into the StorySettings dialog, which SugarCube does not (cannot) use.
Now that you mention it, I see what you mean - especially since the most important compiler option (the story format) is in a different place entirely.
EDIT: I guess I could add a "Build Options" menu item to either the build menu or the story menu, containing the story format, identity, description, default CSS, jquery and modernizr options - replacing the "story format" submenu.
EDIT2: Actually, I guess the jquery, CSS and modernizr options should remain in StorySettings, due to being more intimately tied to the default formats than the others, and the fact that they each have some runtime effect.
* Added the fixes and things described in preceding posts. * Also fixed a bug where script passages would error if they began with statements instead of expressions.
Again, do check that nothing unseemly happens when you run your code in it, please!
I have a bug report from elsewhere: [quote]Has anybody ever mentioned that A) Twine 1.4.2 frequently thinks changes have been made which need to be saved even if, e.g., one simply opens a passage and then closes it without changing it, but doesn't think a significant change has been made to a file when a passage is completely deleted? A very minor annoyance, but it would be nice to have fixed if possible.
It's been a while since I've tried the betas, looking cool! Flat Design mode is nice.
I'd mentioned before how rudimentary the Search and Replace functions are compared to a normal text editor's. I understand that we are in release candidate stage right now, but hopefully some improvements to search and replace could be considered at some point, maybe after this release!
I had some ideas for some minor tweaks (hopefully minor to code too) that would improve searching/replacing a lot, as well as an idea that would dovetail into the new fullscreen mode feature:
- The "selected passage" highlight is a bit low-contrast. This comes into play when using search/replace. Maybe a bright outline around the selected passage would help?
- search/replace dialog box doesn't move out of the way if it's visually on top of a search result
- search/replace dialog box's "finished searching" dialog is confusing--it just says "The text you entered was not found in your story" even though the fact is, it is, it's just that the search function has already searched everything and is finished.
- search/replace doesn't work in fullscreen mode
And now for the idea that hopefully would be possible:
- what if there was a checkbox in the search dialog box to search the entire story, and what if in fullscreen mode the search/replace functions worked, and when you did a search in the entire story, as you moved from search result to search result in the story, the relevant passage was loaded in fullscreen mode? This would give your search results the *context* needed to enable you to make quick decisions about whether to replace or skip a given search result.
L: Thanks a lot for all your hard work! I've been trying out Twine 1.4.2 and I think it's fantastic! It's more or less solved all the issues I've ever had with Twine. The message you were responding to about its not properly recognizing whether the story needs to be saved or not was an issue I had pointed out to TheMadExile. The part about recognizing that it needs to be saved when a passage is deleted is much more serious than the other. I don't mind at all being prompted to save when I don't need to, but it can be an issue when it doesn't prompt to save when it does need it.
I can only think of one feature that I would still like, though I am well aware that Twine 1.4.2 is already locked down in terms of features so it's more a desired feature for Twine 1.4.3 should such a thing ever exist. I currently have a story file which is split into four parts (plus a couple other files which include technical and non-story passages) since Twine isn't really built to accommodate 800+ passage stories. For very good reasons, only one part can include a StoryIncludes passage and have its links properly recognized as working. So any time I'm working with a file which is not my currently active file, it's filled with broken links and I get the "do you wish to create these passages?" message constantly. (Yes, I know I can turn it off. It's actually the "!" icon I'm trying to get rid of, since that icon is useful when it's actually accurate.) The issue is livable, but it would be nice if something could be done about it.
I was thinking of something like a LinkedFiles passage which is automatically marked as not included with the story (so when building, Twine won't care that there might be more than one passage with that name). Then you could enter files just as you would with a StoryIncludes passage and it would recognize passages in those files as having working links.
The technical challenge that I see is that StoryIncludes finds the passage names during build (correct me if I'm mistaken). That might be difficult with the LinkedFiles passage since it's not being included in the build. Moreover, if you "build story" with a file which doesn't have a StoryIncludes file, the build is going to choke and fail since it won't find StoryIncludes and probably not Start and other crucial passages. I can think of ways to handle this (a separate command, for example, whose only purpose is to scan the other files for passage names and store that list with the current story file), but I don't know if the costs of creating such a command are worth it. The same command should, of course, also look for a StoryIncludes passage and update the link list appropriately for that as well so it would then also be possible to build a link list for a file with StoryIncludes without building a story.
I do think there is much to be gained for larger stories from such a command, though it's much more serious for certain stories (like mine, where every story file includes lots of links to outside files) than for others. Until you integrated the broken link fix into your version of Twine, I was unwilling to switch over to it despite some very attractive features (such as the passage color-coding) since the broken link issue was a quite serious one for me personally. This issue is much less serious since it's only "inactive" files without StoryIncludes which currently have it, but it's still a little annoying to have to work with such files when going back to fix issues. (In an extreme event where a lot of work needs to be done on an inactive story file, I move the StoryIncludes passage to that file and build a story with it and then move the StoryIncludes passage back when done.)
Anyway, whether you ever add such a feature or not, thanks a lot for all the work you've done on improving Twine. It is very much appreciated.
Just tried out 1.4.2 RC3 so I could play around with StoryIncludes on the Mac, and it appears to still be broken, at least in part.
It successfully built with a reference to a .tws file in the same folder, but a similar attempt with a .twee file still returns the weird "can't find file" letter-u prefix bug that any/all StoryIncludes produce under 1.4.1/Mac.
New Passage Here works well. Paste Passage Here does not ;-(
I can reproduce this: Paste Passage Here does paste the copied passage, but not in the location of the click. The problem seems to be a missing toLogical() conversion, but I'll have to dig deeper to know for sure.
New Passage Here works well. Paste Passage Here does not ;-(
I can reproduce this: Paste Passage Here does paste the copied passage, but not in the location of the click. The problem seems to be a missing toLogical() conversion, but I'll have to dig deeper to know for sure.
A fix for this has been created and is waiting to be included into the next version of Twine.
Just tried out 1.4.2 RC3 so I could play around with StoryIncludes on the Mac, and it appears to still be broken, at least in part.
It successfully built with a reference to a .tws file in the same folder, but a similar attempt with a .twee file still returns the weird "can't find file" letter-u prefix bug that any/all StoryIncludes produce under 1.4.1/Mac.
This error, or at least one like it, is still a problem for StoryIncludes on Windows when including .tw or .twee files. Oddly, "Build Story" will work correctly and once you do that, "Rebuild Story" will work. But if you close Twine and reopen, you have to "Build Story" again to get it to work; you can't immediately "Rebuild Story."
EDIT: This may actually have had to do with looking for paths in a subdirectory rather than specifically because they were Twee files as it turns out.
Comments
Release candidate 2
http://l.j-factor.com/twine/TwineBetaWin.zip
http://l.j-factor.com/twine/TwineBetaMac.zip
Differences:
* Fixed macro syntax regexes badly hindering performance.
* Added SugarCube's data-setter property, to complement data-passage.
* Fixed highlighting for the bold/italic/underline syntax, which got broken in RC1. u_u
* Altered the error messages of certain macros to be slightly more consistent.
* A rudimentary HTML loading bar, which I feel is necessary when producing especially large HTML files with several embedded assets.
* Variable/function links such as [[back|previous()]] are no longer regarded as 'broken' on the Story Map.
* Other minor fixes.
Code fragment: This is in a passage with a nobr tag.
What I'm getting out is: The JOE path (when the if is true - shown second) is working fine, but the FRED path is generating some line breaks and a stray close angle bracket. I'm running out of ideas about where it could be coming from other than out of the else macro.
Yeah, tried a different game with rc2 and I'm seeing it on other else statements as well.
Build Story's open file dialog throws an error every single time it's used. Specifically:
[quote]
You can't open this location using this program.
Please try a different location.
I haven't had the time (or motivation) to dig through the code to find the problem, but is it using the full path there (incl. the file name), rather than simply the full directory path (i.e. sans the file name), or something like that perhaps?
Notes:
D:\Games\Twine\).C:\devel\local\src\sugarcube\_testing\).A quick answer to your question is that it depends on if you have built that story in the past or not.
The line in question is storyframe.py:821 As you can see it passes the value of either self.buildDestination or os.getcwd() depending on if self.buildDestination has a value to the FileDialog as the default location.
a. If no previous build has been done then self.buildDestination equals an empty string so the current working directory is used:
eg. (str:) C:\home\twine
b. If there has been a previous build then self.buildDestination will have a value. (which is stored within the TWS pickle file)
The data type of the value of self.buildDestination on my machine is unicode instead of a string and includes the file name.
eg. (unicode:) C:\home\twine\test_build_story.html
The build dialog does not fail on my WinXP VM, I will retest on a Windows 7 machine tonight.
wx.FileDialog()specs, the third parameter specifies the default directory only, the fourth parameter is for specifying the default file name.It seems like the obvious solution would be to change it to something like: (notionally, of course)
EDIT: I guess I could add a "Build Options" menu item to either the build menu or the story menu, containing the story format, identity, description, default CSS, jquery and modernizr options - replacing the "story format" submenu.
EDIT2: Actually, I guess the jquery, CSS and modernizr options should remain in StorySettings, due to being more intimately tied to the default formats than the others, and the fact that they each have some runtime effect.
http://l.j-factor.com/twine/TwineBetaWin.zip
http://l.j-factor.com/twine/TwineBetaMac.zip
* Added the fixes and things described in preceding posts.
* Also fixed a bug where script passages would error if they began with statements instead of expressions.
Again, do check that nothing unseemly happens when you run your code in it, please!
[quote]Has anybody ever mentioned that A) Twine 1.4.2 frequently thinks changes have been made which need to be saved even if, e.g., one simply opens a passage and then closes it without changing it, but
I'd mentioned before how rudimentary the Search and Replace functions are compared to a normal text editor's. I understand that we are in release candidate stage right now, but hopefully some improvements to search and replace could be considered at some point, maybe after this release!
I had some ideas for some minor tweaks (hopefully minor to code too) that would improve searching/replacing a lot, as well as an idea that would dovetail into the new fullscreen mode feature:
- The "selected passage" highlight is a bit low-contrast. This comes into play when using search/replace. Maybe a bright outline around the selected passage would help?
- search/replace dialog box doesn't move out of the way if it's visually on top of a search result
- search/replace dialog box's "finished searching" dialog is confusing--it just says "The text you entered was not found in your story" even though the fact is, it is, it's just that the search function has already searched everything and is finished.
- search/replace doesn't work in fullscreen mode
And now for the idea that hopefully would be possible:
- what if there was a checkbox in the search dialog box to search the entire story, and what if in fullscreen mode the search/replace functions worked, and when you did a search in the entire story, as you moved from search result to search result in the story, the relevant passage was loaded in fullscreen mode? This would give your search results the *context* needed to enable you to make quick decisions about whether to replace or skip a given search result.
I hope these ideas are useful! Thanks L.
L: Thanks a lot for all your hard work! I've been trying out Twine 1.4.2 and I think it's fantastic! It's more or less solved all the issues I've ever had with Twine. The message you were responding to about its not properly recognizing whether the story needs to be saved or not was an issue I had pointed out to TheMadExile. The part about recognizing that it needs to be saved when a passage is deleted is much more serious than the other. I don't mind at all being prompted to save when I don't need to, but it can be an issue when it doesn't prompt to save when it does need it.
I can only think of one feature that I would still like, though I am well aware that Twine 1.4.2 is already locked down in terms of features so it's more a desired feature for Twine 1.4.3 should such a thing ever exist. I currently have a story file which is split into four parts (plus a couple other files which include technical and non-story passages) since Twine isn't really built to accommodate 800+ passage stories. For very good reasons, only one part can include a StoryIncludes passage and have its links properly recognized as working. So any time I'm working with a file which is not my currently active file, it's filled with broken links and I get the "do you wish to create these passages?" message constantly. (Yes, I know I can turn it off. It's actually the "!" icon I'm trying to get rid of, since that icon is useful when it's actually accurate.) The issue is livable, but it would be nice if something could be done about it.
I was thinking of something like a LinkedFiles passage which is automatically marked as not included with the story (so when building, Twine won't care that there might be more than one passage with that name). Then you could enter files just as you would with a StoryIncludes passage and it would recognize passages in those files as having working links.
The technical challenge that I see is that StoryIncludes finds the passage names during build (correct me if I'm mistaken). That might be difficult with the LinkedFiles passage since it's not being included in the build. Moreover, if you "build story" with a file which doesn't have a StoryIncludes file, the build is going to choke and fail since it won't find StoryIncludes and probably not Start and other crucial passages. I can think of ways to handle this (a separate command, for example, whose only purpose is to scan the other files for passage names and store that list with the current story file), but I don't know if the costs of creating such a command are worth it. The same command should, of course, also look for a StoryIncludes passage and update the link list appropriately for that as well so it would then also be possible to build a link list for a file with StoryIncludes without building a story.
I do think there is much to be gained for larger stories from such a command, though it's much more serious for certain stories (like mine, where every story file includes lots of links to outside files) than for others. Until you integrated the broken link fix into your version of Twine, I was unwilling to switch over to it despite some very attractive features (such as the passage color-coding) since the broken link issue was a quite serious one for me personally. This issue is much less serious since it's only "inactive" files without StoryIncludes which currently have it, but it's still a little annoying to have to work with such files when going back to fix issues. (In an extreme event where a lot of work needs to be done on an inactive story file, I move the StoryIncludes passage to that file and build a story with it and then move the StoryIncludes passage back when done.)
Anyway, whether you ever add such a feature or not, thanks a lot for all the work you've done on improving Twine. It is very much appreciated.
It successfully built with a reference to a .tws file in the same folder, but a similar attempt with a .twee file still returns the weird "can't find file" letter-u prefix bug that any/all StoryIncludes produce under 1.4.1/Mac.
OK, I'm going to release this tomorrow, since I've gone over my secret personal deadline of June 1 by one day.
New Passage Here works well. Paste Passage Here does not ;-(
I can reproduce this: Paste Passage Here does paste the copied passage, but not in the location of the click. The problem seems to be a missing toLogical() conversion, but I'll have to dig deeper to know for sure.
A fix for this has been created and is waiting to be included into the next version of Twine.
This error, or at least one like it, is still a problem for StoryIncludes on Windows when including .tw or .twee files. Oddly, "Build Story" will work correctly and once you do that, "Rebuild Story" will work. But if you close Twine and reopen, you have to "Build Story" again to get it to work; you can't immediately "Rebuild Story."
EDIT: This may actually have had to do with looking for paths in a subdirectory rather than specifically because they were Twee files as it turns out.