inform 7 default answers...

8 views
Skip to first unread message

terumi

unread,
Jul 26, 2007, 7:47:56 AM7/26/07
to
Hi all!

Is there a way to change the default way that a game written in inform
responds (you can't go west, you cannot open it, it is hardly portable
etc)...

I've been making a game using third person narration, but inform
responds in second person narration.
How can I make inform respond in a "your hero cannot see a thing"
etc...


Thank you,

Zylon

unread,
Jul 26, 2007, 7:50:30 AM7/26/07
to
You can use the Custom Library Messages extension.

http://www.inform-fiction.org/I7Downloads/Extensions/David%20Fisher/Custom%20Library%20Messages

Just set it up for third person and it'll work fine. Directions are included
with the extension. You can also selectively modify some messages the
library throws at you. Personal rant: To me this kind of thing should be
inherent in the library, not an extension. TADS 3 and Hugo allow this
automatically. I don't think Inform ever has.


terumi

unread,
Jul 26, 2007, 7:53:08 AM7/26/07
to
On 26 , 14:50, "Zylon" <zylo...@hotmail.com> wrote:
> You can use the Custom Library Messages extension.
>
> http://www.inform-fiction.org/I7Downloads/Extensions/David%20Fisher/C...

>
> Just set it up for third person and it'll work fine. Directions are included
> with the extension. You can also selectively modify some messages the
> library throws at you. Personal rant: To me this kind of thing should be
> inherent in the library, not an extension. TADS 3 and Hugo allow this
> automatically. I don't think Inform ever has.


Cheers!!!!

Andrew Plotkin

unread,
Jul 26, 2007, 10:21:54 AM7/26/07
to
Here, Zylon <zyl...@hotmail.com> wrote:
> You can use the Custom Library Messages extension.
>
> http://www.inform-fiction.org/I7Downloads/Extensions/David%20Fisher/Custom%20Library%20Messages
>
> Just set it up for third person and it'll work fine. Directions are included
> with the extension. You can also selectively modify some messages the
> library throws at you. Personal rant: To me this kind of thing should be
> inherent in the library, not an extension.

To me, everything which can possibly be an extension should be an
extension. Darkness should be an extension. Doors should be an
extension.

"Extension" isn't a mark of a second-class feature. It's the mark of a
language which is flexible enough to allow first-class features to be
developed independently.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
If the Bush administration hasn't shipped you to Syria for interrogation, it's
for one reason: they don't feel like it. Not because of the Eighth Amendment.

Zylon

unread,
Jul 26, 2007, 11:27:03 AM7/26/07
to
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:f8aam1$nsh$1...@reader2.panix.com...

> To me, everything which can possibly be an extension should be an
> extension. Darkness should be an extension. Doors should be an
> extension.

That's definitely a way to look at it. Personally, I disagree. Having a
minimalist core system is a way to go in some things where the supposed
power comes in from the extensibility. You could argue that Eclipse took
this route. But even then, Java support was really always part of the thing
anyway so even the "classic" was not all that minimalist as some people like
to believe. But for that kind of system, maybe that more minimialist
approach makes sense. For IF systems, I'm not convinced. There's a
difference here in that we're talking about library extensions and not
extensions to the compiler or to the core language itself.

> "Extension" isn't a mark of a second-class feature. It's the mark of a
> language which is flexible enough to allow first-class features to be
> developed independently.

This is the old debate about what actually belongs in a system and what
other people are expected to go get on their own. I know it's not easy to
discern the line and even if you do, it's only your own line since everyone
else is likely to disagree to some extent. I can see both sides of it. I
just think things like the ability to customize the standard messages of the
library should be a standard feature of that same library. If someone wanted
to somehow add on even to that customizability, then perhaps you have an
extension.


namekuseijin

unread,
Jul 26, 2007, 8:44:29 PM7/26/07
to
On 26 jul, 12:27, "Zylon" <zylo...@hotmail.com> wrote:
> There's a
> difference here in that we're talking about library extensions and not
> extensions to the compiler or to the core language itself.

Correct me if I'm wrong, but aren't I7's "extensions" just modules of
code? A library of sorts?

