Inform 7: Possible extension developments
Emily Short
Inform 7. Some of the requested features have taken time to implement,
but the process was very valuable; it is one we may repeat at some
point when we are finished working through the existing to-do list.
It occurred to us, though, that it might be worth asking a similar set
of questions in a more specific area: namely, where people feel the
extension support currently needs the most work.
Which means:
1) Are there specific (or general) areas where you feel the extensions
contributed so far are lacking? For instance, are there particular
kinds of functionality that you have tried to find an extension to
help with, but found nothing that met your needs?
It might be useful to discuss requests here, so that extension authors
can see where their services might be needed most. We could even
consider a "requests" page to accompany the extensions website, if
that would be useful.
2) Are there extensions you have yourself tried/wanted to write that
you couldn't bring about, for some technical reason? What could we do
that would help you? Are there deeper internals of Inform which you
would need access to?
3) Are there ways that the website/extension providing could work
better?
Some specific suggestions about desired extensions:
(1.1) An extension to systematically manage Glulx sound effects,
including the use of multiple channels, fading sounds in and out (and
volume control in general), and the ability to stop sounds that are
playing; this would, as we understand it, be about along the lines of
GSound from the GWindows package.
(1.2) More/better/different conversation handling. This has been
somewhat more vaguely described to us by the parties requesting it;
the strongest sense we get is that the requesters want it to be easier
to create conversation for I7, to make that aspect of things much more
writerly and less programmatically fiddly; and that they want to
produce conversations that appear to flow naturally and preserve a
sense of context.
Emily has been thinking about how best to do I7 conversation for a
couple of years now, and finally has a draft design that she is alpha-
testing; nonetheless, more input would be welcome. The new system is
still some way from being ready for release, and there may still be
significant design adjustments. Are there more specific requests about
what such a system ought to do? Those of you who are not satisfied
with the current set of conversation packages available: what *do* you
want to see?
(1.3) As a response to some of the random-setup games like "Act of
Murder" and "When in Rome 2": an extension for Glulx that would use an
external file to track which scenarios of a partly-randomized game the
player has already won, so that on subsequent playings he could be
guaranteed a new scenario until all the scenarios have been exhausted
(rather than chance into replaying the same one).
And some suggestions that have been aired about extension management
in the past:
(3.1) That there should be a way to archive extensions with a project,
so that the old versions will be retained even as Inform moves
forward;
(3.2) That old versions of extensions should in fact be maintained on
the Inform website, for the use of people working with legacy releases
of the program;
(3.3) That the Inform application should, under some circumstances,
automatically download updates of extensions.
Other stuff, though? What are we missing?
-- Graham Nelson and Emily Short
Eric Forgeot
> 1) Are there specific (or general) areas where you feel the extensions
> contributed so far are lacking? For instance, are there particular
> kinds of functionality that you have tried to find an extension to
> help with, but found nothing that met your needs?
great survey idea :)
I don't use many extensions myself, and there are already plenty that I
haven't tested yet, and that looks appealing so I don't have any particular
request.
I would only suggest, if possible, to include in every new releases of
Inform 7, all the extensions found on the website. It may be easier for
authors to pick one when they need to. It's not particularly heavy in size,
so it wouldn't increase much the size of the package. They could be
classified as "external extensions" for example.
I wonder also if it wouldn't be positive to create some kinds of objects
like the ones we can find for 3D models : some animals (cats, dogs, fish),
some tools (weapons and such), some materials (stone, fabric etc) with
default answers for general interactions. So people could pick them easily
for their project (or derive from them).
I'm also thinking about the status of translated extensions, or modified
extensions. Should they bear the name of the translator / the one who
modified the extension ? If so, is there a way to track the name of the
original author, to respect the Creative Common attribution licence. For
example it could be like this :
Chitchat Rules by John Doe, based on Version 3 of Conversation Rules by Eric
Eve, begins here.
or :
Chitchat Rules by John Doe (based on Version 3 of Conversation Rules by Eric
Eve) begins here.
or even :
Chitchat Rules by John Doe begins here. It's based on Version 3 of
Conversation Rules by Eric Eve.
Gerald
> 3) Are there ways that the website/extension providing could work
> better?
There are two things that I think could/would help:
First (and probably simplest), include better and more thorough
instructions (a) in the documentation, and (b) at the website, for how
to actually install the extensions properly. Currently, unless I'm
missing something completely obvious, I have to know where in my
installation of Inform the extensions are stored (which requires knowing
where it is installed), create a new folder for the author (if there is
not already an existing one), and save the file there. I could also open
a new extension from within Inform, copy and paste the text from the web
site, and save it in the appropriate place. It took me a few tries to
figure this out. Either way it's cumbersome and awkward.
Which leads me to my second suggestion: perhaps there could be a way for
the Inform IDE to connect directly to the web site, give me a list of
available extensions (perhaps even marking or excluding those which are
already installed--and as long as we're dreaming, to identify extensions
with newer versions as well), and allow me to do a "one-click install"
from there. Alternatively (or perhaps in addition), provide the
extensions in both text format and with some other file name extension
(OK, yes, I'm using Windows, but I'm sure there is a parallel approach
in other OSes) so that upon downloading the file, it automatically opens
Inform and proceeds to install itself in the appropriate location.
Gerald
Hector Rodriguez
There is one functionality that I would certainly welcome. Several
months ago, I tried to split the glulx window into, for instance, a
top and a bottom window, and then allow the player to type text on
either of the two windows. If the player types on the top window, she
becomes one character, and if she types on the bottom window, she
becomes another. I got this to work (except for a minor glitch in
Gargoyle, which I cannot quite figure out). Still, my code is probably
very bad (I think I posted a version of it in a thread some time ago)
and it would be great if someone could come up with a solid
implementation. (My implementation is available for anyone who might
want to see it, so you as you promise not to laugh too hard...)
I am also interested in the idea of interactive comics. I am not quite
sure what that would mean, though, so I can hardly ask for specific
assistance there...
I also remember Victor's essay on IF and community (for the Innovation
comp). Some of his suggestions (about allowing players to set the
rules for the game world) would help to expand the artistic
possibilities of this form. I think the new, expaneded text-handling
capabilities go a long way towards allowing the player (for instance)
to create new objects and new characters and place them in the game
world. But I am not sure how the player could possibly generate rules
that govern change in the system. (In other words, anything that would
open up the system, so that it is no longer evolving in terms of a
finite set of rules that have been predefined, would be a breath of
fresh air).
Thanks for the work you guys are doing.
Emily Short
> Emily Short wrote:
> > 3) Are there ways that the website/extension providing could work
> > better?
>
> There are two things that I think could/would help:
>
> First (and probably simplest), include better and more thorough
> instructions (a) in the documentation, and (b) at the website, for how
> to actually install the extensions properly. Currently, unless I'm
> missing something completely obvious, I have to know where in my
> installation of Inform the extensions are stored (which requires knowing
> where it is installed), create a new folder for the author (if there is
> not already an existing one), and save the file there. I could also open
> a new extension from within Inform, copy and paste the text from the web
> site, and save it in the appropriate place. It took me a few tries to
> figure this out. Either way it's cumbersome and awkward.
I'm not in a position to check this on Windows right this second, but
the documentation suggests that the Windows IDE, like the Mac one, has
an "Install Extension" option in the File menu. This should
automatically figure out where to put your extension file, and do so.
This is documented in 2.10, "Installing Extensions".
If it's there and you've managed to miss it, though, your point is
taken -- the website perhaps should mention this on the extensions
page.
The other suggestion sounds like more or less what was meant with
suggestion 3.3: some way for the application to help the author track
upgrades and retrieve and install them without extra trouble.
Gerald
> I'm not in a position to check this on Windows right this second, but
> the documentation suggests that the Windows IDE, like the Mac one, has
> an "Install Extension" option in the File menu. This should
> automatically figure out where to put your extension file, and do so.
> This is documented in 2.10, "Installing Extensions".
>
> If it's there and you've managed to miss it, though, your point is
> taken -- the website perhaps should mention this on the extensions
> page.
Ah, thank you. It is in fact there--somehow in several readings of that
section, though, I missed the one sentence that describes the automatic
installation. Not sure if it's just my admittedly lousy reading skills
(I almost always miss the _one_ obvious clue listed in a room
description that's essential to solving the puzzle I'm working on! ;-),
but perhaps it could be made more explicit--mention the automatic method
first (since this is probably the preferred method) and then explain
where they end up being stored? Another sentence or two describing
exactly _how_ to proceed with installation might make it more clear, too.
BTW, The other obvious place that I had looked for this information was
in Chapter 22--it might be worth either a second mention there, or at
least a cross reference to 2.10.
> The other suggestion sounds like more or less what was meant with
> suggestion 3.3: some way for the application to help the author track
> upgrades and retrieve and install them without extra trouble.
Yes, but with the addition of being able to install new extensions in
this way as well as part of the workflow of writing. What I'm
envisioning is being in the middle of developing a project, and thinking
"Hm, I wonder if there's an extension to do what I'm trying here..." A
simple click on a new tab brings up a list of all existing extensions,
which can then be immediately downloaded and installed without leaving
Inform at all. No idea of course how fiendishly difficult this could
potentially be to actually implement, but it would be nice. :-)
S. John Ross
> contributed so far are lacking? For instance, are there particular
> kinds of functionality that you have tried to find an extension to
> help with, but found nothing that met your needs?
Nothing specific for my own needs, but it would be nifty if some folks
would put some of their favorite homebrew debugging/checking stuff out
there in extension form ... I can always use more debugging assistance :)
> 3) Are there ways that the website/extension providing could work
> better?
It's inconvenient to have to create (in Windows, anyway) the necessary
series of author-labeled subfolders, when the files themselves don't
have the author in the filename and don't open with a double-click in
Windows because they lack an extension (you can drag 'em on to WordPad
and that works just fine, but it slows the process down a lot). This is
one of those problems I suspect I wouldn't have if I weren't a Microserf
slaving away in King Gates' realm, but alas, I am :(
> (3.1) That there should be a way to archive extensions with a project,
> so that the old versions will be retained even as Inform moves
> forward;
Yes yes yes, please yes. Oh god yes. I feel myself becoming aroused at
the thought of it.
> (3.2) That old versions of extensions should in fact be maintained on
> the Inform website, for the use of people working with legacy releases
> of the program;
Yes.
> (3.3) That the Inform application should, under some circumstances,
> automatically download updates of extensions.
That would be very very cool, combined with the (3.1) above. Without the
(3.1) above, it would be uncool.
> Other stuff, though? What are we missing?
This hug! {BIG HUG!} Thanks so much for making a long-time dream start
to come true. Thank you thank you.
--
|| S. John Ross
|| Husband · Cook · Writer
|| In That Order
|| http://www.io.com/~sjohn/bio.htm
S. John Ross
>> If it's there and you've managed to miss it, though, your point is
>> taken -- the website perhaps should mention this on the extensions
>> page.
>
> Ah, thank you. It is in fact there--somehow in several readings of that
> section, though, I missed the one sentence that describes the automatic
> installation. Not sure if it's just my admittedly lousy reading skills
> (I almost always miss the _one_ obvious clue listed in a room
> description that's essential to solving the puzzle I'm working on! ;-),
> but perhaps it could be made more explicit--mention the automatic method
> first (since this is probably the preferred method) and then explain
> where they end up being stored? Another sentence or two describing
> exactly _how_ to proceed with installation might make it more clear, too.
>
> BTW, The other obvious place that I had looked for this information was
> in Chapter 22--it might be worth either a second mention there, or at
> least a cross reference to 2.10.
D'oh!
Ditto on every word above. Especially the bit about missing that one
vital clue.
Emily Short
> There is one functionality that I would certainly welcome. Several
> months ago, I tried to split the glulx window into, for instance, a
> top and a bottom window, and then allow the player to type text on
> either of the two windows. If the player types on the top window, she
> becomes one character, and if she types on the bottom window, she
> becomes another. I got this to work (except for a minor glitch in
> Gargoyle, which I cannot quite figure out). Still, my code is probably
> very bad (I think I posted a version of it in a thread some time ago)
> and it would be great if someone could come up with a solid
> implementation. (My implementation is available for anyone who might
> want to see it, so you as you promise not to laugh too hard...)
I think the ideal way to do this would be to build a design on top of
Jon Ingold's Flexible Windows extension; with a couple of tweaks to
the underlying Glulx Entry Points (which I would also have to upload),
I seem to have such a thing mostly working. There are a few problems
with manipulating the parse buffer, but I bet they could be resolved.
I can't guarantee that this version would be more solid/stable than
yours, but it would at least have the advantage of being built in a
way that would let it co-exist with other Glulx effects, which must be
useful. Also, the I6 content is relatively slight; it's mostly more
accessible I7 stuff.
Anyway, if you'd like to send me your code, I wouldn't mind having a
look at it and seeing if it resolves the remaining issues I'm having.
(I had a look at what you posted before, but it wasn't a complete
game, so I couldn't get it to run on its own and run tests, and I had
some difficulties translating some of the things you'd done to a new
context.)
> I am also interested in the idea of interactive comics. I am not quite
> sure what that would mean, though, so I can hardly ask for specific
> assistance there...
I imagine a graphics window strip along the top of the screen, with
new panels being added at the right and old ones fading off the
left...
I don't know how to do it either, though.
Ron Newcomb
> 1) Are there specific (or general) areas where you feel the extensions
> contributed so far are lacking?
(Yeah. Where's the Strong AI extension?)
Humor aside, my big beef is having to edit extensions for the prose
they output. I believe extensions should either: never use the 'say'
statement, communicating with the parent program through variables,
callbacks, and such, or, use the 'say' alone inside of a named Report
rule. Extensions who use 'say' statements outside of a named Report
rule can't have the 'say' line replaced or de-Listed, forcing the
author to directly edit the extension, which gives the headache of
keeping the customized version separate (and safe from) the real
version. (Especially headachey when the real version upgrades to be
compatible with the latest release of Inform.) May I propose some
kind of treaty for extensions that are Obsessively Silent? Even if
compliance is just a rubber-stamp icon on the website, it's something
to aspire to.
I also may have to edit an extension because the Set Action Variables
don't play nice with outside rules (i.e., my new verb wants to use an
extension's verb's Set Action Variables, but I can't call S.A.V.
directly.) When writing an extension, I'm loathe to use S.A.V. for
the problems my author-users may run into. You can't edit S.A.V. from
the outside AFAIK even if you're re-Listing a rule that makes use of
'em.
Thirdly, though I think this may be outside the scope of the thread,
extensions that can auto-include particular lines if other extensions
are, or are not, used in the same project would be very lovely
indeed. Again, to get around having to edit the extension, or clutter
up the author's work with a bunch of boilerplate extension glue-code.
Finally, I'd like Inform's help Search feature to have an option to
include looking in unused extensions for a solution. Sometimes I know
I saw some feature I know I want, but can't find it because it was in
an obscure extension I haven't even downloaded yet.
> It might be useful to discuss requests here, so that extension authors
> can see where their services might be needed most. We could even
> consider a "requests" page to accompany the extensions website, if
> that would be useful.
That's a good idea. Along with freeform notes, "So-and-so is so-far
into solving this problem", to avoid duplication of work.
> 2) Are there extensions you have yourself tried/wanted to write that
> you couldn't bring about, for some technical reason?
A couple of things:
The whole suite of player meta-commands (NOTIFY, VERBOSE, TRANSCRIPT,
SAVE/RESTORE/RESTART/QUIT, etc.) seem to be tricky to fully play
with. ({lookmode} anyone?) Being newer to the form, I have trouble
remembering they're even there. I'm compiling a list, but how would I
even know the list is complete?
Two, I wrote a Prose Mode extension, but it's messy and requires the
author to do silly stuff like ensure all quotes end in whitespace.
I've no problem -where- I7 puts paragraph breaks, just what a
paragraph break -is-. Seems like I7 should just be printing a
variable, which can be changed by Change..To..., rather than using a
To.. phrase, which can't be edited at all.
> 3) Are there ways that the website/extension providing could work
> better?
I echo the "tighter" Inform7 / extension_website linkage others
mention. Mainly, if help/search could work across everything
seamlessly, that would help.
As for auto-downloading / auto-updating... well, I have slightly
customized certain extensions (see above), so please step lightly
around them.
> (1.2) More/better/different conversation handling. This has been
> somewhat more vaguely described to us by the parties requesting it;
> the strongest sense we get is that the requesters want it to be easier
> to create conversation for I7, to make that aspect of things much more
> writerly and less programmatically fiddly; and that they want to
> produce conversations that appear to flow naturally and preserve a
> sense of context.
I have to frequently use Procedural Rules for ignoring Accessibility
Rules a lot, just so my characters can talk about stuff that isn't
right in their faces. Seems silly. I'd almost suggest an mini-
extention to define a "is talking" kind of Action Group that the
Procedural Rule works on, so all an author would have to do is say
their new verb "is talking" for all those accessibility problems to go
away, but you'd still have to put [any thing] in its Understand, which
would defeat the purpose.
IIRC.
Beyond that, I'm making what I want to see. It may fly or fail.
> (3.1) That there should be a way to archive extensions with a project,
> so that the old versions will be retained even as Inform moves
> forward;
Please.
> (3.2) That old versions of extensions should in fact be maintained on
> the Inform website, for the use of people working with legacy releases
> of the program;
For those of us who clobber our own copies, please. :)
> (3.3) That the Inform application should, under some circumstances,
> automatically download updates of extensions.
As long as it doesn't overwrite the customized versions.
And, a built-in DIFF menu command in the IDE, to compare two versions
of an extension, would be a god-send.
Thank you for asking our opinions, Emily & Graham.
--Ron
Smoov...@gmail.com
> couple of years now, and finally has a draft design that she is alpha-
> testing; nonetheless, more input would be welcome. The new system is
> still some way from being ready for release, and there may still be
> significant design adjustments. Are there more specific requests about
> what such a system ought to do? Those of you who are not satisfied
> with the current set of conversation packages available: what *do* you
> want to see?
>
I know this is a "duh, we already knew that" statement, but what I'm
really looking for out of a conversation system is tweakability. Pre-
current build, I'd been tweaking with the Quip-based conversation
extensions to have an integrated Ask/Tell/Menu system (similar to City
of Secrets, really), because that's the best thing I've come across to
get the effect I'm currently shooting for. But a Zork-style puzzler
may not need the same level of conversational flexibility as, say, a
courtly intrigue, and anything beyond a simple ask/tell would be
guilding the lily.
So being able to integrate menu/ask/tell and possibly even moods, *but
still being able to move those components in and out when the project
demands it* is the kicker. I know it's possible now, I just wish I
was spending more time writing the dialogue than the framework. I am
grateful for the work already done, though.
In any case, I eagerly await these new convo-rules coming out of alpha
testing.
I've got a whole pile of design notes on what I was trying to do with
conversation. If I can find them all and type them up in a coherent
manner, I'll post more.
Emily Short
> Humor aside, my big beef is having to edit extensions for the prose
> they output. I believe extensions should either: never use the 'say'
> statement, communicating with the parent program through variables,
> callbacks, and such, or, use the 'say' alone inside of a named Report
> rule.
Not every occasion for printing text is within an action; sometimes
text needs to be printed elsewhere and a report rule isn't exactly
appropriate. But still, I take your point in a more general sense:
it's good if the extension author puts output text either into an
isolated, replaceable rule or into a variable or table that can be
modified easily by the user.
One of the things Graham and I have talked about on and off is posting
a checklist for extension authors, which would contain things like:
-- have you given an explicit name to every rule?
-- have you isolated text into easily-replaced parts of the code?
-- have you included at least one example?
-- do all your examples have paste buttons?
...and so on. I'm not sure whether that would be felt to be helpful or
just needlessly kindergarten-teacherish. But I agree with you that
this is a good thing where it can be achieved. I haven't always
accomplished it perfectly in my own extensions, but have been
upgrading them as I notice problems with this kind of compliance.
> Extensions who use 'say' statements outside of a named Report
> rule can't have the 'say' line replaced or de-Listed, forcing the
> author to directly edit the extension, which gives the headache of
> keeping the customized version separate (and safe from) the real
> version. (Especially headachey when the real version upgrades to be
> compatible with the latest release of Inform.) May I propose some
> kind of treaty for extensions that are Obsessively Silent? Even if
> compliance is just a rubber-stamp icon on the website, it's something
> to aspire to.
I suppose we could ask people to indicate compliance themselves; I
don't know whether that would satisfy you. I'm a little hesitant to
add a feature whereby I have to do additional checking on an extension
before I post it, though, because I don't always have time to do that
and also keep the site reasonably current with what has been submitted
to me. It is not clear to me that this is something that easily be
automated, either. (Extensions that are sent in with a note from the
author saying 'I'm not sure whether this works; please beta-test it
for me' often take significantly longer for me to get around to
posting, for example. They also make me growl at the screen. It's
always better to find someone other than me to test a complicated
extension before you submit it, if that's humanly possible.)
> I also may have to edit an extension because the Set Action Variables
> don't play nice with outside rules (i.e., my new verb wants to use an
> extension's verb's Set Action Variables, but I can't call S.A.V.
> directly.) When writing an extension, I'm loathe to use S.A.V. for
> the problems my author-users may run into. You can't edit S.A.V. from
> the outside AFAIK even if you're re-Listing a rule that makes use of
> 'em.
Can you give me an example of where this is necessary? Setting action
variables is not, so far as I know, broken in its current incarnation;
it is intentional that one cannot refer to an action's variables from
another action; this is to avoid cross-contamination and to guarantee
that if you call an action recursively somehow, the nested case
doesn't overwrite the action variables of its parent (as would happen
if we were using global variables).
If two actions are doing more or less the same thing, a good approach
is often to redirect the second action into the first, somehow, rather
than trying to make the second action mirror the first.
> Thirdly, though I think this may be outside the scope of the thread,
> extensions that can auto-include particular lines if other extensions
> are, or are not, used in the same project would be very lovely
> indeed. Again, to get around having to edit the extension, or clutter
> up the author's work with a bunch of boilerplate extension glue-code.
No, that's not outside the scope of this thread, and is actually
something that I should have put on the list, because you're not the
first person to have asked for it.
> Finally, I'd like Inform's help Search feature to have an option to
> include looking in unused extensions for a solution. Sometimes I know
> I saw some feature I know I want, but can't find it because it was in
> an obscure extension I haven't even downloaded yet.
Hm. I have no idea how practical that is.
> That's a good idea. Along with freeform notes, "So-and-so is so-far
> into solving this problem", to avoid duplication of work.
Might need to be a wiki; would almost certainly become obsolete, as
people ditched projects they had started work on but didn't update the
page. Still, it's a thought; there might be ways to deal with those
drawbacks.
> The whole suite of player meta-commands (NOTIFY, VERBOSE, TRANSCRIPT,
> SAVE/RESTORE/RESTART/QUIT, etc.) seem to be tricky to fully play
> with. ({lookmode} anyone?) Being newer to the form, I have trouble
> remembering they're even there. I'm compiling a list, but how would I
> even know the list is complete?
Aren't these listed in "Actions out of world" in the actions index?
(This doesn't address the question of access to lookmode, but I think
the list qua list is complete.)
> Two, I wrote a Prose Mode extension, but it's messy and requires the
> author to do silly stuff like ensure all quotes end in whitespace.
> I've no problem -where- I7 puts paragraph breaks, just what a
> paragraph break -is-. Seems like I7 should just be printing a
> variable, which can be changed by Change..To..., rather than using a
> To.. phrase, which can't be edited at all.
I suspect the answer there is that it's doing something more
complicated than just printing some text; it's checking for various
conditions.
What sort of thing would you like to be able to do here? Make a
paragraph break a single line break followed by indentation (or a
change along those lines)? Or something else?
> I have to frequently use Procedural Rules for ignoring Accessibility
> Rules a lot, just so my characters can talk about stuff that isn't
> right in their faces. Seems silly. I'd almost suggest an mini-
> extention to define a "is talking" kind of Action Group that the
> Procedural Rule works on, so all an author would have to do is say
> their new verb "is talking" for all those accessibility problems to go
> away, but you'd still have to put [any thing] in its Understand, which
> would defeat the purpose.
Hm, okay, I'm slightly confused here. If I say, for instance,
Understand "ask [someone] about [any thing]" as interrogating it
about. Interrogating it about is an action applying to one thing and
one visible thing.
...then I should not get any kind of accessibility problem in
discussing any object/topic in the game. Are you doing this and still
having problems?
> Beyond that, I'm making what I want to see. It may fly or fail.
Excellent.
Gerald
>> 3) Are there ways that the website/extension providing could work
>> better?
>
> I echo the "tighter" Inform7 / extension_website linkage others
> mention. Mainly, if help/search could work across everything
> seamlessly, that would help.
>
> As for auto-downloading / auto-updating... well, I have slightly
> customized certain extensions (see above), so please step lightly
> around them.
If you're altering an extension, is it appropriate then to consider Eric
Forgeot's earlier suggestion of modifying the attribution so that the
altered version you create would now have your name as the author with a
reference to the original (e.g. something like "Conversation Management
by Ron Newcomb; based on Reactable Quips version 8 by Michael Martin")?
Then an automatic updating system wouldn't muck with your altered
version, but it might be able to notice that there's a newer version of
an extension you've modified so that you could go see if you want to
work with the old version or need to modify your custom one accordingly.
Emily Short
> On Nov 16, 2:46 pm, Emily Short <emsh...@mindspring.com> wrote:
>
>
>
> > Emily has been thinking about how best to do I7 conversation for a
> > couple of years now, and finally has a draft design that she is alpha-
> > testing; nonetheless, more input would be welcome. The new system is
> > still some way from being ready for release, and there may still be
> > significant design adjustments. Are there more specific requests about
> > what such a system ought to do? Those of you who are not satisfied
> > with the current set of conversation packages available: what *do* you
> > want to see?
>
> > -- Graham Nelson and Emily Short
>
> I know this is a "duh, we already knew that" statement,
It is nice to have one's ideas confirmed, of course...
> but what I'm
> really looking for out of a conversation system is tweakability. Pre-
> current build, I'd been tweaking with the Quip-based conversation
> extensions to have an integrated Ask/Tell/Menu system (similar to City
> of Secrets, really), because that's the best thing I've come across to
> get the effect I'm currently shooting for. But a Zork-style puzzler
> may not need the same level of conversational flexibility as, say, a
> courtly intrigue, and anything beyond a simple ask/tell would be
> guilding the lily.
One of the design principles of the draft system is that the
presentation level should be semi-separate from the other internals,
so that the author should be able to switch relatively painlessly
between plain ASK/TELL, a TADS 3-style prompted ASK/TELL, and various
types of menu. The choice of output system will probably somewhat
affect the way the author writes his conversational content, but it
should be easy to select one of several different rules for indicating
conversation options to the player.
That's a goal, anyway.
Rioshin an'Harthen
news:b70306fd-f136-49d5...@41g2000hsh.googlegroups.com...
> On Nov 17, 2:25 am, Ron Newcomb <psc...@yahoo.com> wrote:
>
>> Thirdly, though I think this may be outside the scope of the thread,
>> extensions that can auto-include particular lines if other extensions
>> are, or are not, used in the same project would be very lovely
>> indeed. Again, to get around having to edit the extension, or clutter
>> up the author's work with a bunch of boilerplate extension glue-code.
>
> No, that's not outside the scope of this thread, and is actually
> something that I should have put on the list, because you're not the
> first person to have asked for it.
Maybe something like
If the extension Atmospheric Effects by Mikael Segercrantz is included
If the extension Atmoshperic Effects by Mikael Segercrantz is not
included
for conditions, so that we could in a rule use the rule of another
extension, if the game is including it, and default to something else if
not - maybe that extension contains features that the game author does not
want to use, eg. some heavy every turn rules.
Then, for sections in the source code, we could use something like
Section 1E (When the extension Atmospheric Effects by Mikael Segercrantz
is included)
Section 1N (When the extension Atmospheric Effects by Mikael Segercrantz
is not included)
and have separate rules.
I see the first version with the if statements as the better option, when a
somewhat lengthy rule might want to access features from another extension
in a few places only, while the second one for sections, chapters etc. is
for a rule that just about delegates responsibility to the other extension.
Possibly add also conditions like
If compiling for Glulx
and
If compiling for Z-machine
to complement the current (for Glulx only) and (for Z-machine only) in case
there's only very little difference between the two versions of some code.
S. John Ross
> If you're altering an extension, is it appropriate then to consider Eric
> Forgeot's earlier suggestion of modifying the attribution so that the
> altered version you create would now have your name as the author with a
> reference to the original (e.g. something like "Conversation Management
> by Ron Newcomb; based on Reactable Quips version 8 by Michael Martin")?
I'd personally be uncomfortable with this as an _automatic_ change, but
that's a reflection of my own habit of making _extremely_ microscopic
changes to extensions to match a game's style. In that case, it remains
Extension by Joe (with vain little tweaks by S. John) instead of
anything like Extension II by S. John based on Extension by Joe. I feel
sheepish enough about accepting the generosity of the community without
plastering my name in front as well :)
As a clickable option, I'd be all for it.
Gerald Aungst
>
>> If you're altering an extension, is it appropriate then to consider
>> Eric Forgeot's earlier suggestion of modifying the attribution so that
>> the altered version you create would now have your name as the author
>> with a reference to the original (e.g. something like "Conversation
>> Management by Ron Newcomb; based on Reactable Quips version 8 by
>> Michael Martin")?
>
> I'd personally be uncomfortable with this as an _automatic_ change, but
> that's a reflection of my own habit of making _extremely_ microscopic
> changes to extensions to match a game's style. In that case, it remains
> Extension by Joe (with vain little tweaks by S. John) instead of
> anything like Extension II by S. John based on Extension by Joe. I feel
> sheepish enough about accepting the generosity of the community without
> plastering my name in front as well :)
>
> As a clickable option, I'd be all for it.
>
I think what I really had in mind was letting the author control it, but
making the IDE aware of the pedigree of the extension. Since the person
making the changes knows best how radical they are, they would also be
the one in the best position to determine whether upgrading the
extension would mess with the changes (and thus would be a candidate for
being a "new" extension rather than a microscopically altered one).
If the changes are essentially cosmetic, it's probably not a new
extension, but if _functionality_ is different, even a little, I'd
consider it a new one worthy of a new name.
It also occurred to me that you then run into potential problems if
someone takes an altered extension and changes it more.... I could
foresee "Complex Extension by S. John Ross; based on Simple Extension by
Gerald Aungst; based on Altered Extension by Han Solo; based on...." In
this case it probably makes sense to just keep the most recent ancestor.
--
Gerald
Ron Newcomb
> appropriate. But still, I take your point in a more general sense:
> it's good if the extension author puts output text either into an
> isolated, replaceable rule or into a variable or table that can be
> modified easily by the user.
Thank you for answering what I meant to say, rather than what I
said. (If only I7 could do the same!)
> -- have you given an explicit name to every rule?
> -- have you isolated text into easily-replaced parts of the code?
(snip)
> ...and so on. I'm not sure whether that would be felt to be helpful or
> just needlessly kindergarten-teacherish.
It would be helpful... "helpful" isn't quite the right word...
"instructive"? But reword it as:
A high-quality extension:
- gives an explicit name to every rule
- isolates text into easily-replaced parts of code
....and so on. Yeah, remove the "Have you"s and I think you're
golden.
On the subject, I have a question. I have a named Check rule that
Says why it failed, but the author-user can't override it without also
overriding the complex conditions Check is checking. Report rules
won't run if Check prevents the action, there aren't Unsuccessful
Report rules, and I don't wish to require my author-user to clutter
her code with a bunch of "if the reason the action failed is the X
rule" kind of statements. So where do I put the default Say replies
that each Check would print? I want to include default messages of
why something failed because its useful in debugging, but I still want
my author-user to override them easily before she releases her game.
Anyway, can we all create this "compliance" checklist in full and give
it a name? I have at least one extension I'm about ready to show the
world.
> But I agree with you that
> this is a good thing where it can be achieved. I haven't always
> accomplished it perfectly in my own extensions
Yeah I know; I found places sometimes where you just can't work around
something. If the extension author at least documents it, "This bit
here isn't Checklist-compliant because ..(gory technical details)..",
then I'd still call the extension compliant (as-it-can-be).
Usefulness trumps pat paradigms. So, I would like adding that point
to the checklist.
> I suppose we could ask people to indicate compliance themselves;
I'm fine w/that. We can all lean on raif to point out the occasional
problem. Most creators are pretty trustworthy as far as representing
their own work, in my experience. Besides, even a well-intentioned
author may miss something occasionally. More eyeballs = better
quality anyway.
> (Extensions that are sent in with a note from the
> author saying 'I'm not sure whether this works; please beta-test it
> for me'
(I'm surprised you take the time to entertain these, actually. Myself
is much more hard-nosed about "do your own work".)
You mentioned yourself re-tests extensions when I7 upgrades. Anything
to add to the checklist to make that easier for you? What makes a
good regression test? (...for the way you'll eventually have
completely automated, of course.)
(Uh, for anyone not familiar with software engineering, a regression
test simply re-checks old features to make sure the new features
didn't break them.)
>> Set Action Variables and extensions
> Can you give me an example of where this is necessary? Setting action
> variables is not, so far as I know, broken in its current incarnation;
I reviewed my extension to refresh memory on what the deal was:
I made a GO TO verb with a named Check rule I needed to add to normal
cardinal movement. (We'll call this new Check rule "foo".) I wanted
to simply List "foo" in both actions' Check rules, so if the author-
user overwrote or modified Foo, it would be ready to work regardless
of how the player moved around. But, S.A.V. was a problem. Two
different workarounds: I'd have to make Foo set its variables again
just so it would work regardless of which context it was checked in,
or, make two Foos and hope my author-user read my extension's docs so
she'd know she'd get weird behavior if she didn't change them both in
identical ways.
So, listing a named rule in multiple rulebooks is a great I7 feature,
but S.A.V. means each rulebook has some context, an environment, that
our rule might not feel at home in. Since I can't explicitly call
S.A.V. from our rule if all the necessary context isn't already there,
I'm inclined not to use S.A.V. It wouldn't be a problem if this were
a one-shot solution -- just ad-hoc anything til it works -- but
extensions aren't one-shot solutions. (Understanding the needs of
recursion, I'm not so sure there's a good solution here, honestly.)
Alternately, regarding having the two Foos, I7 doesn't support
#assertions -- author-defined compiler errors -- which would be useful
for extension writers. (i.e., "#if <condition> then cause problem
message 'The docs for extension Foobar say you must ensure <condition>
to avoid <bad thing>, but you haven't. This is a loose end you still
need to tie up. Please see Foobar's docs [link] for details on how
and why this is necessary.'")
> If two actions are doing more or less the same thing, a good approach
> is often to redirect the second action into the first, somehow, rather
> than trying to make the second action mirror the first.
My existing solution re-directs cardinal movement into the GO TO, but
it breaks I7 code of the form "going from X" or "entering (this room)
from the Gazebo". So, still not ideal.
> Aren't these listed in "Actions out of world" in the actions index?
> (This doesn't address the question of access to lookmode, but I think
> the list qua list is complete.)
True, but when I use the Search box to search the docs, NOTIFY only
pulls up a single hit about awarding points (not customizing the meta-
command), and VERBOSE pulls up nothing relevant.. as if the command
didn't exist.
In the actions index, placing that important section beneath "Actions
which always do nothing...." doesn't help, cause I usually stop
reading at that particular heading. Even though the next section is in
red, you'd have to scroll down further to see it.
Perhaps I just need a super-example of how to modify all of them,
rather than an extension, if they're all already available to be
modified.
> > Two, I wrote a Prose Mode extension, but it's messy and requires the
> I suspect the answer there is that it's doing something more
> complicated than just printing some text; it's checking for various
> conditions.
I'm cool with its conditions, I just want to modify the result if they
check out OK.
> What sort of thing would you like to be able to do here? Make a
> paragraph break a single line break followed by indentation (or a
> change along those lines)?
In a word, yes. I found things I did & didn't like about Jon Ingold's
"My Angel", which used an I6 prose mode. One of which, prose mode
should depend upon the width of the screen. If the screen's as wide
as my coffee-table book on Architecture, (or as wide as random
netizen's blog entries), then non-indented blank-line-separated
paragraphs are appropriate. Same with extra-thin screens, such as PDAs
and a Commodore-64's 40-column screen. But there's a sweet-spot in
the middle that newspaper- and novel-style paragraphs work better.
And novels & newspaper columns, being of that width, use that indented
format.
> > I have to frequently use Procedural Rules for ignoring Accessibility
> > Rules a lot,
> Hm, okay, I'm slightly confused here. If I say, for instance,
> Understand "ask [someone] about [any thing]" as interrogating it
> about. Interrogating it about is an action applying to one thing and
> one visible thing.
I'm aware of that solution, but it seems like a bug to me. Usually,
the more adjectives you add to an I7 Description, the more restricted
group of things you get back (i.e., "carried things" vs. all
"things"). I don't see how "visible things" is -less- restrictive
than "things". Your above example breaks this pattern of increasing
restrictiveness, which makes it look like a bug, and so I trust it
not. The procedural rule approach, while verbose, is clear about the
author's intention.
--Ron
Michael Martin
> Not every occasion for printing text is within an action; sometimes
> text needs to be printed elsewhere and a report rule isn't exactly
> appropriate. But still, I take your point in a more general sense:
> it's good if the extension author puts output text either into an
> isolated, replaceable rule or into a variable or table that can be
> modified easily by the user.
>
> One of the things Graham and I have talked about on and off is posting
> a checklist for extension authors, which would contain things like:
>
> -- have you given an explicit name to every rule?
> -- have you isolated text into easily-replaced parts of the code?
> -- have you included at least one example?
> -- do all your examples have paste buttons?
>
> ...and so on. I'm not sure whether that would be felt to be helpful or
> just needlessly kindergarten-teacherish. But I agree with you that
> this is a good thing where it can be achieved.
I was actually going to fold something similar into Reactable Quips
and Quip-Based Conversation for the bugfix update, but found that I
was having to do too much research on the matter for it. If this was
set up as a checklist and possibly a refactoring guide, I for one
would appreciate it.
The refactoring guide would be particularly nice -- I was hoping to
use activities to do the reporting with but worried about how to
properly encapsulate some of the computed values. It would be nice to
throw them around as arguments, but then there are namespace issues,
making it harder to extend, etc.
--Michael
Emily Short
> I have a named Check rule that
> Says why it failed, but the author-user can't override it without also
> overriding the complex conditions Check is checking. Report rules
> won't run if Check prevents the action, there aren't Unsuccessful
> Report rules, and I don't wish to require my author-user to clutter
> her code with a bunch of "if the reason the action failed is the X
> rule" kind of statements. So where do I put the default Say replies
> that each Check would print?
There are several options here, of varying verbosity. I usually put
text that I want to make easily replaced into a text variable or
property (properties especially if the author is likely to want to
change the message on an object-by-object basis); or I make a table of
output, using some special kind of value as a key; or I make an
activity. This is obviously the most high-powered choice, since it
gives the user near infinite options for adding complexities and
special conditions, but it's almost certainly overkill in the 'check'
situation you describe.
> Anyway, can we all create this "compliance" checklist in full and give
> it a name? I have at least one extension I'm about ready to show the
> world.
Graham and I have been trading notes on a draft checklist. I suspect
it will be ready to post after another exchange or two, but of course
if people have more ideas they want to throw in, to make sure we've
thought of them, that's welcome.
> You mentioned yourself re-tests extensions when I7 upgrades. Anything
> to add to the checklist to make that easier for you? What makes a
> good regression test? (...for the way you'll eventually have
> completely automated, of course.)
Well, ideally: the extension examples should cover all the
functionality that needs to be tested (either in one sample or in
several, depending on the complexity of the extension); and they
should include a "test me" script, just like the manual examples,
which will put the example through its paces. We already have an
automator that runs all the "test me" scripts of all the manual
examples and compares them against the ideal transcripts; we could do
something similar with extension examples, but don't have ideal
transcripts for most of those. (The exception is the set of bundled
extensions, like Locksmith.)
Anyway, if we get more sophisticated about regression-testing
extensions, adhering to the same techniques as the manual examples
will make it easier to automate.
> Alternately, regarding having the two Foos, I7 doesn't support
> #assertions -- author-defined compiler errors -- which would be useful
> for extension writers. (i.e., "#if <condition> then cause problem
> message 'The docs for extension Foobar say you must ensure <condition>
> to avoid <bad thing>, but you haven't. This is a loose end you still
> need to tie up. Please see Foobar's docs [link] for details on how
> and why this is necessary.'")
Hm, that's an interesting idea.
In the conversation code I've been working on, I have some tests that
run at the start of play and abort the game (with an explanation of
what to fix) if they detect certain kinds of error in the code; but
being able to generate my own problem messages would be even better
for some of this. Though, again, I have no idea how feasible that is.
> True, but when I use the Search box to search the docs, NOTIFY only
> pulls up a single hit about awarding points (not customizing the meta-
> command), and VERBOSE pulls up nothing relevant.. as if the command
> didn't exist.
...
> Perhaps I just need a super-example of how to modify all of them,
> rather than an extension, if they're all already available to be
> modified.
Okay. This mostly sounds like a request for documentation
improvements, and (probably) the addition of access to lookmode as
part of the Standard Rules; doesn't sound too hard to me, but also
doesn't seem like extension territory. Noted.
> > What sort of thing would you like to be able to do here? Make a
> > paragraph break a single line break followed by indentation (or a
> > change along those lines)?
>
> In a word, yes.
Okay. I don't know how easy this would be, but at least now I
understand the request.
> I'm aware of that solution, but it seems like a bug to me. Usually,
> the more adjectives you add to an I7 Description, the more restricted
> group of things you get back (i.e., "carried things" vs. all
> "things"). I don't see how "visible things" is -less- restrictive
> than "things". Your above example breaks this pattern of increasing
> restrictiveness, which makes it look like a bug, and so I trust it
> not.
Hm. It's a fairly old and fundamental rule, and exemplified
repeatedly; Inform assumes that touchability is a minimum requirement
for all nouns unless it's told otherwise, but this was (as far as I
know) a choice based simply on the fact that such actions are the most
common in IF situations.
Anyway, I'm not sure what to suggest about the trust issue, but this
code *does* work, and I suspect is likely to continue working for the
foreseeable future, unless someone convinces us that action
definitions ought to default differently.
Emily Short
> The refactoring guide would be particularly nice -- I was hoping to
> use activities to do the reporting with but worried about how to
> properly encapsulate some of the computed values. It would be nice to
> throw them around as arguments, but then there are namespace issues,
> making it harder to extend, etc.
I am not quite sure what you're looking for. An overview of the
various ways to isolate text in the extension, with some comments
describing when each is suitable?
Ron Newcomb
> There are several options here, of varying verbosity. I usually put
> text that I want to make easily replaced into a text variable or
Amazing how the most obvious solution walked right by me... Thanks.
> Graham and I have been trading notes on a draft checklist.
We look forward to seeing it!
> Well, ideally: the extension examples should cover all the
> functionality that needs to be tested [...] in a "test me" script [...] an
> automator runs and compares them against the ideal transcripts
A "test me" script who's output will be compared to its output under
the previous I7 version. Easy enough.
> adhering to the same techniques as the manual examples
> will make it easier to automate.
As long as the checklist lets us know exactly what they are, great!
>> #assume
> Hm, that's an interesting idea.
At least it's in the thinktank.
> Hm. It's a fairly old and fundamental rule, and
> Inform assumes that touchability is a minimum requirement
I'm new. No rule is old or fundamental to me. (A blessing and a
curse.) :-/
I didn't know "things" actually meant "touchable things", but the
reasoning makes sense; I just needed clueing in. Now your code seems
trustworthy since I know why it works. But now I'm tripping over
naming issues: why not "any" undoing "touchable", as it does in
Understand statements?
But now I'm off-topic.
--Ron
Ron Newcomb
> you couldn't bring about, for some technical reason?
Date-time?
I can sorta manage with Units...
A date-time is a kind of value. 45-3:59 specifies a date-time with
parts daycount, hours, minutes.
...but I feel like I'm reinventing the wheel, since I7's Time
functions so well. I definately want both the coarse-grained and fine-
grained measures of chronology to be the same unit, so they would be
the same table-column. Makes comparisons much much easier. Say..
statements convert daycount to names of months, weekdays, etc.
Mike
out some error checking when the code is first run and issue error
message. I think that this is an excellent idea. Perhaps I7 needs to
provide some hooks so that the exension author can abort compiliation
where there is an error and to display error messages elegantly. I
tried to provide some of this functionality in my patrollers extension
but the resulting error messages are far from pretty and I needed to
fall back to some I6 code to abort compilation.
Going back to Emily's earlier request of areas that extensions could
usefully cover, I think that it would be useful if the functionality
allowing continuous spaces such as in the examples "Rock Garden" or
"Stately Gardens" could be encapsulated within an exension possible
along the lines of Eric Eve's ConSpaces TADS3 extension.
isd
* Thanks for this survey, it gives the feeling that the users can
take some part in the development ^_^
* About the extensions I would like to see : I was looking for a good
combat system, but I was only able to find something pretty much
rudimentary. I was also looking for an extension that could help me to
simulate liquids but there was nothing that would behave the way I
wanted. I know there are limits to realism but the extensions as well
as the examples in the manual always seem to be written from a
contextual point of view, and it is very hard to use the same code for
different contexts, or to add it to an already existing game. I'd like
more extensions that simulates the real world behavior, the more
realistically possible (and that allow us to add things/customize them
to adapt them to the context of our game). I know this is a very
difficult request though...
* The extensions are not as easily tested as the examples in the
manual. I could be nice to be able to test them on the fly. For the
updating process I think firefox is a nice example. It doesn't auto-
update, it prompts the user before, and the non compatible versions
are in grey. I think all the extensions should be bundled with the
standard distribution of inform. For the website I would like that all
the extensons that are not compatible with the last version have their
text in grey, so we don't lose time with them. The current design is
to write those that are compatible, this is a pain to browse. The
"updated" or "new" labels are nice but we have no way to really know
what has been updated precisely... it would be nice to have a change
log accessible.
* (3.1) I agree with that. It is a good idea to bundle the extension
with the project. It also allow to edit the extension easily for this
project only, and the original extension is still available for other
projects.
Emily Short
> * About the extensions I would like to see : I was looking for a good
> combat system, but I was only able to find something pretty much
> rudimentary.
About this one, I would say: I've never seen a really good combat
system in any work of IF. I don't know what one would look like.
Randomized combat is annoying because the player can just UNDO any
problems; non-randomized combat is often pretty repetitive. (Slap That
Fish gets closer than some with its optimization puzzle, but even
there, lots of reviewers seem to have found it quite repetitive and
unappealing.)
This is a round-about way of saying that someone might be willing to
write such a thing if they knew what it ought to do -- but I certainly
do not.
> I was also looking for an extension that could help me to
> simulate liquids but there was nothing that would behave the way I
> wanted.
Do any of the examples at least introduce a system that would suit
you?
> I know there are limits to realism but the extensions as well
> as the examples in the manual always seem to be written from a
> contextual point of view, and it is very hard to use the same code for
> different contexts, or to add it to an already existing game.
We recently (just in this build) restructured a number of the manual
examples that we thought were most likely interesting to re-use, and
put the generalizable stuff first. This list includes "Costa Rican
Ornithology", "Crusoe", "Farewell", "Juggling", "Nickel and Dimed",
"Money for Nothing", "Aftershock", "Channel 2", "Four Cheeses", and
Bogart". Do those still seem hard to pull the system out of? Is there
something we could do that would improve them in that respect?
Emily Short
> > 2) Are there extensions you have yourself tried/wanted to write that
> > you couldn't bring about, for some technical reason?
>
> Date-time?
>
> I can sorta manage with Units...
>
> A date-time is a kind of value. 45-3:59 specifies a date-time with
> parts daycount, hours, minutes.
>
> ...but I feel like I'm reinventing the wheel, since I7's Time
> functions so well.
So what would help you be able to write such an extension?
Emily Short
> Going back to Emily's earlier request of areas that extensions could
> usefully cover, I think that it would be useful if the functionality
> allowing continuous spaces such as in the examples "Rock Garden" or
> "Stately Gardens" could be encapsulated within an exension possible
> along the lines of Eric Eve's ConSpaces TADS3 extension.
"Rock Garden" is pretty lightweight, though I've just now gone back
and rearranged it into separate "generic" and "scenario" sections to
make it even easier to extract the general part of the code for re-
use.
I went and had a look at ConSpaces, and (assuming I understand) it's
doing something a bit different from "Stately Gardens": whereas SG has
a comparatively simple model of movement to adjacent locations and
spends most of its energy on autogenerating complex descriptions of
what's around, ConSpaces focuses more on having different kinds of
paths between locations, allowing and disallowing implicit movement in
a complex way.
So my question is, I guess, what in particular you want this
hypothetical extension to do. RG simply lists what's in any rooms you
can see into, and automatically moves you if you try to interact with
the other things; that seems like a baseline level of behavior, but
not complex enough to deserve its own extension.
Ron Newcomb
> On Nov 18, 3:57 am, Ron Newcomb <psc...@yahoo.com> wrote:
> So what would help you be able to write such an extension?
What I found so far in tinkering, before backing away from the
problem:
A date is a kind of value. 12/31/9999 specifies a date with parts
month, day, year.
...That only works for Glulx, due to number size. Attempts to define a
date like 23 November 2007 just won't work, even if I declare a kind-
of-value "month" -- it doesn't recognize the word as something other
than a literal tag, like "kg". The dd/dd/dddd syntax is ambiguous per
American/European conventions, though a workaround is yyyy/mm/dd so
everybody's equally unhappy. I won't even attempt the American
convention with its comma, March 30, 1969.
I7's "At..." scheduling phrase. How's an extension to change it to
accept types of Date and Date-Time? Adventures usually take place
over an unbroken stretch of time, but dramas and detective
investigations come in fits & starts over the course of days, weeks...
sometimes longer. Dynastic dramas span generations. I'd like to be
able to schedule Christmas.
Plus, just the ickyness of writing all the glue code to make three
different-but-related types Time, Date, and Date-Time work
together... ugh. It would seem to save a lot of man-hours and a
fat, ungainly plethora of nitpicky code if I7's Time were expanded to
be the more the general Date-Time, solving the issue once & for all,
instead of leaning on an outside solution to attach itself like a
remora.
To recap :
1) glulx required for the Unit specification
2) syntax of Unit: 2005/11/23 instead of the more readable 23
November 2005
3) clunkly or non-existant "At..." scheduling integration. Think of
poor baby Jesus.
4) full date-time spec (can't be done in Units?): 23 November 2005 @
3:32 pm
That's just what I've found so far.
isd
> On Nov 18, 6:13 am, isd <ionsupplydr...@gmail.com> wrote:
>
> > * About the extensions I would like to see : I was looking for a good
> > combat system, but I was only able to find something pretty much
> > rudimentary.
>
> About this one, I would say: I've never seen a really good combat
> system in any work of IF. I don't know what one would look like.
> Randomized combat is annoying because the player can just UNDO any
> problems; non-randomized combat is often pretty repetitive. (Slap That
> Fish gets closer than some with its optimization puzzle, but even
> there, lots of reviewers seem to have found it quite repetitive and
> unappealing.)
>
> This is a round-about way of saying that someone might be willing to
> write such a thing if they knew what it ought to do -- but I certainly
> do not.
Well, I am in fact in the process of writing such combat code and I am
positive on the possibility to make it interesting.
Of course it is only my point of view of what could be a "fun" combat
system, and it is pretty much inspired of my mudding experience so it
obviously includes some sort of repetitive text that is absolutely not
litterature... But that tries to give the player the feeling of some
"interesting" realism.
The player attacking part is almost finished. It works but it is
pretty ugly code (some "to" statements with a lot of cascading If/
otherwise...).
>
> > I was also looking for an extension that could help me to
> > simulate liquids but there was nothing that would behave the way I
> > wanted.
>
> Do any of the examples at least introduce a system that would suit
> you?
Yes of course.
Lakeside living and frizz were very useful.
Since, as I said, I am coding a combat system, I need also to code the
blood as a liquid (for sake of realism at least I'd like to try and if
it is overkill I will just completely give up this part, which is, in
fact, a detail).
To have some blood that would gather and "soak" clothes or the floor,
and have its volume in the location increase (whether it is the blood
of creature A, B, or C), or decrease depending on the texture of the
floor... or change state when coagulating... I have not even started
to code it but I know I should start by defining it as a kind of value
(at least).
I know it is unecessary realistic but if it is not overkill to code
there is no reason I would want to make it simpler.
> > I know there are limits to realism but the extensions as well
> > as the examples in the manual always seem to be written from a
> > contextual point of view, and it is very hard to use the same code for
> > different contexts, or to add it to an already existing game.
>
> We recently (just in this build) restructured a number of the manual
> examples that we thought were most likely interesting to re-use, and
> put the generalizable stuff first. This list includes "Costa Rican
> Ornithology", "Crusoe", "Farewell", "Juggling", "Nickel and Dimed",
> "Money for Nothing", "Aftershock", "Channel 2", "Four Cheeses", and
> Bogart". Do those still seem hard to pull the system out of? Is there
> something we could do that would improve them in that respect?
Oh, I haven't checked the new examples (sorry... I was just updating
my code to the new version)... but since I am interesting with a
general purpose clothing system (still for combat realism purposes) I
came across "what not to wear" that seems ot be some kind of a
base...
I will look at the examples and tell you ^_^
At any rate, I am interested in any improvement towards real world
simulation (since it is maybe the most challenging thing to do). I
must say I prefer examples to extensions (for the moment) since they
are more easily searched, accessed and tested, as well as reused.
So I may add that making more examples would be even better than
making more extensions... or just make the extensions be examples (I
think this may be difficult from the author point of view but frm the
user one it would be the perfect solution maybe, just copy and paste,
and modify what needs to be).
isd
> > examples that we thought were most likely interesting to re-use, and
> > put the generalizable stuff first. This list includes "Costa Rican
> > Ornithology", "Crusoe", "Farewell", "Juggling", "Nickel and Dimed",
> > "Money for Nothing", "Aftershock", "Channel 2", "Four Cheeses", and
> > Bogart". Do those still seem hard to pull the system out of? Is there
> > something we could do that would improve them in that respect?
(it would be nice to have a "mini change log" accessible for the
examples in the documentation maybe..., or even a list with all the
updated examples in the documentation. I know there is a list on the
change log of inform7 but it is not easy to refer to it all the time)
* costa rican ornithology
I have 2 problems with this example.
The first : you have to think at birds names to search. The best
implementation I have seen of this approach is in Anchorhead, at the
beginning you are int he room with so much files that you have no
choice but to search by name. Browsing all of them is something the
player wouldn't want to do.
But in the case of a book, browsing the pages would certainly be
something the player would want to do. At least browsing the index,
and choosing to look a the related page.
The fact is that you have a book but you can't look at any page unless
you know its name... This behavior could be used for searching a
database on an electronic device but for a book I don't like it very
much. It may be a personal taste.
The second problem is that you have hard coded in the book the answer
to the bird you have in front of you:
"You flip through the Guide for a while and eventually discover a
reference to the scarlet macaw, which appears to correspond with what
you see before you."
This is what I was saying when I was talking about restricted context.
I know this is for the sake of the example, but at the same time this
does not give a good idea of how where it could be extended. Let's say
you want to use this example for describing a lot of birds you will
encouter, you will have to add some conditionals in the style "[if the
scarlet macaw is in the location]" etc... for each bird.
Well, I suppose you intended the example to be simple and to be a way
to show a searching method... which it does very well anyway.
* Kyoto
I don't know if it is a new example but while looking for "juggling" I
found it (and very pleased I did).
I have already coded a throw it at action for things to hit and break,
but you way to do it gave me more insights of what I could do to make
it better (especially the choice of attributes: fragile and strong,
flat, round etc... and some checks).
And I have some cascading if/otherwise that could be re-coded as a
relation like you coded...(I am not yet used ot relations so I haven't
used them ^^; ).
I have also used "part of things" to appear in the location when the
thing breaks (inspired by your example with the robot we "zap").
Nice way to code a broken door also (I had very much trouble to do
this... coding a dummy door then tricky replacements to simulate
movement from one room to another when the door is broken.)
* juggling
I think the example lacks good descriptions of what is happening, or
how we get better at juggling... Could be nice to have beans bag fall
on the floor when making a mistake for example. Or coding when we
almost made a mistake but managed to avoid it brilliantly making some
fancy stuff.
This would temper the "repetitive" problem of randomized stuff.
* Channel 2
I would have writtent the description of what we see on the TV without
having to type "x channel y". Just after have tuned to a channel we
should also have the description...
This remark is not really related to the purpose of the example but...
* bogart
The problem of bogart is that the layers are determined.
So it works well when we take the clothes off but what if we want/
happen to wear them in a different order?
It automatically layers the way it "should" be.
It may be a good approach sometimes but sometimes the player could be
frustrated not to be able to wear the clothes the way he wants.
"what not to wear" has the same problem, and another : it is so slow
I'm afraid it can't be used in a real game (>_<)
Well deciding of the order of clothes is not that a bad idea, but I
guess it would be better to decide of the order by the order the
player actually wears the clothes.
If someone is stupid enough to wear the panties after have worn the
trousers it may certainly be on purpose ^^; (for what purpose I don't
know though). Anyway for this approach to work, a completely different
coding approach is needed as well... And still may be too dynamic to
be done in inform7 (but if there is a way I'd like to know).
We should also be able to test "if the panties are worn over the
trousers", say "Very funny!" or that kind of stuff.
Emily Short
> (it would be nice to have a "mini change log" accessible for the
> examples in the documentation maybe..., or even a list with all the
> updated examples in the documentation. I know there is a list on the
> change log of inform7 but it is not easy to refer to it all the time)
The chapter "What's new in Inform" has a list of all the changes, and
links to all the examples that are new.
> * costa rican ornithology
>
> I have 2 problems with this example.
> The first : you have to think at birds names to search...
> But in the case of a book, browsing the pages would certainly be
> something the player would want to do. At least browsing the index,
> and choosing to look a the related page.
Sure. Here (as with some of the other things you point out), the
example shows one possible way of approaching the thing implemented,
but that approach is not going to be ideal for every game. By
contrast, if you want a book that the reader can browse through, see
"Pages".
> * juggling
>
> I think the example lacks good descriptions of what is happening, or
> how we get better at juggling... Could be nice to have beans bag fall
> on the floor when making a mistake for example. Or coding when we
> almost made a mistake but managed to avoid it brilliantly making some
> fancy stuff.
Heh. I avoided most of that sort of thing as extraneous, since I meant
the example to be about the money and pricing issue, rather than about
a juggling simulation.
> "what not to wear" has the same problem, and another : it is so slow
> I'm afraid it can't be used in a real game (>_<)
Hm. Okay, I'll look at whether there are ways to optimize the
performance, if this is something that a number of people are
interested in using.
> If someone is stupid enough to wear the panties after have worn the
> trousers it may certainly be on purpose ^^; (for what purpose I don't
> know though). Anyway for this approach to work, a completely different
> coding approach is needed as well... And still may be too dynamic to
> be done in inform7 (but if there is a way I'd like to know).
It's not hard at all -- in fact, it's less hard than what the example
does. You would just remove all the checks that require clothes to be
worn in a certain layering order.
isd
> On Nov 18, 11:17 pm, isd <ionsupplydr...@gmail.com> wrote:
>
> > (it would be nice to have a "mini change log" accessible for the
> > examples in the documentation maybe..., or even a list with all the
> > updated examples in the documentation. I know there is a list on the
> > change log of inform7 but it is not easy to refer to it all the time)
>
> The chapter "What's new in Inform" has a list of all the changes, and
> links to all the examples that are new.
Ouch! I had spotted it just after the installation then completely
forgot about it ^^;
> > * costa rican ornithology
>
> > I have 2 problems with this example.
> > The first : you have to think at birds names to search...
> > But in the case of a book, browsing the pages would certainly be
> > something the player would want to do. At least browsing the index,
> > and choosing to look a the related page.
>
> Sure. Here (as with some of the other things you point out), the
> example shows one possible way of approaching the thing implemented,
> but that approach is not going to be ideal for every game. By
> contrast, if you want a book that the reader can browse through, see
> "Pages".
ooh, thank you.
> > "what not to wear" has the same problem, and another : it is so slow
> > I'm afraid it can't be used in a real game (>_<)
>
> Hm. Okay, I'll look at whether there are ways to optimize the
> performance, if this is something that a number of people are
> interested in using.
If this is a problem with inform itself (the loops are slow) it may be
difficult... had better ask Graham Nelson ;)
It seems looping through objects is slow but if looping through
tables(or something else which can be used) is not, it may be a
solution.... ^^;
> > If someone is stupid enough to wear the panties after have worn the
> > trousers it may certainly be on purpose ^^; (for what purpose I don't
> > know though). Anyway for this approach to work, a completely different
> > coding approach is needed as well... And still may be too dynamic to
> > be done in inform7 (but if there is a way I'd like to know).
>
> It's not hard at all -- in fact, it's less hard than what the example
> does. You would just remove all the checks that require clothes to be
> worn in a certain layering order.
Ohh, and it would still work when trying to look "under" clothes? (I
think this is the point where it becomes hard to code.. maybe)
isd
> > > If someone is stupid enough to wear the panties after have worn the
> > > trousers it may certainly be on purpose ^^; (for what purpose I don't
> > > know though). Anyway for this approach to work, a completely different
> > > coding approach is needed as well... And still may be too dynamic to
> > > be done in inform7 (but if there is a way I'd like to know).
>
> > It's not hard at all -- in fact, it's less hard than what the example
> > does. You would just remove all the checks that require clothes to be
> > worn in a certain layering order.
>
> Ohh, and it would still work when trying to look "under" clothes? (I
> think this is the point where it becomes hard to code.. maybe)
I forgot to add: I already have done that in the past, and the problem
is that you need the order for when you take clothes off (since you
can't take off something which is overlaid before/or at the same time
than taking off the thing that overlies... in most cases.)
JDC
wrote:
> I would only suggest, if possible, to include in every new releases of
> Inform 7, all the extensions found on the website. It may be easier for
> authors to pick one when they need to. It's not particularly heavy in size,
> so it wouldn't increase much the size of the package. They could be
> classified as "external extensions" for example.
If this were done, I think it would be a good idea to not install them
automatically, in case author's are relying on the version they have
installed currently.
> I'm also thinking about the status of translated extensions, or modified
> extensions. Should they bear the name of the translator / the one who
> modified the extension ? If so, is there a way to track the name of the
> original author, to respect the Creative Common attribution licence.
This could be useful; I've wanted to tweak a couple of things in
extensions from time to time, and not been sure what to do about
attribution.
-JDC
JDC
> 2) Are there extensions you have yourself tried/wanted to write that
> you couldn't bring about, for some technical reason? What could we do
> that would help you? Are there deeper internals of Inform which you
> would need access to?
Here are a couple of things I can think of (these are really
suggestions about the language, but ones which would be most
applicable to extension writers). Some of these may be of pretty
limited use:
* Constants
It would be useful to have some nice way of setting a default value in
an extension which could be overridden by the game author. For many
things you can do this with a variable, but I'm thinking of situations
where you need to hard-code a number at compile-time (like the number
of rows in a table, or the number of instances of a class you want to
create).
Something like:
The string-count is a number constant with default value 10.
A string is a kind of thing. String-count many strings are in the
string repository.
* A way to replace routines
First, I mean the ability to replace certain phrases defined in an
extension; this currently works for named rules, but there are some
things which I don't think can be overridden (To... phrases,
definitions, the kinds to which a relation applies?).
Second, the ability to replace included I6 routines. Routines from the
libraries can be replaced in the usual way (with the Replace
directive), but not ones which are included in the auto.inf file by
the I7 compiler (since I6 doesn't let you replace a routine from the
same file).
* As many entry-points as possible :), or a way to dynamically insert
them
I'm thinking of something like Jon Ingold's extension for multiple
examining, which requires modifying the library (I'd actually really
like to see that entrypoint added to the standard library, so that
extension writers could more easily take a crack at improving the
handling of commands applied to multiple objects).
* Better parsing of player input to find objects
Ok, this is really a language feature request, but I'm going to slip
it in here since it's relevant to conversation systems. It would be
nice to be able to use tokens like thing, person, etc. more flexibly
than is currently possible. I love the new regular expression
features; I'm thinking of allowing these sorts of tokens in
expressions.
Something like:
If the topic understood matches "if [person] knows about
[conversation topic]" ...
(where conversation topic was a kind of thing), which could be used to
parse "Ask the butler if Lord someone-or-other knows about the
upcoming wedding".
-JDC
Ron Newcomb
> > I'm also thinking about the status of translated extensions, or modified
> > extensions. Should they bear the name of the translator / the one who
> extensions from time to time,
Code being code, a pre-made thing almost always has to be tweaked, so
I never add my name to an extension unless I made -extensive- changes/
additions.
Hopefully the upcoming guidelines for extensions, once followed, will
make tweaking less necessary.
-Ron
PS: I would still like some guidelines on attribution though!
Ron Newcomb
> * Constants
> It would be useful to have some nice way of setting a default value in
> an extension which could be overridden by the game author. For many
Seconded.
Also, I add this request from my other thread, "I7: bug? saying 'the
actor' causes compiler error". In the following text-that-varies,
[noun] and [second noun] work, but not [actor]. I request [actor]
work, for the purposes of replaceable prose in those Check rules using
a say...instead.
Slippery pig error is "[The noun] is so slippery, [the actor] fails to
take it."
Check an actor taking the pig: if <complex conditions>, say slippery
pig error instead.
Rioshin an'Harthen
news:8cb79589-2245-4ad1...@y5g2000hsf.googlegroups.com...
> On Nov 16, 5:46 pm, Emily Short <emsh...@mindspring.com> wrote:
>
>> 2) Are there extensions you have yourself tried/wanted to write that
>> you couldn't bring about, for some technical reason? What could we do
>> that would help you? Are there deeper internals of Inform which you
>> would need access to?
>
> Here are a couple of things I can think of (these are really
> suggestions about the language, but ones which would be most
> applicable to extension writers). Some of these may be of pretty
> limited use:
>
> * Constants
> It would be useful to have some nice way of setting a default value in
> an extension which could be overridden by the game author. For many
> things you can do this with a variable, but I'm thinking of situations
> where you need to hard-code a number at compile-time (like the number
> of rows in a table, or the number of instances of a class you want to
> create).
> Something like:
> The string-count is a number constant with default value 10.
> A string is a kind of thing. String-count many strings are in the
> string repository.
I'm going to comment only on this, for now, since I stumbled across this
when checking that Weather Effects works.
In previous versions of I7, it was possible for the extension to declare a
variable (in fact, this time it's inherited from Ish's Weather), like
Day is a number variable. Day is 1.
and for the game to override it simply with
Day is 20.
However, with the new 5G67, this is no longer possible. This led to the
example for Weather Effects to replace the simple
The Month is 7. The Day is 20. The Time of Day is 8:25 PM.
with the, in my opinion too complex to figure out easily
When play begins:
Now the Month is 7;
Now the Day is 20;
Now the Time of Day is 8:25 PM;
Consider the scene changing rules.
However, one good thing came out of this: I stumbled upon a small bug in
Atmospheric Effects which I hadn't noticed before, and led me to separate
the displaying of messages from their generation.
Emily Short
> * Better parsing of player input to find objects
> Ok, this is really a language feature request, but I'm going to slip
> it in here since it's relevant to conversation systems. It would be
> nice to be able to use tokens like thing, person, etc. more flexibly
> than is currently possible. I love the new regular expression
> features; I'm thinking of allowing these sorts of tokens in
> expressions.
> Something like:
> If the topic understood matches "if [person] knows about
> [conversation topic]" ...
> (where conversation topic was a kind of thing), which could be used to
> parse "Ask the butler if Lord someone-or-other knows about the
> upcoming wedding".
I'm not unsympathetic to this, but I've been thinking about the
problem and wondering whether your hypothetical approach is really the
best solution. I think what I would do is run a series of regular
expressions on the input to determine what kind of question the player
was asking, and then translate the command with substitutions into
some kind of Informese pidgin (>BUTLER, DOES LORD FOOBAR KNOW WEDDING
PLANS ? or something equally appalling -- but the player wouldn't have
to see that, of course).
The advantages of that, as I see it, are two-fold: first, we can use
the usual parser and scope rules and so on to handle parsing the
tokens in the command, which has to be a net win: it avoids our having
to express in two different places in the code which people,
conversation topics, etc., are considered to be in scope.
Second, it means that even if Inform cannot resolve the question into
something it fully understands -- maybe it doesn't recognize "wedding
plans" as a conversation subject, or whatever -- it will still be able
to guess generally what *kind* of question the player was trying to
ask; which means that the NPC's responses can be more intelligently
tailored to reflect at least a partial comprehension.
JDC
> I'm not unsympathetic to this, but I've been thinking about the
> problem and wondering whether your hypothetical approach is really the
> best solution. I think what I would do is run a series of regular
> expressions on the input to determine what kind of question the player
> was asking, and then translate the command with substitutions into
> some kind of Informese pidgin (>BUTLER, DOES LORD FOOBAR KNOW WEDDING
> PLANS ? or something equally appalling -- but the player wouldn't have
> to see that, of course).
I am coming to the conclusion this method is probably the best.
> Second, it means that even if Inform cannot resolve the question into
> something it fully understands -- maybe it doesn't recognize "wedding
> plans" as a conversation subject, or whatever -- it will still be able
> to guess generally what *kind* of question the player was trying to
> ask; which means that the NPC's responses can be more intelligently
> tailored to reflect at least a partial comprehension.
And this is the main reason. You can use something like ParseToken()
to pick at a conversation topic, but it gets ugly if you hit a
disambiguation message or an unrecognized command (also scoping
issues, as you noted). So it does seem best to let the parser do the
heavy lifting whenever possible.
-JDC