[Inform] Simulationist conversation/knowledge representation

4 views
Skip to first unread message

Thomas Hudson

unread,
Mar 9, 2002, 11:32:15 AM3/9/02
to

Coming to IF more a programmer than a writer, it's very easy for me to
slip into simulationist thinking. Also lacking the wisdom of our literary
brethren, the setting I'm playing with for my "first IF" has about 50
NPCs in it, all of whom the PC knows well.

That's ridiculous. As I flesh out the story I ought to be able to
cut the number down, or hide a lot of them - Mr. X is away, Ms. Y is
busy, it would be indelicate to interrupt U and V right now, ... Meanwhile,
I'm trying to think of programming methods that would let me handle
many NPCs running around and able to have rudimentary conversations.
Rather than writing 50 NPCs from scratch, I'm trying to give NPCs
access to a lot of generic information, then add their personal
knowledge on top of that.

Best Of 3 is one of the recent works that really blew me away. I'd
like to go to topic + menu conversations eventually, but for now I'm
just aiming at ask/tell/order (extending Info.h).

ORlib looks interesting, but way too undercommented for me to be
willing to adopt right now. Reading through it this morning, though,
some of what's being done with KnowledgeTopic is similar to what I'm
trying to do; something finer-grained and more flexible than
CommonKnowledge and with a model that explicitly differentiates
between topics of conversation and replies.

So, my current design for a knowledge-representation +
(static) conversation system in Inform:

There are a set of topics, class cTopic - "the plague",
"the east gate".

There is a class cKnowledge. Every NPC has one.
Every instance of cKnowledge contains a bunch of instances of
class cReply. Each of those instances points to a topic and
has a string that gets printed or a routine that gets run.
With routines, I can check flags so that people can comment
fearfully about the plague before it strikes and despairingly
afterwards, etc. Each instance of cKnowledge also has a list of
other instances that are "fallback" information.

Fallback information is the only way I'd ever be able to write
many NPCs. Servants who don't have a personal replay to a given
topic can fall back to their generic servantly knowledge. If
there's nothing there, they can fall back to generic person-who-
lives-here, or gender, or culture. Setting up all the contextual
knowledge objects is a little tricky, but it's more flexible than
an inheritance hierarchy, which was my first prototype.

To answer a question, the parser figures out the topic. The
NPC walks through her knowledge looking for any replies about
that topic. If that fails, the NPC checks out her fallback
knowledges, walking through the replies in each of those
objects in order.


The code seems to work. My questions for the group:

1) I haven't found anybody else using huge numbers of NPCs in their
games. Are there games I've missed that do this?

(I've not played even 2 dozen of the modern games yet, but right now
I'm working in the tradition of "When the Ph.D. is at an impasse."
I have at least looked through Emily Short's
list http://emshort.home.mindspring.com/literacy.htm
and Roger Firth's tutorial
http://www.firthworks.com/roger/infact/convers2.html)

2) Magnus Olsson has MOOCE in alpha without released code. Emily Short
has some great code somewhere but I don't see the source hanging around
for download (reasonably enough). There's ORLib, there's Info.h
(immediate precursor of my code), PhTalkOO.h, Converse.h, and their
peers at the archive. Are there other knowledge-representation
or conversation packages I've missed?

I'd like to grow my system towards some of the features that Emily
Short talks about using in Bo3; there is at least one NPC who I
have a strong sense of and want to have complicated conversations
with throughout the game. I expect that a lot of the puzzles in the
game will be conversational rather than object manipulation.
(Is this a *stupid* thing to do given the state of IF parsers?)

3) Are there known best practices of software engineering in Inform?
I'm still figuring out a lot of the implications of details of how
inheritance works with things like property composition - there are
some neat tricks there.

4) How else do you cope with highly-populated settings? Pytho's Mask
seemed to be able to get away with "you don't have an introduction"
pretty well.


P.S. This may be a newbie Inform question. Looking at sample code
for Converse.h:

Topic -> t0 "Greet the usher"
with playerpart "Hello.",
convpart [;
usher.remconv(t0); usher.remconv(t1); usher.remconv(t2);
usher.putconv(t3); usher.putconv(t5); usher.putconv(t7);
"~Good evening.~"; ];

