Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Beta version of Harlowe 1.1

13

Comments

  • edited May 2015
    CRAP! I didn't go any farther than the first couple screens in my game, which all looked good, until I got to combat . . .

    Same game, exported into beta with no changes at all.

    release:
    ifeSEr.png

    beta:
    tvYaEj.png

    There are no nested braces that I can tell. Link in PM now goes to latest beta version's HTML file. (EDIT: Oops. Now it does. Went to release at first.)
  • Okay, so displaying a passage in braces breaks the braces, it appears to me.


    ::start
    
    {
    2
    3
    4
    5
    6(display: "foo")
    7
    8
    }9
    10
    11 Hello!
    12
    13 $foo
    
    ::foo
    (set: $foo to "Hello, world!")
    
    (if: $foo is "yes")[]
    
    (else:)[]
    
    (set: $bar to 1)
    

    In Chrome and FF:

    Z6Dwi3.png

    In IE, I encountered an error in IE Version: 11.0.9600.17801, Update Versions: 11.0.19 (KB3049563):

    0RdcfJ.png

    I took the else/if out of the code and still got the error.
  • As you've probably already tested, a single passage with "Hello, world," will run in IE. Pu that in braces and it won't.

    And, putting the "foo" passage in braces in the above example won't help either. It will still retain and display all white-space.

    I'm leaving and will be gone until Monday night when I will have to bust my rear to get a game out for the challenge! XD
  • Sorry about the bugs. Here's another release candidate. This fixes:

    * IE crash when whitespace collapsing braces are used.
    * (random:) now only accepts whole numbers, and will produce an error if given fractional numbers. (This is because it was designed to only return whole numbers, and silently rounds the range between both inputs down to a whole number).
    * Fixed the numbered bullet syntax again, and made it and the other "block" syntaxes more consistent w/r/t preceding and trailing line breaks.

    Thanks for your patience.
  • Thanks for your continued hard work and effort for our enjoyment! :-)

    So, passages displayed in braces are not supposed to have white-space removed (regardless if the displayed passage has braces or not)? That's not a bug?

    I ask because I tested the HTML file I uploaded above and it looks the same, as does my game—lots of white-space where braces are ignored due to displayed passages. Also, that isn't the behavior in the release version. Yet, you didn't mention it and it's still doing it, so I don't know.

    As far as I can tell, this should all be on one line:

    eNKASQ.png
    ::foo
    
    {A
    B (set: $foo to "Hello, world!")
    C
    D
    E
    F 
    G
    }H
    
    ::start
    
    {1
    2
    3
    4
    5
    6(display: "foo")
    7
    8
    }10 $foo
    

    I tried the "foo" passage with and without braces.
  • edited May 2015
    Uh-oh. IE crashed when I tested as well.

    I would say something was up with the download link, but the numbered list bug seemed fixed . . .

    EDIT: I re-downloaded it and made all new files. IE crashed and white-space remained, but I can now type "0." and it not go to a numbered list, so something is up. I'm guessing maybe you

    Random now prints an error when fed decimals as intended, so yeah. (I was only trying to get around the numbered list bug since I couldn't multiply by decimals anyway.)

    EDITx2: Okay, now I'm not sure about numbered lists being fixed, either.
    ::start
    
    (set: $foo to (random: 1, 4) * 0.25)
    I have $foo apples.
    

    You'll get a numbered list.

    Again, can you try:
    (set: $foo to (random: 1, 4) * 0.25)
    $foo
    (set: $foo to (random: 1, 4) * 0.25)
    $foo
    (set: $foo to (random: 1, 4) * 0.25)
    $foo
    

    In a passage and refresh it a few times and see if it's doing what it should? I don't think it is.

    I never noticed a number that wasn't '1', '1.25', or '1.5'. Not even if I ran it 1,000 times, and I did.
  • Terribly sorry about these continued bugs. I didn't have reliable access to my IE11 test tools, so I missed one final compatibility bug, which should be fixed now in this new release candidate. Along with:
    * Now, the numbered list syntax requires a space after the dot, which should eliminate most instances of decimals being parsed as numbered lists.
    * Fixed a bug where (display:)ed passages which use the collapsing whitespace syntax wouldn't collapse properly.

    Hopefully this will be the last of them before release, but, as always, any further bugs will merit attention.
  • Hey, this is also my first run with 2.0.5. Looks great. Love how the first passage made is start and how the text in passages is highlighted by default.

    Thanks again for your perseverance. Unfortunately, I copy and pasted the white-space code from my above post into a new story file and it did the same thing. Braces in displayed passages are ignored. I'd take a screen shot, but it looks exactly the same. Tried adding/removing braces from the displayed passage like before with no change in result.

    Good news is, it ran in IE!

    This now works:
    (set: $foo to 0.25)
    (set: $bar to (random: 1, 4))
    (set: $baz to $foo * $bar)
    $foo
    $bar
    $baz
    
    The apples I have are 3. Would you like an apple?
    
    I have 0.1 apples after taking a few bites.
    
  • Ah, yes, that was a... foolish tiny mistake.

    New release candidate.
  • L wrote: »
    Ah, yes, that was a... foolish tiny mistake.

    New release candidate.

    Thanks for that.

    For some reason, my two stories do not work in this and I get an error of:
    Sorry to interrupt, but this page's code has got itself in a mess. (Script error.) (this is probably due to a bug in the Twine game engine.)
    

    The stories work fine with the previous version of Harlowe.

    I'll include a story file here, though ideally it would be smaller so as to find what is conflicting with Harlowe 1.1. I just get a blank page and the error message above.
  • Just to be clear... the error is produced when I import the story to the Twine build with Harlowe 1.1. and then I try to play it within Twine.

    When I import the file and then publish it, the published file does not produce the error dialogue, but neither does the story work. As soon as I press "start" in the story, I get a blank page.

    Attached is the Harlowe 1.1. published file of the same story.
  • On phone. Feli, what browsers and versions of those browsers did you use to test?

    I believe there was an error with Twine 2.0.5 and Firefox.

    Test published HTML files in browsers (not using IDE).
  • Sharpe wrote: »
    On phone. Feli, what browsers and versions of those browsers did you use to test?

    I believe there was an error with Twine 2.0.5 and Firefox.

    Test published HTML files in browsers (not using IDE).


    Chrome Version 43.0.2357.81 m

    Firefox 38.0.1
  • L wrote: »
    Ah, yes, that was a... foolish tiny mistake.

    New release candidate.

    Nope. Same problem. Copy/paste text above into new game. Displayed passage shows full white-space.
  • @feliwebwork, I tested your story ad had a chuckle.

    It's actually not blank page. It's just that the white-space from the braces bug pushes the content of your page down; you can scroll down and see it. Same error I'm reporting. ;-)
  • Sharpe wrote: »
    @feliwebwork, I tested your story ad had a chuckle.

    It's actually not blank page. It's just that the white-space from the braces bug pushes the content of your page down; you can scroll down and see it. Same error I'm reporting. ;-)

    lol! Okay, well at least it's not as bad as I thought! I guess the whitespace issue is a fairly important one!!

  • Sharpe wrote: »
    L wrote: »
    Ah, yes, that was a... foolish tiny mistake.

    New release candidate.

    Nope. Same problem. Copy/paste text above into new game. Displayed passage shows full white-space.

    I don't understand. I tried it and got this output:
  • L wrote: »
    Sharpe wrote: »
    L wrote: »
    Ah, yes, that was a... foolish tiny mistake.

    New release candidate.

    Nope. Same problem. Copy/paste text above into new game. Displayed passage shows full white-space.

    I don't understand. I tried it and got this output:

    Well, I don't either, because I just went through the whole thing again fresh and it worked this time . . . But feliwebwork's story had the same issue as I did . . .

    Well, anyways, it's fixed! Great, man!

    I'm calling it good.

    Thanks again!
  • edited May 2015
    Sharpe wrote: »
    I just went through the whole thing again fresh and it worked this time . . .

    What do you mean by going through the whole thing again fresh? Perhaps I could try that. Does it mean copy and pasting all the passages one by one?

  • Well, I discovered that the problem was in my CSS. I had the body set to width:100% and height:100%, and when I removed that, the spacing displayed properly. So it seems it was a problem on my end in not knowing how to set up the background picture properly.

    However, I discovered another problem, and that is that some (text-style:)[text] no longer work.

    I tested all the styles available in the http://twine2.neocities.org/ page and the following ones do not appear to work any more:

    blur
    blurrier
    smear

    Attached is a simple HTML file showing that the blurrier text is not showing at all.
  • OK, the styles worked in Firefox but not Chrome. *bone-rattling sigh*

    New release candidate.
  • L wrote: »
    OK, the styles worked in Firefox but not Chrome. *bone-rattling sigh*

    New release candidate.

    Working!! Thanks!

  • Sorry, but I found something else which may need fixing. :(

    It has to do with using asterix for styling. In particular, combining "strong" with "emphasized".

    Previously this would work:
    ***strong emphasized text***
    

    Also the following combination does not work either:
    <strong>*strong emphasised text*</strong>
    

    Furthermore, when using the **asterix styling** in a [hook], it displays different results depending on whether there was previously an **asterix styled** text.

    Attached is a file with the different combinations, showing that some work and others do not, and hooks behave different depending on which position they are in.

    (PS: I tested on both Firefox and Chrome and both gave the same results)
  • Thanks, every report is necessary and good.

    New release candidate.
  • L wrote: »
    Thanks, every report is necessary and good.

    New release candidate.

    Thanks for that. Working fine as far as I can see.

  • That's good.

    I'd like to take this opportunity to remind everyone what the alterations (that is, changes which aren't strictly "bugfixes") in this version of Harlowe are:
    * Altered the collapsing whitespace syntax (`{` and `}`)'s handling of whitespace considerably.
    ** Now, whitespace between multiple invisible elements, like `(set:)` macro calls, should be removed outright and not allowed to accumulate.
    ** It can be safely nested inside itself.
    ** It will also no longer collapse whitespace inside macros' strings, or HTML tags' attributes.
    * TwineScript strings are now Unicode-aware. Due to JavaScript's use of UCS-2 for string indexing, Unicode astral plane characters (used for most non-Latin scripts) are represented as 2 characters instead of a single character. This issue is now fixed in TwineScript: strings with Unicode astral characters will now have correct indexing, length, and `(substring:)` behaviour.
    * Positional property indices are now case-insensitive - `1ST` is the same as `1st`.
    * `(if:)` now only works when given a boolean - if you had written `(if: $var)` and `$var` is a number or string, you must write `$var is not 0` or `$var's length > 0` instead.
    * `(text:)` now only works on strings, numbers, booleans and arrays, because the other datatypes cannot meaningfully be transformed into text.
    * Now, you can't use the `and`, `or` and `not` operators on non-boolean values. (This means things like `(if: $stringVariable)` will produce an error now.) So, one must explicitly convert said values to boolean using `is not 0` and such instead of assuming it's boolean.
    * Now, division operators (`/` and `%`) will produce an error if used to divide by zero.
    * Reordered the precedence of `contains` - it should now be higher than `is`, so that e.g. `(print: "ABC" contains "A" is true)` should now work as expected.
    * Now, giving a datamap to `(print:)` will cause that macro to print out the datamap in a rough HTML `<table>` structure, showing each name and value. This is a superior alternative to just printing "[object Object]".
    * Now, variables and barename properties (as in `$var's property`) must have one non-numeral in their name. This means that, for instance, `$100` is no longer regarded as a valid variable name, but `$100m` still is. (This means it's now possible to write `$100`, without the verbatim syntax, in bare passage prose without it being replaced with `0`.)
    * Now, datamaps may have numbers as data names: `(datamap: 1, "A")` is now accepted. However, due to their differing types, the number `1` and the string `"1"` are treated as separate names.
    * HTML-style comments `<!--` and `-->` can now be nested, unlike in actual HTML.
    * The heading syntax no longer removes trailing `#` characters, or trims terminating whitespace. This brings it more into line with the bulleted and numbered list syntax.
    * Changed `(textstyle:)` and `(transition:)` to produce errors when given incorrect style or transition names (like `(textstyle:"blurier")`).
    Does anyone have any issues with these, or feel that any of these should be deferred to a major release instead of 1.1.0? This is the final call before the release, so do give any concerns.
  • There is another "bug" I found related to the whitespace issue. It seems the whitespace brackets remove the first space in some of the [hooks], especially with the (live:) macro, and also the space before a passage-link.

    Please see attached HTML.
  • I have also noticed that the "blur" and "blurrier" effect does not display it's correct color in Chrome (but does in Firefox).

    In Chrome it always displays in black, whereas in Firefox it takes on the correct color of the element.

    View the attached HTML in both Chrome and Firefox for comparison.
  • Ugh, OK. This may take a bit of time to fix, but don't worry.
  • Right, I've done a new release candidate with a fix for the "blur" style, but it's a slightly quirky fix (to be frank: it defers applying the special "blur" CSS until after the element has been inserted into the DOM, because Chrome needs to know what the current text colour is before it can blur it, and if your story's CSS has complicated CSS selectors like "tw-story tw-expression:nth-child(2n)" or whatnot, it can't work it out another way.) So, just test that any other (text-style:)s you've been using still work, as well as any (transition:)s and the (align:) macro.

    The other bug will be fixed a little later when I have more time.
Sign In or Register to comment.