[Reality] Unsatisfactory Consequences

Glyph Lefkowitz reality@twistedmatrix.com
Thu, 6 Mar 2003 11:40:29 -0600


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Thursday, March 6, 2003, at 10:21 AM, Allen Short wrote:

> To start with, the parser doesn't look at any of the participants'
> interfaces before dispatch, so "blow whistle" results in ambiguity,
> as do the other two commands.

Argh.  It should _definitely_ be doing this: based on a brief glance at 
the code I don't see how it could be.  If I get a chance to poke at 
this later in the day, I will investigate.

> ToolActions DTRT when tool = None. However, there's no feedback to
> indicate this, such as "(with the rocket)".

Hmm... this doesn't sound bad to fix in a pretty basic way, but 
separating cause and effect would allow us to format the action in a 
much more interesting way.

> There's no code for picking up tools before using, but it has been
> pointed out that this might be a feature.

However, I still believe that it ought to be _possible_ to provide this 
option to the developer and/or user.  It's a small feature of Refusal...

> Finally, events emitted by closed Doors do not propagate beyond the
> Door itself. should Door.collectImplementors check whether asker is
> self?

Probably.

I've been working on a little diagram (attached) in order to clarify 
for myself how collectImplementors is influenced by the difference 
between "outgoing" and "incoming" links.  There may be some argument I 
want to add to collectImplementors at some point.

> Another bothersome thing: formatTo methods get run only after
> doAction. I can understand why -- you dont want to run them if the
> action fails -- but this makes things look odd when the results of the
> action print before the confirmation of its execution does. ("You
> destroy the grid bug! You start bashing monsters with your pickaxe.",
> etc.)

Wow!  This totally passed me by.  However, it sheds light on the 
events-which-make-you-move problem.  (Though that was solved through 
other means...).  Each action (cause) should probably have a list of 
effects.  These effects happen in order after the action.

As an added bonus, this would give the sanity check that an action that 
has generated effects and then raised an exception is almost 
indubitably a game bug :).  However, we could still publish the events 
(until we have transactions of some kind in the game kernel, ha ha) and 
log the action / exception.

> Thoughts on which bits needs to be fixed in the code and which bits
> need to be fixed in the paper?

Well, they _all_ need to be fixed in code.  However, we may not have 
enough time to do this for the presentation of the paper, so there may 
be some shuffling into "future work".  You don't seem to be talking 
about event propogation much, so that could probably be put off (and 
might be the one that would involve the most substantial changes)

>> BLOW WHISTLE
>> BLOW CANDLE
>> BLOW UP DOOR

DEFINITELY fix this in the code.

> - [first taking the rocket launcher]

I'm inclined to say that this should be fixed too, because it'd be 
pretty trivial to add to the Refusal.

I sure hope that I can get 'net access in the hall during after my 
roundtable this afternoon.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)

iD8DBQE+Z4gSvVGR4uSOE2wRAgPjAJ440KiqfCsIjhbd/Am5670Q/N6seQCff5JR
N3NmuMPTQrfztN0LgvyFVbQ=
=/SJo
-----END PGP SIGNATURE-----