Is there some reason not to rewrite the library to support doing all
the addition and removal of topics automatically, since that's most
of the library's function? convpart could still be a routine to allow
checking flags and actions in reaction to the conversation. Some of
this is the implementor's personal taste, I suppose. My proposed
syntactic sugar would look something like:

Topic -> t0 "Greet the usher"
with playerpart "Hello.",
convput t3 t5 t7, ! the cloak, the opera, the crowd
convrem t0 t1 t2, ! done with introduction
convpart ~Good evening.~";


Tom Hudson
// hud...@cs.unc.edu, hud...@uncwil.edu

OKB -- not okblacke

unread,
Mar 9, 2002, 1:00:41 PM3/9/02
to
hud...@cs.unc.edu (Thomas Hudson) wrote:
> Coming to IF more a programmer than a writer, it's very easy for me to
>slip into simulationist thinking. Also lacking the wisdom of our literary
>brethren, the setting I'm playing with for my "first IF" has about 50
>NPCs in it, all of whom the PC knows well.

My jaw dropped when I read this. I don't mean to be discouraging, but I
don't think there's any way that's going to happen. But you seem to have
reached the same conclusion. . .

> That's ridiculous. As I flesh out the story I ought to be able to
>cut the number down, or hide a lot of them - Mr. X is away, Ms. Y is
>busy, it would be indelicate to interrupt U and V right now, ... Meanwhile,
>I'm trying to think of programming methods that would let me handle
>many NPCs running around and able to have rudimentary conversations.
>Rather than writing 50 NPCs fr

Whew :-).

<snipped description of knowledge representation>

That looks like a basically good framework. I haven't worked specifically
with knowledge-modelling, but in my experience a big problem with coding NPCs
is the workaday tedium of creating tons of objects and defining relationships
between them. Syntactic sugar and shortcut behavior of the type you suggest
for Converse.h is a real time-saver and helps prevent burnout.

>1) I haven't found anybody else using huge numbers of NPCs in their
>games. Are there games I've missed that do this?

I haven't played any game that uses anywhere near 50 NPCs. (I'm talking
about real, meaningful NPCs that you can interact with in ways significant to
the game; I'm not talking about shopkeepers and orcs.) My own game "Stick it
to the man" had about 10 major NPCs. Most IF games I've seen have no more than
2 or 3 such NPCs.

>2) Magnus Olsson has MOOCE in alpha without released code. Emily Short
>has some great code somewhere but I don't see the source hanging around
>for download (reasonably enough). There's ORLib, there's Info.h
>(immediate precursor of my code), PhTalkOO.h, Converse.h, and their
>peers at the archive. Are there other knowledge-representation
>or conversation packages I've missed?

I'll go ahead and plug my own library, GxScript. It's not
knowledge-representation, though; it handles menu-based conversations. There's
no TOPIC command, but considering the amount of thought you've put into the
conversation-topic concept you probably wouldn't have much trouble adding one.
GxScript is for Glulx Inform; there's an older version for Zcode called
OKBScript, but I haven't really been keeping it up so it's a bit stale. You
can get these from the archive but more recent versions are at my site at

http://members.aol.com/brenbarn/IF-download.html

>I expect that a lot of the puzzles in the
>game will be conversational rather than object manipulation.
>(Is this a *stupid* thing to do given the state of IF parsers?)

No. I much prefer good NPC interaction to piddling around with objects.

>3) Are there known best practices of software engineering in Inform?
>I'm still figuring out a lot of the implications of details of how
>inheritance works with things like property composition - there are
>some neat tricks there.

Well, there are certainly good habits to get into, but I can't really
think of any words of wisdom. The DM4 is a good resource if you read it right
through; there are a lot of useful tidbits buried in obscure corners.

--OKB (Bren...@aol.com) -- no relation to okblacke

"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
--Author Unknown

Jim Fisher

unread,
Mar 10, 2002, 1:05:56 PM3/10/02
to

> ORlib looks interesting, but way too undercommented for me to be
> willing to adopt right now.

