This only bans '=', the assignment operator, and does NOT prohibit '==', the comparison operator, or any other comparison operators.
Allowed:
<<if $a == 2>>
Prohibited:
<<if $a = 2>>
The '==' operator, which 'is' and 'eq' both de-sugar to, is not really encouraged because of its visual similarity to '=', and because 'is' is a smidge closer to natural language. Obviously there's a counter-argument that '==' has continuity with '>=' and '<=', but I feel that forgoing that isn't a big deal.
First up, could we get a check box in preferences to tell it not to bother drawing lines from macros to passages. There's already one for the stylesheet to passage lines. Mostly I just want to see the linkage flows and the macro lines are clutter. (Although an option to just draw the lines if the macro is selected could be useful.)
Second up, could we get an option to add a softlink - something the editor knows to use as a link to draw a line, but the game engine ignores. Why? Well, when links are dynamically created by macros the editor doesn't know about them, so doesn't draw the lines to them. If there was a way of adding them back in - say as a comment - so the editor would know to draw the lines it would make it easier to keep the flow straight.
EDIT by Sharpe: Merged. L has said to keep all suggestions in the beta threads.
Well, OK. I guess I could repurpose "View Last Build" into something like "Rebuild and Play" (because TBH I doubt many want to view a build without it being the freshest available).
Thanks! Like I say, it would be very helpful to have it in the passages window as well, which already has "Rebuild Story" and "Save Story" for wasted effect without "View Last Build."
I only used "View Last Build" to view an old build on very rare occasion when I want to compare the old build with the new and I already closed the old version. But, I can just double-click the HTML file if needed.
L wrote:
Change of subject: I've decided to change the <<if>> macro so that using a = sign in its clause (e.g. <<if $a = 2>>) displays the error message "please use 'is' instead of '='". Mainly this is because too many people have been falling victim to the =/eq ambiguity, even despite the inclusion of 'is'. You might think "well, why not just have the program Do What I Mean and auto-substitute the = for an ==, like Game Maker and other proglangs do?", but right now I feel more inclined to discourage the habit of not using "is" (or "==" or "eq" or "==="). Any thoughts welcome.
Using "=" for "eq/is/==/===" in a conditional branch is always broken in Twine, correct? It never works. So, there is no down side at all to doing this, right?
I'm all for it as long as "<<set $foo = $baz>>" still works. I do that all the time.
Change of subject: I've decided to change the <<if>> macro so that using a = sign in its clause (e.g. <<if $a = 2>>) displays the error message "please use 'is' instead of '='". Mainly this is because too many people have been falling victim to the =/eq ambiguity, even despite the inclusion of 'is'. You might think "well, why not just have the program Do What I Mean and auto-substitute the = for an ==, like Game Maker and other proglangs do?", but right now I feel more inclined to discourage the habit of not using "is" (or "==" or "eq" or "==="). Any thoughts welcome.
Using "=" for "eq/is/==/===" in a conditional branch is always broken in Twine, correct? It never works. So, there is no down side at all to doing this, right?
Well, it isn't quite that simple. <<if $a = 2>> is actually functionally equivalent to the following, in sequence: <<set $a to 2>><<if $a>>. So, the <<if>> macro's argument is almost always true.
TheMadExile wrote:
Please tell me your planning this "error" to be a compile-time warning issued by Twine/Twee.
I wasn't going to, but if you insist, then OK, it's fortunately easy to validate just by regexp. Thing is, Twine currently has no mechanism for delivering compile-time warnings, and in the past has avoided these in favour of run-time errors, on the basis that only a browser can execute Javascript, and thus validate code.
(The only actual compile-time warning it has at present is for the Start passage's absence, which takes the form of an alert dialog displayed on every build.)
Now that we're on the subject, there are a few other things I'd like to issue warnings for but are currently a mite tough to work around at runtime - first being someone unwittingly putting "<script type='text-javascript'>" around the contents of a script passage (which has happened at least twice, to my knowledge - almost certainly due to copy-pasting the snippet from a DHTML site).
mykael wrote:
This is a couple of suggestions for 1.4.2.
First up, could we get a check box in preferences to tell it not to bother drawing lines from macros to passages. There's already one for the stylesheet to passage lines. Mostly I just want to see the linkage flows and the macro lines are clutter. (Although an option to just draw the lines if the macro is selected could be useful.)
Second up, could we get an option to add a softlink - something the editor knows to use as a link to draw a line, but the game engine ignores. Why? Well, when links are dynamically created by macros the editor doesn't know about them, so doesn't draw the lines to them. If there was a way of adding them back in - say as a comment - so the editor would know to draw the lines it would make it easier to keep the flow straight.
You refer to passages displayed via <<display>>, right? Hmm, yes, OK.
Softlinks: how about, any link inside a /% comment %/ gets a faint line drawn, despite being commented out.
I've decided to make <<if $a = 2>> etc. be a passage-close-time warning, which is even earlier than a compile-time warning. Opt-out by an app preference checkbox, if you must. For consistency I should probably add other warnings, too, like unmatched or missing <<endif>>. I guess I'll also add a "Check All Passages" option to the Build menu that runs these checks on all passages at will (since they won't be run on builds or test plays).
(All these checks are defined in the Header.py files, so custom headers can have different ones. SugarCube's header could possibly have an "introduced an undefined variable" warning to catch typo'd variable names (which can't be easily done in Sugarcane due to variable defaulting u_u;). Maybe that'd be a tad annoying, though.)
I've decided to make <<if $a = 2>> etc. be a passage-close-time warning, which is even earlier than a compile-time warning. Opt-out by an app preference checkbox, if you must.
In GCC, you can avoid the warning by adding extra parentheses around the assignment, to show that you intended to write an assignment. Maybe that's an option for Twine as well?
<<if (($a = 2))>>
The advantage being that this suppresses the warning on a case-by-case basis, while a preference suppresses it globally.
Actually, it would make more sense to disable the warning as a story setting than as a preference, since you might want to load other people's code, which might use different coding conventions than your own code.
If you need to evaluate an assignment inside an <<if>> then you can use "to". <<if $a to 5>> is not prohibited, because it's easily and readily distinguishable from "is".
mykael wrote:
[quote]Softlinks: how about, any link inside a /% comment %/ gets a faint line drawn, despite being commented out.
That would be fine.
I just tried adding this, and it turns out it's already available right now. u_u; Albeit as a normal link line, though...
I just tried adding this, and it turns out it's already available right now. u_u; Albeit as a normal link line, though...
;D
Hey, just out of curiosity and anticipation, can you give us a heads up about what has or might become of the "bookmark" save-type feature? Will we be able to use it outside of the sidebar in 1.4.2?
There's currently an issue with setter links in the 1.4.1 vanilla headers. If you do something like the following:
:: Start <<set $a to { id: 0 }>>\ [[Next (setter link: $b to $a)|Result][$b to $a]]
:: Result <<set $b.id to Math.random()>>
In the Result passage $a and $b will refer to the same object, rather than $b referring to a clone of $a. I'd assert that the setter portion of a link should execute as part of the passage it belongs to, rather than the linked passage (i.e. the setter callback should occur before pushing a new state onto the history stack).
Additionally, creating a bookmark on the Result passage (via the Bookmark link in the sidebar) and then loading that bookmark in a new tab will show $a as it was prior to the modification of $b (i.e. loading the bookmark makes $b a clone of $a, rather than referencing the same object). So, currently, loading a passage linked to by a setter link does not restore the same game state (at least when doing an object assignment in the setter).
I'd assert that the setter portion of a link should execute as part of the passage it belongs to, rather than the linked passage (i.e. the setter callback should occur before pushing a new state onto the history stack).
Hmm... I recall there was a reason why I implemented History#saveVariables like that, but altering the order seems to keep it passing all my tests, so, OK, done. Thanks for the lookout!
Also kind of pressed for time and can't mention all the fixes this has, but: * The aforediscussed warning system is in. It currently only reports for <<if $a = 2>>, "http://"; being misspelled as "http//" or "http:/", and "<script type='text/javascript'>" appearing unquoted inside script passages. The latter two are errors I've noticed a few times in some people's games, but may actually be too rare to bother with. * You can now use the inline syntax as a shorthand for <span class="...">:
@@.robot;This is a robot-class span@@
is equivalent to
<span class="robot">This is a robot-class span</span>
You can also mix styles and the class selector:
@@.robot;text-decoration:underline;This is a robot-class span with an underline@@
There isn't an equivalent for setting IDs, though. * You hopefully should now be able to write [[<<$obj[0].x>>|Passage name]] (that is, a ] character inside the link syntax) and <<print ">>" >> (that is, a quoted ">>" inside the macro syntax. * A preference option for <<display>> connector arrows being visible or not. * Flat Design(TM) story map skin. Mostly added as a lark, but I kind of like it a bit.
The great thing about this version is that it automatically creates the new passages you have written links to - but would it be possible for them to appear to the right be default. I am guessing most people work left to right,so it makes more sense for a linked passage to be that side.
Hmmm. It only prompts when I close the passage editor. Normally if I'm working on a set of passages I'll keep the more recent ones open so I can tweek flows and numbers. I was sort of expecting the prompt to appear when I create the link. In my normal workflow I'll manually create the next passage before I close that passage.
Hiding <<display>> links works well and it's worth shifting to the Beta simply to get a New Passage that doesn't hide the passage a few screens away.
<<if $encounter eq 1>> /% Start $encounter if branch %/
<<set $monster = $slime>>
<<elseif $encounter eq 2>>
<<set $monster = $redSlime>>
<<elseif $encounter eq 3>>
<<set $monster = $wolf>>
<<elseif $encounter eq 4>>
<<set $monster = $goblin>>
<<elseif $encounter eq 5>>
<<set $monster = $orc>>
<<endif>> /% End $encounter if branch. %/
<<else>> /% If it's night . . . %/
<<if $encounter lt 4>> /% Start new $encounter if branch. %/
<<set $monster = $zombie>>
<<elseif $encounter eq 4 or $encounter lt 6>>
<<set $monster = $skeleton>>
<<elseif $encounter eq 6>>
<<set $monster = $ghost>>
<<endif>> /% End $encounter if branch. %/
<<endif>> /% End day/night if branch. %/
A <<print $monster.name>> appears!<br><br>
<<display "Combat Choice">>
I took out the comments and the whitespace was removed. I guess the space before the comments is counted? Again, maybe it's working as intended. Dunno. Just a heads up.
I still have a error message with this new version : An error occurred while building your story (u'\xea').
The twine.exe.log : C:\Program Files\TwineBetaWin2\library.zip\urllib.py:1285: UnicodeWarning: Unicode equal comparison failed to convert both arguments to Unicode - interpreting them as being unequal
I'm on Windows 7 - 32 bits. The accent in the current month does not apply today. March in french is Mars
I've just ran into the same issue. Apparently the app doesn't like building the file in a directory, which has any accented characters in the directory path (e.g.: c:\Users\Default\Desktop\Magn\test_twine.html) or having accented characters in the HTML file's name. The html gets generated but Twine shows the above error message. Could this be corrected?
You could always download the thing above and check yourself
FWIW my quick tests lead me to believe it's fixed in 1.4.2.
[quote]I've just ran into the same issue. Apparently the app doesn't like building the file in a directory, which has any accented characters in the directory path (e.g.: c:\Users\Default\Desktop\Magn\test_twine.html) or having accented characters in the HTML file's name. The html gets generated but Twine shows the above error message. Could this be corrected? Fixed now. Sorry for this!
I just tried the latest beta and am able to build a story! I do still encounter the ascii codec ordinal not in range error if I add say a single to the sugarcane header file.
The following is generating an error about a missing semicolon at runtime. Earlier I had an error about 'a' not having a value, but that doesn't seem to want to come back.
Removing just the continuation characters gives me an unterminated string literal error (sort of expected).
Removing the continuation characters and the line breaks to make the value a single string works fine, as does making a separate string on each line and using a trailing + to join them together.
I've got a pending pull request which fixes issues with how the twine-position attribute was being written to tiddlers.
Thanks. For the record I only check tweecode/twine/pull for requests, and not my own repository.
Also when synching your repository, you perchance ought to rebase instead of piling merge upon merge. Just for tidiness, ofc.
mykael wrote:
The following is generating an error about a missing semicolon at runtime. Earlier I had an error about 'a' not having a value, but that doesn't seem to want to come back.
Removing just the continuation characters gives me an unterminated string literal error (sort of expected).
Removing the continuation characters and the line breaks to make the value a single string works fine, as does making a separate string on each line and using a trailing + to join them together.
Bug fixed. Thanks.
mykael wrote:
The following:
<<navdir "North" -11 {x:0,y:-1}>>
produces an error about {x:0,y:-1} being an invalid parameter. Looks like a perfectly good variable value to me.
Changing the parameter to $move.north (which is set to the above value) appears to work.
Also fixed. For the interested, the bug is that eval("{x:0,y:-1}") fails miserably thanks to block/object-literal malprecedence.
You know how we have a StoryInit passage. Could we get a StoryTurn passage that get run every time the turn count is incremented? (Preferably before the StoryMenu gets processed.) It would make it a lot easier to keep track of some things without having to do something bodgy or having to put global housekeeping code into every room.
You know how we have a StoryInit passage. Could we get a StoryTurn passage that get run every time the turn count is incremented? (Preferably before the StoryMenu gets processed.) It would make it a lot easier to keep track of some things without having to do something bodgy or having to put global housekeeping code into every room.
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?
You know how we have a StoryInit passage. Could we get a StoryTurn passage that get run every time the turn count is incremented? (Preferably before the StoryMenu gets processed.) It would make it a lot easier to keep track of some things without having to do something bodgy or having to put global housekeeping code into every room.
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?
Is the sidebar required for those special passages?
Comments
Allowed: Prohibited: The '==' operator, which 'is' and 'eq' both de-sugar to, is not really encouraged because of its visual similarity to '=', and because 'is' is a smidge closer to natural language. Obviously there's a counter-argument that '==' has continuity with '>=' and '<=', but I feel that forgoing that isn't a big deal.
First up, could we get a check box in preferences to tell it not to bother drawing lines from macros to passages. There's already one for the stylesheet to passage lines. Mostly I just want to see the linkage flows and the macro lines are clutter. (Although an option to just draw the lines if the macro is selected could be useful.)
Second up, could we get an option to add a softlink - something the editor knows to use as a link to draw a line, but the game engine ignores. Why? Well, when links are dynamically created by macros the editor doesn't know about them, so doesn't draw the lines to them. If there was a way of adding them back in - say as a comment - so the editor would know to draw the lines it would make it easier to keep the flow straight.
EDIT by Sharpe: Merged. L has said to keep all suggestions in the beta threads.
Thanks! Like I say, it would be very helpful to have it in the passages window as well, which already has "Rebuild Story" and "Save Story" for wasted effect without "View Last Build."
I only used "View Last Build" to view an old build on very rare occasion when I want to compare the old build with the new and I already closed the old version. But, I can just double-click the HTML file if needed.
Using "=" for "eq/is/==/===" in a conditional branch is always broken in Twine, correct? It never works. So, there is no down side at all to doing this, right?
I'm all for it as long as "<<set $foo = $baz>>" still works.
Well, it isn't quite that simple. <<if $a = 2>> is actually functionally equivalent to the following, in sequence: <<set $a to 2>><<if $a>>. So, the <<if>> macro's argument is almost always true.
I wasn't going to, but if you insist, then OK, it's fortunately easy to validate just by regexp. Thing is, Twine currently has no mechanism for delivering compile-time warnings, and in the past has avoided these in favour of run-time errors, on the basis that only a browser can execute Javascript, and thus validate code.
(The only actual compile-time warning it has at present is for the Start passage's absence, which takes the form of an alert dialog displayed on every build.)
Now that we're on the subject, there are a few other things I'd like to issue warnings for but are currently a mite tough to work around at runtime - first being someone unwittingly putting "<script type='text-javascript'>" around the contents of a script passage (which has happened at least twice, to my knowledge - almost certainly due to copy-pasting the snippet from a DHTML site).
You refer to passages displayed via <<display>>, right? Hmm, yes, OK.
Softlinks: how about, any link inside a /% comment %/ gets a faint line drawn, despite being commented out.
Yes. I've got lots of blue lines going all over the place that don't really tell me anything.
[quote]Softlinks: how about, any link inside a /% comment %/ gets a faint line drawn, despite being commented out.
That would be fine.
(All these checks are defined in the Header.py files, so custom headers can have different ones. SugarCube's header could possibly have an "introduced an undefined variable" warning to catch typo'd variable names (which can't be easily done in Sugarcane due to variable defaulting u_u;). Maybe that'd be a tad annoying, though.)
In GCC, you can avoid the warning by adding extra parentheses around the assignment, to show that you intended to write an assignment. Maybe that's an option for Twine as well? The advantage being that this suppresses the warning on a case-by-case basis, while a preference suppresses it globally.
Actually, it would make more sense to disable the warning as a story setting than as a preference, since you might want to load other people's code, which might use different coding conventions than your own code.
That would be fine.
I just tried adding this, and it turns out it's already available right now. u_u; Albeit as a normal link line, though...
;D
Hey, just out of curiosity and anticipation, can you give us a heads up about what has or might become of the "bookmark" save-type feature? Will we be able to use it outside of the sidebar in 1.4.2?
Additionally, creating a bookmark on the Result passage (via the Bookmark link in the sidebar) and then loading that bookmark in a new tab will show $a as it was prior to the modification of $b (i.e. loading the bookmark makes $b a clone of $a, rather than referencing the same object). So, currently, loading a passage linked to by a setter link does not restore the same game state (at least when doing an object assignment in the setter).
http://l.j-factor.com/twine/TwineBetaWin.zip
http://l.j-factor.com/twine/TwineBetaMac.zip
Also kind of pressed for time and can't mention all the fixes this has, but:
* The aforediscussed warning system is in. It currently only reports for <<if $a = 2>>, "http://"; being misspelled as "http//" or "http:/", and "<script type='text/javascript'>" appearing unquoted inside script passages. The latter two are errors I've noticed a few times in some people's games, but may actually be too rare to bother with.
* You can now use the inline syntax as a shorthand for <span class="...">: is equivalent to You can also mix styles and the class selector: There isn't an equivalent for setting IDs, though.
* You hopefully should now be able to write [[<<$obj[0].x>>|Passage name]] (that is, a ] character inside the link syntax) and <<print ">>" >> (that is, a quoted ">>" inside the macro syntax.
* A preference option for <<display>> connector arrows being visible or not.
* Flat Design(TM) story map skin. Mostly added as a lark, but I kind of like it a bit.
Hiding <<display>> links works well and it's worth shifting to the Beta simply to get a New Passage that doesn't hide the passage a few screens away.
In 1.4.1, a passage tagged "nobr", this: is different than this: A whitespace indent is shown in the first in Sugarcane (though not SugarCube). Don't know if that's intended or not.
Also, as previously reported (and perhaps fixed already), these two are different: and The latter has a line of white space, "nobr" tag or not.
Again, don't know if that's intended or not. DIV's, I know should, but spans, I don't know.
EDIT: Also, in the following passage, there is a lot of white space in Sugarcane before "A monster appears!" I took out the comments and the whitespace was removed. I guess the space before the comments is counted? Again, maybe it's working as intended. Dunno. Just a heads up.
I've just ran into the same issue. Apparently the app doesn't like building the file in a directory, which has any accented characters in the directory path (e.g.: c:\Users\Default\Desktop\Magn\test_twine.html) or having accented characters in the HTML file's name. The html gets generated but Twine shows the above error message. Could this be corrected?
You could always download the thing above and check yourself
FWIW my quick tests lead me to believe it's fixed in 1.4.2.
[quote]I've just ran into the same issue. Apparently the app doesn't like building the file in a directory, which has any accented characters in the directory path (e.g.: c:\Users\Default\Desktop\Magn\test_twine.html) or having accented characters in the HTML file's name. The html gets generated but Twine shows the above error message. Could this be corrected?
Fixed now. Sorry for this!
I do still encounter the ascii codec ordinal not in range error if I add say a single to the sugarcane header file.
Works fine if I include the trailing }>>.
Removing the continuation characters and the line breaks to make the value a single string works fine, as does making a separate string on each line and using a trailing + to join them together.
Changing the parameter to $move.north (which is set to the above value) appears to work.
Also when synching your repository, you perchance ought to rebase instead of piling merge upon merge. Just for tidiness, ofc.
Bug fixed. Thanks.
Also fixed. For the interested, the bug is that eval("{x:0,y:-1}") fails miserably thanks to block/object-literal malprecedence.
Is the sidebar required for those special passages?