> just think things like the ability to customize the standard messages of the
> library should be a standard feature of that same library. If someone wanted
> to somehow add on even to that customizability, then perhaps you have an
> extension.

I think you're viewing "extensions" as some foreign, malign plugin-
like kind of thing, when in fact they're just modules of code, written
in the same language as that of Inform's "standard library". It makes
sense to me, as it leaves much code in the hands of the IF community
and frees GN to work just on the core system without much pressure.

Besides, in this day and age the old C-stdlib model can't compete with
an online huge repositoire of free code a la Perl's CPAN. It's not
terribly difficult to simply download the file and drop in the source
directory.

Eric Forgeot

unread,
Jul 30, 2007, 7:49:22 AM7/30/07
to
Andrew Plotkin wrote:

> To me, everything which can possibly be an extension should be an
> extension. Darkness should be an extension. Doors should be an
> extension.
>
> "Extension" isn't a mark of a second-class feature. It's the mark of a
> language which is flexible enough to allow first-class features to be
> developed independently.
>
> --Z

And how about for other languages ?

It's not really easy to adapt other languages to Inform 7 (needs to hack the
main.i6 lib etc), while with the Inform 6 it was provided by 2 libraries...


Zylon

unread,
Jul 30, 2007, 8:10:30 AM7/30/07
to

"Eric Forgeot" <use_form_...@anamnese.fr.st> wrote in message
news:46add029$0$32118$426a...@news.free.fr...

> It's not really easy to adapt other languages to Inform 7 (needs to hack
> the
> main.i6 lib etc), while with the Inform 6 it was provided by 2
> libraries...

For me, it's not even that. By the logic of everything is an extension, then
consider this: Inform assumes that a supporter (any supporter) is fixed in
place. So then the notion of a supporter should be an extension, by this
logic. Technically many things can be a supporter, even if they're not meant
for being such. So that should be an extension as well. Scenery is another
aspect. It's assumed to be immoble but anything can be considered "scenery";
it's a vague term. It should be an extension. So should the notion of "room"
and "thing."

It is an interesting idea regarding how much and how little is considered an
extension to a language and how much is intrinsic. But in this case we're
talking about the library aspects, which makes the debate even murkier for
some. There's a certain logic to the "everything is an extension" in that
you (theoretically) can make the most flexible system possible. In reality,
though, this rarely works because it becomes a usability issue for people as
well as more of a maintenance issue across the board for everyone who writes
the extensions. What is and what isn't an "extension" to a system (whether
language or library) is usually predicated on the nature of the users of
that system. So Java "extensions" will be different in nature from
"extensions" for something like I7 or the Torque 3D game engine.

Where I was originally going with this is that it's clear to me that certain
extensions (like Locksmith) became "part of" the official distribution of
I7, so I7 kind of muddies the waters there anyway. I think something like
customizing the library messages should be accorded similar status. I'm
hoping there's some criterion that's actually applied in determining what
"extensions" are "built in" to I7.


Andrew Plotkin

unread,
Jul 30, 2007, 9:03:32 AM7/30/07
to
Here, Eric Forgeot <use_form_...@anamnese.fr.st> wrote:
> Andrew Plotkin wrote:
>
> > To me, everything which can possibly be an extension should be an
> > extension. Darkness should be an extension. Doors should be an
> > extension.
> >
> > "Extension" isn't a mark of a second-class feature. It's the mark of a
> > language which is flexible enough to allow first-class features to be
> > developed independently.
>
> And how about for other languages ?

I don't know; how about them?



> It's not really easy to adapt other languages to Inform 7 (needs to hack the
> main.i6 lib etc), while with the Inform 6 it was provided by 2 libraries...

main.i6 *is* an Inform 6 library. I'm not sure what you're arguing here.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

Bush's biggest lie is his claim that it's okay to disagree with him. As soon as
you *actually* disagree with him, he sadly explains that you're undermining
America, that you're giving comfort to the enemy. That you need to be silent.

Andrew Plotkin