Yes... I'm trying to address some of the lack of documentation. Out of
curosity, what specific areas to you feel need to be improved upon in the
documentation? Or are you actually refering to the comments in the modules
themselves?

Every bit of input would be appreciated.

--
Jim (AT) OnyxRing (DOT) com
Visit "An Inform Developer's Guide" or browse the
"ORLibrary" extensions to the standard library at
www.OnyxRing.com
----------------------
Some days you eat the code; some days the code eats you

L. Ross Raszewski

unread,
Mar 10, 2002, 2:34:45 PM3/10/02
to
On 9 Mar 2002 11:32:15 -0500, Thomas Hudson <hud...@cs.unc.edu> wrote:
>>
>
>P.S. This may be a newbie Inform question. Looking at sample code
>for Converse.h:
>
>Topic -> t0 "Greet the usher"
> with playerpart "Hello.",
> convpart [;
> usher.remconv(t0); usher.remconv(t1); usher.remconv(t2);
> usher.putconv(t3); usher.putconv(t5); usher.putconv(t7);
> "~Good evening.~"; ];
>
>Is there some reason not to rewrite the library to support doing all
>the addition and removal of topics automatically, since that's most
>of the library's function? convpart could still be a routine to allow
>checking flags and actions in reaction to the conversation. Some of
>this is the implementor's personal taste, I suppose. My proposed
>syntactic sugar would look something like:
>

"Most of the library's function" is a complex subject; converse wasn't
really designed do to forward-only tree-based conversation (though it
can); it was designed to do hierarchical shrubbery-based conversation,
where you don't necessarily swap a lot of new topics in for each line
of conversation, and you rarely swap any topics out

>Topic -> t0 "Greet the usher"
> with playerpart "Hello.",
> convput t3 t5 t7, ! the cloak, the opera, the crowd
> convrem t0 t1 t2, ! done with introduction
> convpart ~Good evening.~";
>

This is reasonable, and wouldn't be hard to implement. However, I
tend to find that if you're doing this sort of thing a lot, you might
be better off actually switching between top-level conversation
menus. That is, you'd have a menu containing topics 0 1 and 2, and
another containing 3,5, and 7, and topic 0 would switch to the other menu.

Of course, the syntax you propose wouldn't allow the user to, say,
have the adding and removing of topics be conditional on some other
test.

Thomas Hudson

unread,
Mar 10, 2002, 3:59:53 PM3/10/02
to
In article <a6gcgl$vrf$1...@foobar.cs.jhu.edu>,

L. Ross Raszewski <lrasz...@loyola.edu> wrote:
>On 9 Mar 2002 11:32:15 -0500, Thomas Hudson <hud...@cs.unc.edu> wrote:
>>>
>>
>>P.S. This may be a newbie Inform question. Looking at sample code
>>for Converse.h:
>>
>>Topic -> t0 "Greet the usher"
>> with playerpart "Hello.",
>> convpart [;
>> usher.remconv(t0); usher.remconv(t1); usher.remconv(t2);
>> usher.putconv(t3); usher.putconv(t5); usher.putconv(t7);
>> "~Good evening.~"; ];
>>
>>Is there some reason not to rewrite the library to support doing all
>>the addition and removal of topics automatically, since that's most
>>of the library's function? convpart could still be a routine to allow
>>checking flags and actions in reaction to the conversation. Some of
>>this is the implementor's personal taste, I suppose. My proposed
>>syntactic sugar would look something like:
>
>"Most of the library's function" is a complex subject; converse wasn't
>really designed do to forward-only tree-based conversation (though it
>can); it was designed to do hierarchical shrubbery-based conversation,
>where you don't necessarily swap a lot of new topics in for each line
>of conversation, and you rarely swap any topics out

Sorry, I was just judging by the example code on Roger Firth's InfAct page;
I've hunted around a little bit for examples of converse.h used in larger
contexts, but don't know an easy way to find them (both the archive and google
are failing me at the moment).

