I7/Glulx: Text window I/O control extension
Erik Temple
I've completed an extension that allows you to control where the
game's main input and output streams go, and I'm looking for some
testers. Testing can be as involved as you want to make it. If you
just want to read through the documentation looking for typos or poor
writing, that's cool, and if you want to test the boundaries of the
extension, that's cool too. Here are some of the things you can do
with this extension:
1) Accept input in a window other than the main window (the main
raison d'etre of the extension);
2) Redirect output from the main window to a different window, such as
a text-grid window for a terminal-like appearance.
To test this, you'll also need the new version of Flexible Windows
(version 9), which I'll also send you. Version 9 character and
hyperlink input for any window, as well as greater control over the
transcript. If you just want to test FW, that's cool too.
Feel free to respond in this thread or via email. Both extensions are
compatible with 5Z71 and 6E3x.
Thanks,
Erik
Jon Ingold
> 1) Accept input in a window other than the main window (the main
> raison d'etre of the extension);
> 2) Redirect output from the main window to a different window, such as
> a text-grid window for a terminal-like appearance.
This sounds great, and a lot like something i was trying to do myself
for a while. The only question I'd have is, does it allow for any
middle steps to this process? Specifically, I've always wanted to be
able to divorce error messages (parser mistakes and the like) from the
body text of the game. Could this be done with your system?
Otherwise, awesome work yet again!!
cheers!
jon
Erik Temple
> This sounds great, and a lot like something i was trying to do myself
> for a while. The only question I'd have is, does it allow for any
> middle steps to this process? Specifically, I've always wanted to be
> able to divorce error messages (parser mistakes and the like) from the
> body text of the game. Could this be done with your system?
>
> Otherwise, awesome work yet again!!
Thanks, Jon. I hadn't specifically thought of redirecting only the
parser's voice to a different window, but of course that is something
one might want to do. This extension plays nicely with Flexible
Windows, so it would be possible to do this kind of thing:
Before printing a parser error:
set focus to the error-window.
After printing a parser error:
return to main screen.
(The "return to main screen" will return to whatever window is
designated as the "current text output window", be that the Inform
library-created main window, or some other window designated by the
author using the extension.)
The difficult part would be identifying all of the situations where
one would want this to occur. If one would like all non-narrative
messages--such as saved game confirmations--to be redirected, that
becomes more difficult; many of them are unfortunately likely to be
hard-coded into I6-level routines and not governed by any activity.
They (or the vast majority) could probably be got at through the
Custom Library Messages extensions, but I don't have enough experience
with that extension to know for sure.
--Erik
Ron Newcomb
> This sounds great, and a lot like something i was trying to do myself
> for a while. The only question I'd have is, does it allow for any
> middle steps to this process? Specifically, I've always wanted to be
> able to divorce error messages (parser mistakes and the like) from the
> body text of the game.
Oh, I've always admired what you tried with _My Angel_, Jon. If you
create a new game using Erik's extension, I'll totally betatest for
you.
-Ron
Ben Collins-Sussman
ago. I'd love to try out the extension!
Erik Temple
> I was getting frustrated with this exact problem a couple of months
> ago. I'd love to try out the extension!
Cool, thanks. To lower the entry bar, I'll just provide links to the
two extensions:
http://dl.dropbox.com/u/947038/Text%20Window%20Input-Output%20Control.i7x
http://dl.dropbox.com/u/947038/Flexible%20Windows.i7x
(The I/O extension is still formally unreleased, and may change before
I submit it to the extensions library. Same story for this update to
Flexible Windows, which I am submitting this round on behalf of Jon
Ingold.)
Ben (and anyone else who decides to try I/O Control), please feel free
to discuss issues in this thread, or just email me if what you find
isn't worth discussing here.
Thanks!
--Erik
Erik Temple
> The only question I'd have is, does it allow for any
> middle steps to this process? Specifically, I've always wanted to be
> able to divorce error messages (parser mistakes and the like) from the
> body text of the game. Could this be done with your system?
I spent some time looking into this over the weekend. Initially I
thought I might incorporate comprehensive control over output of
parser errors, library messages, etc. into the extension. The issue is
a bit thorny, though, given the variety of different outputs that pass
through the library's library message-printing mechanism. Inform will
provide some support in a future build for distinguishing three types
of library message, but the hooks currently in the Standard Rules
can't help yet. To make a long story short, I've decided not to tackle
this, at least not in this version of the extension.
That said, there does seem to be at least one relatively accessible
way to get comprehensive control over the output of all library
messages. Using the Custom Library Messages extension, you could group
the library messages (using lists or tables, for example) into
different sets based on how you want to treat them. For example, error
messages (whether from the parser or from, say, failed saves or
restores) could go in one group, while all other output (default
responses and reports of the actions of the player and other actors,
etc.) go in another. You'd then change CLM's "before library messages"
and "after library messages" rule variables to point to custom
handling rules that would send these outputs where you want them,
e.g.:
My before message rule:
if library-message-id is listed in the error messages list:
set focus to the error-window;
otherwise:
do nothing.
My after message rule:
return to main screen.
...and, if you're using Flexible Windows, this would be enough to send
all the error messages you've identified as such to the error-window
for output, while all other library messages remain in the main
window.
This requires some manual labor, of course, and some decision-making
about what should go where. If there's someone out there who'd like to
categorize all of the library messages, that might be a worthy
project; the categorization could also be used, for example, to print
different kinds of messages in different type-styles, so it wouldn't
be confined merely to multi-windowing. This could be done as an
extension: simply add a property to the CLM's library-message-id KOV
and provide the value for that property for all of the message IDs,
e.g.:
A library-message-id can be action-default-reporting, error-
reporting, or actor-reporting.
LibMsg <oops failed> is error-reporting.
LibMsg <oops too many arguments> is error-reporting.
LibMsg <oops no arguments> is action-default-reporting.
...and so on.
--Erik
Ron Newcomb
> This requires some manual labor, of course, and some decision-making
> about what should go where. If there's someone out there who'd like to
> categorize all of the library messages, that might be a worthy
> project; the categorization could also be used, for example, to print
> different kinds of messages in different type-styles, so it wouldn't
> be confined merely to multi-windowing. This could be done as an
> extension:
...called "Grouped Messages as Dialogue". Though to be fair, it
hasn't successfully compiled since 5T18 or so. Rather than windowing,
it allowed changing a slew of messages with a single line, for
wrapping up the parser voice and report messages and such as NPC
dialogue.
Much like _Violet_ but on a bigger scale, come to think of it.
Erik Temple
> ...called "Grouped Messages as Dialogue". Though to be fair, it
> hasn't successfully compiled since 5T18 or so. Rather than windowing,
> it allowed changing a slew of messages with a single line, for
> wrapping up the parser voice and report messages and such as NPC
> dialogue.
>
> Much like _Violet_ but on a bigger scale, come to think of it.
Cool, I'd forgotten about that extension. While it doesn't compile
anymore, the categorization scheme you used would be a great place to
start for anyone who wants to customize output by message type,
whether for windowing, stylistic variation, or NPC vocalization as in
GMasD.
--Erik