unread,
Jul 30, 2007, 9:12:15 AM7/30/07
to
Here, Zylon <zyl...@hotmail.com> wrote:
>
> For me, it's not even that. By the logic of everything is an extension, then
> consider this: Inform assumes that a supporter (any supporter) is fixed in
> place. So then the notion of a supporter should be an extension, by this
> logic.

Sure.

> Technically many things can be a supporter, even if they're not meant
> for being such. So that should be an extension as well. Scenery is another
> aspect. It's assumed to be immoble but anything can be considered "scenery";
> it's a vague term. It should be an extension. So should the notion of "room"
> and "thing."

Room, certainly. "Thing" is debatable; in the current I7 model, a
thing is a default kind, defined more by not being a room than by any
positive qualities. But in the hypothetical system I'm talking about,
that might not be true.

> What is and what isn't an "extension" to a system (whether
> language or library) is usually predicated on the nature of the users of
> that system. So Java "extensions" will be different in nature from
> "extensions" for something like I7 or the Torque 3D game engine.

Agreed. And I'm *not* saying that I7 *is* flexible enough to make
everything (room, door, darkness) an extension. I don't think it is.
I've made some posts in the past about what might move it in that
direction, but I haven't demonstrated that I'm right.



> Where I was originally going with this is that it's clear to me that
> certain extensions (like Locksmith) became "part of" the official
> distribution of I7, so I7 kind of muddies the waters there anyway. I
> think something like customizing the library messages should be
> accorded similar status.

Ah, "official distribution" is a separate issue.

I entirely agree that library-message customization should be
available to game authors off the bat. On the other hand, there's more
than one way to customize library messages in the current I7
structure, and I might want to use one model or a different one --
those would be different extensions, and it gets silly to provide
both. On the third hand, I think the fact that there's more than one
good way to do it is due to some historic I6 awkwardness inside I7,
and not any true generality of the system.

On the fourth hand, maybe the problem of "official distribution"
should be attacked from the other end. Have the IDE be smart about
listing and downloading the available extensions, so that it *doesn't
matter* which extensions are bundled -- they're *all* visible and
usable right off the bat, regardless.

--Z

--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*

Zylon

unread,
Jul 30, 2007, 3:11:11 PM7/30/07
to
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:f8ko3f$40t$2...@reader2.panix.com...

> On the fourth hand, maybe the problem of "official distribution"
> should be attacked from the other end. Have the IDE be smart about
> listing and downloading the available extensions, so that it *doesn't
> matter* which extensions are bundled -- they're *all* visible and
> usable right off the bat, regardless.

I could see this being workable. Right now I have to parse through the
extensions page just to see what's even available, not sure if it will be
anything I actually want. Then I have to download that. Then use the
"installer" as part of the IDE. It's not the worst process in the world, but
if the system is going to be based on a lot of extensions filling out the
core, then it probably would be good to have a slightly better process. The
other thing is that I imagine I have to keep checking back if there's been
an update. I'm not sure if extensions (either new or modified) are announced
in any way but even then, I might miss the announcement.


Eric Forgeot

unread,
Jul 30, 2007, 5:09:53 PM7/30/07
to
Andrew Plotkin wrote:

>>
>> And how about for other languages ?
>
> I don't know; how about them?

It's not me who should give advice here. We (for example French and Spanish
people using I7) are waiting for official support for foreign languages
into Inform 7.

>
>> It's not really easy to adapt other languages to Inform 7 (needs to hack
>> the main.i6 lib etc), while with the Inform 6 it was provided by 2
>> libraries...
>
> main.i6 *is* an Inform 6 library. I'm not sure what you're arguing here.
>

If I want to add support for foreign language in Inform 7 I must edit the
official library to include my "hack". If I want to suggest people to
create games with Inform 7 I must tell them : open the main.i6, and around
line 80, replace this pattern

{-open-file}{-call:compile_icl_commands}

by

{-open-file}!% +language_name=FrenchN11
{-call:compile_icl_commands}

and around line 390 add :

#IFDEF ForeignLanguage;
#IFNOT;
Include "Grammar";
#ENDIF;


Very elegant isn't it ?


Reply all
Reply to author
Forward
0 new messages