>>Topic -> t0 "Greet the usher"
>> with playerpart "Hello.",
>> convput t3 t5 t7, ! the cloak, the opera, the crowd
>> convrem t0 t1 t2, ! done with introduction
>> convpart ~Good evening.~";
>>This is reasonable, and wouldn't be hard to implement. However, I
>tend to find that if you're doing this sort of thing a lot, you might
>be better off actually switching between top-level conversation
>menus. That is, you'd have a menu containing topics 0 1 and 2, and
>another containing 3,5, and 7, and topic 0 would switch to the other menu.
>
>Of course, the syntax you propose wouldn't allow the user to, say,
>have the adding and removing of topics be conditional on some other
>test.

I wasn't trying to advocate removing the ability to have routines, just
speculating that the shortcut might be useful. (Reading through the last six
months of the newsgroup, there certainly seem to be plenty of friends-of-Inform
who swear by shortcuts like dropping print and print_ret for the bare string
notation.)

And this was an honest question. I'm still discovering interesting things
about how messages propagate up class hierarchies that seem counterintuitive
but perfectly useful and reasonable. What's the right tradeoff in writing a
library between just giving generic support in routines and giving lots of
shortcuts? Too many are as bad (in a different way) as too few. It's only in
the last year or so that I've even thought about writing code that's going to
be read by somebody who isn't a graduate student in computer science.

Ross, the longer I play with a large WIP the closer my conversation code gets
to yours. I wasn't trying to criticize. Just like somebody else who posted
here recently, I'm likely to end up being a better programmer than writer; if
I contribute anything to IF it'd more likely be a strong library than a classic
game.

Tom, who just checked and verified that the deadline for IntroComp is soon
enough that I can worry about *next* year's.

ems...@mindspring.com

unread,
Mar 11, 2002, 4:19:38 PM3/11/02
to
I originally answered this post by private email.

Then I thought: this is ridiculous. I miss raif. I'm sorry if I've
irritated certain people or given an impression of egotism and
condescension; such has never been my intention, and if it happens
again, people should feel free to email me privately. But
conversation with the rest of the community is critical to me.

hud...@cs.unc.edu (Thomas Hudson) wrote in message news:<a6ddef$jen$1...@capefear.cs.unc.edu>...

> 2) Magnus Olsson has MOOCE in alpha without released code. Emily Short
> has some great code somewhere but I don't see the source hanging around
> for download (reasonably enough).

This isn't because I want to keep it out of people's hands, but
because a) it is complicated enough at this point to need a vast
tutorial which I don't have time to write and because b) it is
obviously not really ready yet anyway, given that every project I do
shows me new places where it needs to be Improved.

> 4) How else do you cope with highly-populated settings?

This question spurred me to add a section to my NPC page, to be found
here:

http://emshort.home.mindspring.com/NPC3.htm#crowds

which should, as always, be read as though bracketed in large
<IMHO></IMHO> tags.

ES

Axel Tölke

unread,
Mar 12, 2002, 6:43:35 PM3/12/02
to
"OKB -- not okblacke" <bren...@aol.comRemove> wrote in message
news:20020309130041...@mb-fi.aol.com...

> hud...@cs.unc.edu (Thomas Hudson) wrote:
>
> I'll go ahead and plug my own library, GxScript. It's not
> knowledge-representation, though; it handles menu-based conversations.
There's
> no TOPIC command, but considering the amount of thought you've put into
the
> conversation-topic concept you probably wouldn't have much trouble adding
one.
> GxScript is for Glulx Inform; there's an older version for Zcode called
> OKBScript, but I haven't really been keeping it up so it's a bit stale.
You
> can get these from the archive but more recent versions are at my site at

I've been working with OKB's libraries on a similar project to Thomas'.
Ok, 50 NPC sounds like a nice occasion to take the next 3 years off from
work, but once you get into the swing of things (and prepared nice
templates)
to cover the recurring conversation items, it's actually quite a bit of fun
scripting them. I'm aiming for about 10-15 NPCs that all should conform
to my (already existing) knowledge base.

Now, that being said, it's not difficult adding a knowledge and topic
framework to OKB's already pretty extensive library. The question
is how to do it most efficiently (so the author can concentrate on writing
story, rather than loads of recurring code).

I've been busy with work, so I haven't posted my code snippets, but if
anybody is interested to hurry this along, I'd be more than happy to
share with what I've come up with so far.

