Parchment testing
Andrew Plotkin
merged into it. I'm using Safari 5.0.1.
You can try my PR-IF setup at <http://dev.pr-if.org/play/adventure/>.
(Note the "dev" -- this is the test server.)
Things I've noticed:
- "Restart" seems to reload the page, but it changes the query string to
just "?". This is fine if you have default_story set. But if you're at
<parchment.html?story=http://eblong.com/zarf/zweb/shade/shade.z5.js>,
and you type "restart", it switches to _Troll's Eye View_. Disconcerting.
- The input line is san-serif black text. But when you hit enter, your
command changes to grey and a serif font. (A color shift is okay, although
I don't prefer it as the default, but everything else should stay the
same.)
- The opening block quote in Curses gets stuck up there forever. Even
opening the help menu and closing it doesn't make the block quote go away.
Same in Anchorhead, Photopia.
- There's no scroll bar until the first page is full. This gives an
unpleasant jump within the first few moves. It also leaves the status line
misaligned (until the player resizes the window a little). To avoid this,
I add:
overflow: scroll;
overflow-x: hidden;
...to the body stanza. Which is weird, but I think it produces better
results on IE than a simple "overflow-y: scroll" would.
- The loading screen ("Please wait while Parchment loads") is no longer
visible. This might be my fault -- I use an alternate HTML file -- but I
don't think so. It *is* visible if I run without Javascript (with the
appropriate <noscript> error message), so something about the Javascript
load sequence seems to have changed.
- The parchment.css file has a #loading-screen stanza, which I believe is
obsolete. (No longer any such element.)
- I had to add "background: none;" to the ".LineInput input" stanza, to
make the field match the background color in Photopia. This is probably a
good default.
- The iPad test: Tapping on the body text causes the cursor to jump to the
line-input field, and the keyboard to appear. You can then enter a
command, which works; but then they keyboard disappears and you have to
tap on the body text again.
Tapping on the "Tap here to enter text" field doesn't work right. The
cursor goes to *that* field, and typing just messes up that message. Enter
does nothing.
I can try to figure out how to fix that, but possibly not until next week.
In the meantime, can you explain what the "tap here" field is *supposed*
to do?
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Dannii
On Aug 18, 2:05 pm, Andrew Plotkin <zgoo...@eblong.com> wrote:
> I am testing the current master branch, now that mastertemp has been
> merged into it. I'm using Safari 5.0.1.
>
> You can try my PR-IF setup at <http://dev.pr-if.org/play/adventure/>.
> (Note the "dev" -- this is the test server.)
>
> Things I've noticed:
>
> - "Restart" seems to reload the page, but it changes the query string to
> just "?". This is fine if you have default_story set. But if you're at
> <parchment.html?story=http://eblong.com/zarf/zweb/shade/shade.z5.js>,
> and you type "restart", it switches to _Troll's Eye View_. Disconcerting.
to fix it soon.
> - The input line is san-serif black text. But when you hit enter, your
> command changes to grey and a serif font. (A color shift is okay, although
> I don't prefer it as the default, but everything else should stay the
> same.)
that it works in all colours.) You're the first to say anything either
way about it though. I don't have much of an opinion about whether
it's good or not. Gargoyle has input in green, so the precedent is
there. The font shouldn't change of course.
> - The opening block quote in Curses gets stuck up there forever. Even
> opening the help menu and closing it doesn't make the block quote go away.
> Same in Anchorhead, Photopia.
> - There's no scroll bar until the first page is full. This gives an
> unpleasant jump within the first few moves. It also leaves the status line
> misaligned (until the player resizes the window a little). To avoid this,
> I add:
> overflow: scroll;
> overflow-x: hidden;
> ...to the body stanza. Which is weird, but I think it produces better
> results on IE than a simple "overflow-y: scroll" would.
> - The loading screen ("Please wait while Parchment loads") is no longer
> visible. This might be my fault -- I use an alternate HTML file -- but I
> don't think so. It *is* visible if I run without Javascript (with the
> appropriate <noscript> error message), so something about the Javascript
> load sequence seems to have changed.
>
> - The parchment.css file has a #loading-screen stanza, which I believe is
> obsolete. (No longer any such element.)
really should, as often it can take a long time to load. It used to
have a basic progress meter, but perhaps just a throber would be ok.
> - I had to add "background: none;" to the ".LineInput input" stanza, to
> make the field match the background color in Photopia. This is probably a
> good default.
> - The iPad test: Tapping on the body text causes the cursor to jump to the
> line-input field, and the keyboard to appear. You can then enter a
> command, which works; but then they keyboard disappears and you have to
> tap on the body text again.
>
> Tapping on the "Tap here to enter text" field doesn't work right. The
> cursor goes to *that* field, and typing just messes up that message. Enter
> does nothing.
>
> I can try to figure out how to fix that, but possibly not until next week.
> In the meantime, can you explain what the "tap here" field is *supposed*
> to do?
no iphone mode currently.
Atul Varma
> - The input line is san-serif black text. But when you hit enter, yourParchment has always had the grey thing (technically 50% opacity so
> command changes to grey and a serif font. (A color shift is okay, although
> I don't prefer it as the default, but everything else should stay the
> same.)
that it works in all colours.) You're the first to say anything either
way about it though. I don't have much of an opinion about whether
it's good or not. Gargoyle has input in green, so the precedent is
there. The font shouldn't change of course.
Dannii
> merged into it. I'm using Safari 5.0.1.
>
> You can try my PR-IF setup at <http://dev.pr-if.org/play/adventure/>.
> (Note the "dev" -- this is the test server.)
>
> Things I've noticed:
>
> - "Restart" seems to reload the page, but it changes the query string to
> just "?". This is fine if you have default_story set. But if you're at
> <parchment.html?story=http://eblong.com/zarf/zweb/shade/shade.z5.js>,
> and you type "restart", it switches to _Troll's Eye View_. Disconcerting.
> - The input line is san-serif black text. But when you hit enter, your
> command changes to grey and a serif font. (A color shift is okay, although
> I don't prefer it as the default, but everything else should stay the
> same.)
requests input, then back to roman to respond. I guess Parchment is
breaking the rules here - it now keeps it all the same.
> - The opening block quote in Curses gets stuck up there forever. Even
> opening the help menu and closing it doesn't make the block quote go away.
> Same in Anchorhead, Photopia.
> - There's no scroll bar until the first page is full. This gives an
> unpleasant jump within the first few moves. It also leaves the status line
> misaligned (until the player resizes the window a little). To avoid this,
> I add:
> overflow: scroll;
> overflow-x: hidden;
> ...to the body stanza. Which is weird, but I think it produces better
> results on IE than a simple "overflow-y: scroll" would.
You're right about IE being weird, when I tried having the overflow on
the body it would show two scroll bars, even with your suggestion.
> - The loading screen ("Please wait while Parchment loads") is no longer
> visible. This might be my fault -- I use an alternate HTML file -- but I
> don't think so. It *is* visible if I run without Javascript (with the
> appropriate <noscript> error message), so something about the Javascript
> load sequence seems to have changed.
> - The parchment.css file has a #loading-screen stanza, which I believe is
> obsolete. (No longer any such element.)
>
> - I had to add "background: none;" to the ".LineInput input" stanza, to
> make the field match the background color in Photopia. This is probably a
> good default.
> - The iPad test: Tapping on the body text causes the cursor to jump to the
> line-input field, and the keyboard to appear. You can then enter a
> command, which works; but then they keyboard disappears and you have to
> tap on the body text again.
>
> Tapping on the "Tap here to enter text" field doesn't work right. The
> cursor goes to *that* field, and typing just messes up that message. Enter
> does nothing.
>
> I can try to figure out how to fix that, but possibly not until next week.
> In the meantime, can you explain what the "tap here" field is *supposed*
> to do?
Andrew Plotkin
> On Aug 18, 2:05 pm, Andrew Plotkin <zgoo...@eblong.com> wrote:
>> I am testing the current master branch, now that mastertemp has been
>> merged into it. I'm using Safari 5.0.1.
>>
>> You can try my PR-IF setup at <http://dev.pr-if.org/play/adventure/>.
>> (Note the "dev" -- this is the test server.)
>>
>> Things I've noticed:
>>
>> - "Restart" seems to reload the page, but it changes the query string to
>> just "?". This is fine if you have default_story set. But if you're at
>> <parchment.html?story=http://eblong.com/zarf/zweb/shade/shade.z5.js>,
>> and you type "restart", it switches to _Troll's Eye View_. Disconcerting.
>
> I can't reproduce this. Might it be a Safari only thing?
I'll test it again tonight, with your updated version.
> Photopia actually changes to a fixed with font whenever it
> requests input, then back to roman to respond.
Does it do that with explicit style opcodes? I assumed it was a bug in the
game file. I'm suppressing the fixed-width in my
http://pr-if.org/play/photopia/ stylesheet, because it looks lousy.
> I added overflow-y: scroll; to the html stanza which worked great.
> You're right about IE being weird, when I tried having the overflow on
> the body it would show two scroll bars, even with your suggestion.
Yeah, that's what happens for me. I decided that (for old IE users) always
having two scroll bars was better than having a scroll bar appear in
mid-game.
Andrew Plotkin
> On Aug 18, 2:05 pm, Andrew Plotkin <zgoo...@eblong.com> wrote:
>>
>> - "Restart" seems to reload the page, but it changes the query string to
>> just "?". This is fine if you have default_story set. But if you're at
>> <parchment.html?story=http://eblong.com/zarf/zweb/shade/shade.z5.js>,
>> and you type "restart", it switches to _Troll's Eye View_. Disconcerting.
>
> I can't reproduce this. Might it be a Safari only thing?
The problem has magically gone away. Thanks! :)
(Maybe I forgot to do a "python build.py"? I don't know.)
The block-quote problem seems to be the only serious one left.
Andrew Plotkin
(13) to asterisks. Somewhere the 13 gets converted to a 10, and then we
wind up in ge_ascii_char_to_zscii(10), which -- correctly, I think --
returns 42 for "*". It's the conversion of 13 to 10 that's causing the
problem.
This breaks indexed text:
----------
let X be an indexed text;
now X is "foo[line break]bar";
say "...[X]."
----------
(It also breaks _Heliopause_, which doesn't used indexed text but does
print to streams.)
This is bad.
Andrew Plotkin
> When printing to a memory stream, Parchment converts newline characters (13)
> to asterisks. Somewhere the 13 gets converted to a 10, and then we wind up in
> ge_ascii_char_to_zscii(10), which -- correctly, I think -- returns 42 for
> "*". It's the conversion of 13 to 10 that's causing the problem.
I've added a test to Praxix (in
http://github.com/erkyrath/gnusto/tree/zarfwork) which checks this.
It turns up another little bug as well. If I'm reading the spec 3.8.2.1
correctly, @print_char 0 should add nothing to the output stream and
should not increase the character count either. Parchment writes out a
null byte. (The "@" error at the end of the test is a side effect of
incrementing the count when it shouldn't.)
This 0 bug is trivial, unlike the 13 case.
Other interpreters:
nfrotz gets everything right.
frotz (2003) gets 0 right but fails to roundtrip "oe" and "OE".
Zoom gets only 0 wrong.
Dannii
Icky encoding schemes.
On Oct 31, 4:06 am, Andrew Plotkin <zgoo...@eblong.com> wrote:
> On Sat, 30 Oct 2010, Andrew Plotkin wrote:
> > When printing to a memory stream, Parchment converts newline characters (13)
> > to asterisks. Somewhere the 13 gets converted to a 10, and then we wind up in
> > ge_ascii_char_to_zscii(10), which -- correctly, I think -- returns 42 for
> > "*". It's the conversion of 13 to 10 that's causing the problem.
>
Andrew Plotkin
> Good find, I've fixed this now.
Thanks! Erm, weren't you working on a thesis at some point?
Dannii
of smaller essays.
Andrew Plotkin
> I submitted last Friday!
Congratulations!
Dannii
You're planning to work on optimising Quixe more, yes? I've been
thinking about how to best implement a disassembler and have some new
ideas. It could be good to work together more.
Andrew Plotkin
> Thanks!
>
> You're planning to work on optimising Quixe more, yes?
Yes. Not right off the bat on Jan 1st, though. Glk layer update first.
Andrew Plotkin
Parchment. I'm running into a lot of roadblocks.
In the current source, when I try to load up a game locally, I get a flaky
error -- presumably a file-loading race condition. It works occasionally,
but mostly fails with:
Can't find variable: runtime (outro.js:14)
I'm loading like so:
file:///Users/zarf/src/parchment-zarf/parchment.full.html?story=stories/troll.z5.js
Somewhat desperately, I rolled my branch back to Nov 6th, the last commit
before the one labelled "Have switched ZVM as the default Z-Machine VM!"
That enabled me to run games reliably. However, now I'm missing the
updates that make quote boxes work.
What's the easiest way to run with the current source but using gnusto?
I'd really rather not switch to ZVM right now.
I wound up making a couple of changes to the gnusto/structio code, to work
with my page layout. I don't know whether it's worth you picking them up.
The biggest change was an option allowing structio's scrollParent to be
$('#parchment') rather than the html/body element.
Andrew Plotkin
> What's the easiest way to run with the current source but using gnusto?
Never mind, I got it. Just remove the script link for ifvms.js, or move it
after gnusto.js.
I couldn't seem to make this happen in index.html (as opposed to
parchment.full.html), so I took the hacky route: created a variant
parchment.min.js which excluded ifvms and quixe. Probably there's a better
way to do that, but I don't see it.
You can see my reapplied hacks in
https://github.com/erkyrath/parchment/tree/zarfsite . I haven't quite
gotten Anchorhead looking right (wrong font on the quote boxes), and I
will probably do a little more work to keep the status window from being
all stripy.
Andrew Plotkin
bugs:
Curses doesn't scroll correctly. I imagine this is the referent of the
comment at the top of textgrid.js. It keeps scrolling up, putting the
latest quote-box into view, rather than down.
(Honestly, I'd rather have the old Parchment behavior back, where it fades
the extra box text out after a turn rather than trying to emulate
Infocom's scrolly box behavior. Even better: this could be a
configuration option.)
In Anchorhead, if you type "help", there's an error:
TypeError: 'undefined' is not an object (evaluating 'lines[row][col] =
temp') [textgrid.js:175]
I suppose this is another case of writing outside the status window.
Dannii
Which browser are you using? I've never had file-loading race problems before.
As you've already found out the easiest way is to just not include ifvms.js, or switch their orders. You can also override which vm is selected automatically be adding vm=gnusto to the URL. What problems though are you having with ZVM? Both VMs use the same IO system now so their output should be identical, and Gnusto actually has a few outstanding bugs. I've only left it in Parchment because ZVM doesn't support versions 1-4 and 7.
Are you still using an old revision? I suggest using the latest revision, but removing ifvms.js.
Re: scrollParent, I'm discussing with Eric Temple, and in order to make StructIO compatible with Glk, we'll have to change it so that scrolling will happen within a VM window/div, rather than a browser window. The scrollParent stuff will then be irrelevant.
Scrolling to the top should be fixed in the HEAD of master. I was using window.scrollMaxY but it's not cross-browser, so I just use a number literal now instead.
For boxes, well what we have now is the most basic code, and we can add other behaviours on top of it. One idea I had would be to show a close button when you hover on top of it.
As you've probably noticed though, I haven't been able to get it to correctly identify how much should be a box, and how much is left in the status window. It seems that some games, like curses, don't correctly set the top window height - instead they reduce it down to 1. Any suggestions? One idea I had is for @split_window to completely ignore the number it's given, and instead reduce the top window to the first entirely blank line.
I'll get onto the fix to add lines when you're writing outside the status window soon. Expect a fix in the next couple of days.
Andrew Plotkin
> Roughly in order:
>
>
> Which browser are you using? I've never had file-loading race problems
> before.
Safari. I don't see the problem with Firefox or Chrome.
I don't know what the difference is, but it's consistent (90% of the time
in Safari) and only happens with ZVM, not Gnusto.
> What problems though are you having with ZVM?
I have not had any problems with ZVM except for the loading thing.
However, for in-use web sites (pr-if.org and eblong.com) I want to update
conservatively.
> Are you still using an old revision?
I was testing with your master branch as of last week. I didn't have your
bug fixes of today, but those look unrelated.
> Scrolling to the top should be fixed in the HEAD of master. I was using
> window.scrollMaxY but it's not cross-browser, so I just use a number
> literal now instead.
That change (from Dec 11) was in the branch I was testing.
> As you've probably noticed though, I haven't been able to get it to
> correctly identify how much should be a box, and how much is left in the
> status window. It seems that some games, like curses, don't correctly set
> the top window height - instead they reduce it down to 1. Any suggestions?
> One idea I had is for @split_window to completely ignore the number it's
> given, and instead reduce the top window to the first entirely blank line.
I don't remember how I handled this in my old interpreters, nor how
Parchment used to handle it. But it wasn't that fancy. I'm pretty sure
that the right strategy was to keep all text printed to the status window,
and then (at input time) any of it below the (current) window height is by
definition a quote box.
I may try coding this up in StructIO, and seeing how it behaves. However,
most likely next week.
> I'll get onto the fix to add lines when you're writing outside the status
> window soon. Expect a fix in the next couple of days.
Okay, thanks. I have only seen this in Anchorhead, but I've only tested a
couple of games so far.
Dannii
On Tue, 27 Dec 2011, Dannii wrote:
Roughly in order:
Which browser are you using? I've never had file-loading race problems
before.
Safari. I don't see the problem with Firefox or Chrome.
I don't know what the difference is, but it's consistent (90% of the time in Safari) and only happens with ZVM, not Gnusto.
Scrolling to the top should be fixed in the HEAD of master. I was using
window.scrollMaxY but it's not cross-browser, so I just use a number
literal now instead.
That change (from Dec 11) was in the branch I was testing.
As you've probably noticed though, I haven't been able to get it to
correctly identify how much should be a box, and how much is left in the
status window. It seems that some games, like curses, don't correctly set
the top window height - instead they reduce it down to 1. Any suggestions?
One idea I had is for @split_window to completely ignore the number it's
given, and instead reduce the top window to the first entirely blank line.
I don't remember how I handled this in my old interpreters, nor how Parchment used to handle it. But it wasn't that fancy. I'm pretty sure that the right strategy was to keep all text printed to the status window, and then (at input time) any of it below the (current) window height is by definition a quote box.
Andrew Plotkin
>> I don't know what the difference is, but it's consistent (90% of the time
>> in Safari) and only happens with ZVM, not Gnusto.
>>
>
> Well you wouldn't, Gnusto is a single file. All that is moot when you're
> loading built files though, which you surely would be for pr-if/eblong.
True. I hadn't noticed that the problem *only* occurred with
parchment.full.html, and not with index.html.
Well, now you know about it.
> I've just noticed that I had also used it in textgrid.js, so I'll fix that
> soon.
Cool.
>> I don't remember how I handled this in my old interpreters, nor how
>> Parchment used to handle it. But it wasn't that fancy. I'm pretty sure that
>> the right strategy was to keep all text printed to the status window, and
>> then (at input time) any of it below the (current) window height is by
>> definition a quote box.
>>
>
> That's exactly how StructIO does it now. But it doesn't work when there's a
> multi-line status line (for example in curses). The window is split to a
> height of 1, meaning half of the status line is interpreted as a box.
Huh. So I see. (I just tried running Curses with log statements in the
@split_window.)
I see that it goes back to the correct height=2 on the next input. I guess
interpreters (including the old Parchment code) have historically been
built so that the box and status window are indistinguishable until the
window scrolls, and by then the status window has been rebuilt! So nobody
ever noticed the difference.
I think that's the right plan going forward, rather than trying to
interpolate behavior from the window's contents.
Dannii
On Tue, 27 Dec 2011, Dannii wrote:
I've just noticed that I had also used it in textgrid.js, so I'll fix that
soon.
Cool.
Huh. So I see. (I just tried running Curses with log statements in the @split_window.)
I see that it goes back to the correct height=2 on the next input. I guess interpreters (including the old Parchment code) have historically been built so that the box and status window are indistinguishable until the window scrolls, and by then the status window has been rebuilt! So nobody ever noticed the difference.
I think that's the right plan going forward, rather than trying to interpolate behavior from the window's contents.
Dannii
On Tue, 27 Dec 2011, Dannii wrote:
I don't know what the difference is, but it's consistent (90% of the time
in Safari) and only happens with ZVM, not Gnusto.
Well you wouldn't, Gnusto is a single file. All that is moot when you're
loading built files though, which you surely would be for pr-if/eblong.
True. I hadn't noticed that the problem *only* occurred with parchment.full.html, and not with index.html.
Well, now you know about it.
Dannii
On Tue, 27 Dec 2011, Dannii wrote:
I don't know what the difference is, but it's consistent (90% of the time
in Safari) and only happens with ZVM, not Gnusto.
Well you wouldn't, Gnusto is a single file. All that is moot when you're
loading built files though, which you surely would be for pr-if/eblong.
True. I hadn't noticed that the problem *only* occurred with parchment.full.html, and not with index.html.
Well, now you know about it.
mick crane
any chance for a method to incorporate my 360 photos mickiwiki.com into a
story via some sort of thingy ?
love
mimik