[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-----