However, I think the original post also raised another question that's been
bugging me for quite some time, and I am wondering what your guy's
thoughts are on this:

We seem to have a lot of hefty library extensions out there (and loads of
them are adding Glulx support - yeah!). However, a lot of them take
somewhat of a proprietary approach to their workings, meaning, the
are not really compatible amongst each other.

So, for example, I would really like to use GWindows, because it allows
me to get better control over Glulx windows (I'm after color handling),
and the author has been kind enough to demonstrate how I can get all
the effects I need. I also would love to continue using GXScript, because
so far, it's the most powerful conversation engine IMHO (barring Emily's
and Magnus' unpublished works). But both replace loads of window
handling code, making them incompatible. Some of that is also true
for the ORLibrary, but with Jim's code, I've found it much easier to
'pick & choose', or adapt individual extensions without having to
adopt the entire framwork. While the code may lack commenting,
I found it very readable!

I'm just wondering about this trend of proprietary (and largely)
incompatible
extensions being released. Now, I'm constantly awed by the powerful
solutions each of these offer for their special purpose, but I'm frustrated
by their 'This'll fix anything and then some'-approach that makes the
inclusion of other extensions problematic. I guess, window handling
requires such a radical approach, but it's frustrating nontheless.

Sorry for the longish rant. Opinions?

Best,

Axel


Robin Rawson-Tetley

unread,
Mar 14, 2002, 9:00:33 AM3/14/02
to
> Then I thought: this is ridiculous. I miss raif. I'm sorry if I've
> irritated certain people or given an impression of egotism and
> condescension; such has never been my intention, and if it happens
> again, people should feel free to email me privately. But
> conversation with the rest of the community is critical to me.

Well I always thought you were jolly nice. Try not to listen to trolls
and people with no manners.

Welcome back :)

Bob

Magnus Olsson

unread,
Mar 14, 2002, 2:12:17 PM3/14/02
to
In article <a69830de.0203...@posting.google.com>,

ems...@mindspring.com <ems...@mindspring.com> wrote:
>I originally answered this post by private email.
>
>Then I thought: this is ridiculous. I miss raif.

Raif has missed you.

Welcome back!

--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------

OKB -- not okblacke

unread,
Mar 14, 2002, 2:52:39 PM3/14/02
to
"Axel Tölke" ax...@nospam.atoelke.demon.co.uk wrote:
>I also would love to continue using GXScript, because
>so far, it's the most powerful conversation engine IMHO (barring Emily's
>and Magnus' unpublished works).

Thanks :-).

>I'm just wondering about this trend of proprietary (and largely)
>incompatible
>extensions being released. Now, I'm constantly awed by the powerful
>solutions each of these offer for their special purpose, but I'm frustrated
>by their 'This'll fix anything and then some'-approach that makes the
>inclusion of other extensions problematic. I guess, window handling
>requires such a radical approach, but it's frustrating nontheless.

I am frustrated by this as well. In my opinion this problem has two
primary sources: A) the Inform language's framework for modifying/replacing
library code is not powerful enough; B) the Inform standard library's design is
not modular enough. The effect of B is that it is essentially impossible to
take control of the interface without replacing very basic library routines.
The effect of A is that any such replacements cannot themselves be replaced.
(There is no way to replace a routine which is itself a replacement for another
routine.)

With regard to GxScript specifically: I just glanced through the code.
The library design is modular enough that you shouldn't have to replace any of
the meat-and-potatoes of the library in order to get it to work with another
windowing system. It looks to me like you could get away with rewriting just
initialize, windowSetup, windowReset, and printMenu (all of which are property
routines in GxScriptManager).

Thomas Hudson

unread,
Mar 14, 2002, 4:57:49 PM3/14/02
to
In article <20020314145239...@mb-cg.aol.com>,

OKB -- not okblacke <bren...@aol.comRemove> wrote:
>"Axel Tölke" ax...@nospam.atoelke.demon.co.uk wrote:
>>I'm just wondering about this trend of proprietary (and largely)
>>incompatible
>>extensions being released. Now, I'm constantly awed by the powerful
>>solutions each of these offer for their special purpose, but I'm frustrated
>>by their 'This'll fix anything and then some'-approach that makes the
>>inclusion of other extensions problematic. I guess, window handling
>>requires such a radical approach, but it's frustrating nontheless.
>
> I am frustrated by this as well. In my opinion this problem has two
>primary sources: A) the Inform language's framework for modifying/replacing
>library code is not powerful enough; B) the Inform standard library's design is
>not modular enough. The effect of B is that it is essentially impossible to
>take control of the interface without replacing very basic library routines.
>The effect of A is that any such replacements cannot themselves be replaced.
>(There is no way to replace a routine which is itself a replacement for another
>routine.)

I think this is also a function of
(1) the age of the field
(2) the nature of IF code

My dates (and facts) are a little hazy, but for part 1 I think I can draw
some parallels to libraries for 3D computer graphics. Back before the
mid-80s every hardware had its own library. Even though the base ideas
were the same (specifying triangles in a 3-dimensional space, colors,
lights), you had to code them a significantly different way on every
platform. Different libraries may have subtly different capabilities.
There were standards proposed (PHIGS) that saw some use, but then SGI
released a corporate language - OpenGL - that became the de facto
standard. [Eventually Microsoft came along with Direct3D, and after
rewriting it 6 or 7 times they have something that rivals Direct3D in
capability and spread, but that's for a different message.]

So, we have OpenGL and Direct3D. All well and good when you're dealing
with fairly simple models; they've been used for lots of stuff. However,
to build a really complex application on top of them requires reams and
reams of extra code. In the early to mid 90s complex applications were
where basic graphics were in the 70s - each had a custom implementation,
although some implementations were repurposed (rendering engines for
first-person shooters) and there were a few higher-level libraries used
in industry (SGI Inventor and Performer). These additional layers of
code tend to be much narrower of focus, to only satisfy particular
purposes, whether writing a highly constrained video game (Quake engine),
providing lots of 3D widgets to interact with a low-complexity virtual
world (Inventor), visualizing 2D and 3D scientific datasets (OpenDX), or
supporting flight simulators, tank simulators, and other applications
that can be designed in a similar framework (Performer). Today there are
some more general-purpose libraries out there (Panda, Bamboo, ?), but
nothing appears to be approaching a standard; from what I've seen, VRML
and Java3D have tried and failed the same way PHIGS did.

So, computer graphics, a $ zillion per year industry, has a lag of at
least 10 years between the proliferation of a good low-level standard
and the adoption of a high-level standard, and I don't think one's
there yet - expect another 5 years for that. Meanwhile, there are
some very narrow, vertical solutions you can use for specific problems;
if your problem violates some of their assumptions, you either get
source code access or roll your own (been there, done that). The only
library that ever TRIED to be extensible the way we might like the
Inform library to be was Inventor, and many people didn't adopt it
because it was believed to be highly inefficient due to this
extensibility.

I think Inform and TADS are very much like OpenGL and Direct3D -
programming libraries that are designed around the basic concepts of the
genre, distilling out years of previous experimentation. Right now there
are some narrow, moderately powerful library contributions available that
we can use for specific problems, but we often end up going to source
code to rewrite it.

Take the introduction date of Inform, add 20 years divided by the ratio
in industy values to get how long I think it'll be until we can expect
powerful libraries that do everything for us.

Tom, who will probably be retired by then


Axel Tölke

unread,
Mar 14, 2002, 5:24:21 PM3/14/02
to
"Thomas Hudson" <hud...@cs.unc.edu> wrote in message
news:a6r6ct$jpk$1...@capefear.cs.unc.edu...

>
> Take the introduction date of Inform, add 20 years divided by the ratio
> in industy values to get how long I think it'll be until we can expect
> powerful libraries that do everything for us.
>
> Tom, who will probably be retired by then
>

You might be right there ;)

However, a lot of us aren't expert programmers, and therefore
rely on the contributions of the more skilled to achieve the
more delicate effects that we would like.

I personally don't think we desperately need a standard for
everything just yet. The standard Inform library (sorry know
nothing about TADS) is fine when it comes to crafting IF
of all manner of complexity.

However, some things, especially in GLULX got a lot harder
to do after making the switch. For example Statusline replacements
and especially window handling. To me, that's just very cryptic,
even with the wrappers and after spending a lot of time with
GULL. I personally would welcome if we could have a standard
(and easy to use!) method of handling windows, that writers
of other extensions would feel comfortable with basing their
further enhancements on.

Just one example: I cannot for the life of me figure out how
to switch the story stream between two windows (to do something
like the Photopia color effect). Its a common enough requirement,
I believe, that would warrant a nice easy to use high level
procedure :)

Best,

Axel


L. Ross Raszewski

unread,
Mar 14, 2002, 9:47:27 PM3/14/02
to


Yeah. It'd be nice if someone would write, y'know, a high level OO
library for handling Glulx windowing mechanisms :-)

--
http://justice.loyola.edu/~lraszews/if


Niezamysl Gwozdzinski

unread,
Mar 30, 2002, 8:46:06 PM3/30/02
to
m...@df.lth.se (Magnus Olsson) wrote in message news:<a6qsmh$8qo$1...@news.lth.se>...

> In article <a69830de.0203...@posting.google.com>,
> ems...@mindspring.com <ems...@mindspring.com> wrote:
> >I originally answered this post by private email.
> >
> >Then I thought: this is ridiculous. I miss raif.
>
> Raif has missed you.
>
> Welcome back!

Planet Earth to Planet Cornball! Could you please confine your
arse-licking to your private correspondence. It's nice to see you
haven't changed a bit since Durham.

Adam Thornton

unread,
Mar 31, 2002, 12:19:03 AM3/31/02
to
In article <618ac6f9.02033...@posting.google.com>,

Niezamysl Gwozdzinski <gosta_va...@hotmail.com> wrote:
>Planet Earth to Planet Cornball! Could you please confine your
>arse-licking to your private correspondence. It's nice to see you
>haven't changed a bit since Durham.

Hey, bus-stop boy: did Magnus piss in your Cheerios or something?
Because if he did, well, I've got a little someone who wants to have a
word with him, since there's only one person allowed to go
Cheerio-pissing at will in *this* newsgroup.

Adam

kodrik

unread,
Mar 31, 2002, 1:43:09 AM3/31/02
to
> Planet Earth to Planet Cornball! Could you please confine your
> arse-licking to your private correspondence. It's nice to see you
> haven't changed a bit since Durham.

http://home.adelphia.net/~ncavezze/sigs/kitteh2.jpg

Jim Fisher

unread,
Mar 31, 2002, 12:58:58 PM3/31/02
to
LOL!

That's hilarious!

--
Jim (AT) OnyxRing (DOT) com
Visit "An Inform Developer's Guide" or browse the
"ORLibrary" extensions to the standard library at
www.OnyxRing.com
----------------------
Some days you eat the code; some days the code eats you

"kodrik" <kod...@zc8.net> wrote in message
news:uadc8k9...@corp.supernews.com...

Peter Seebach

unread,
Apr 1, 2002, 12:38:09 AM4/1/02
to
In article <uadc8k9...@corp.supernews.com>, kodrik <kod...@zc8.net> wrote:
>http://home.adelphia.net/~ncavezze/sigs/kitteh2.jpg

I'm now starting to wonder which of the many variants of this was the
original.

-s
--
Copyright 2002, all wrongs reversed. Peter Seebach / se...@plethora.net
$ chmod a+x /bin/laden Please do not feed or harbor the terrorists.
C/Unix wizard, Pro-commerce radical, Spam fighter. Boycott Spamazon!
Consulting, computers, web hosting, and shell access: http://www.plethora.net/

David Brain

unread,
Apr 2, 2002, 10:36:00 AM4/2/02
to
In article <3ca7f241$0$79559$3c09...@news.plethora.net>, se...@plethora.net
(Peter Seebach) wrote:

> In article <uadc8k9...@corp.supernews.com>, kodrik <kod...@zc8.net>
> > wrote:
> >http://home.adelphia.net/~ncavezze/sigs/kitteh2.jpg
>
> I'm now starting to wonder which of the many variants of this was the
> original.
>

All your kitten pics are belong to us.

--
David Brain
London, UK

Reply all
Reply to author
Forward
0 new messages