[Home] [Groups] - Message: [Prev in Group] [Next in Group]

nu.kanga.list.mud-dev

20: Re: {MUD} Expanding the mud list

[Full Header] [Plain Text]
From: "Chris Lawrence" <clawrenc@xsvr1.cup.hp.com>
Newsgroups: nu.kanga.list.mud-dev
Date: Mon, 26 Aug 1996 09:30:27 -0700
References: [1]
Organization: Kanga.Nu
On Aug 25,  7:40am, Alex Oren wrote:

> BTW, I have a list of addresses of people who participated in the "design
> group" of the (now defunct) Java MUD mailing list.  Maybe some of them
> will be interested to participate here too.
...list ellided...

If they were active contributers of good ideas, then hey, why not?  I feel that
we are beginning to die a little here as we fall into debating small details
rather than core ideas.  Some new blood would be good.

BTW:  Has Orlando Burnett just up and died, or is he the non-posting sort?


--
J C Lawrence                           Internet: coder@ibm.net
---------------(*)               Internet: clawrenc@cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...
> process list, and the others are killed. > > When you add an event, you ask the object that is to run it if it should > only run after another event. if so, fill that event in in the list. At the implementation level, this would do it, but it would seem to require the scheduler etc to have prior knowledge of the character of the commands being processed. In you example (deleted) you mention movement commands. The problem is that it is not only those commands, or more specifically, those combinations of commands which are sequence specific. Consider, given the following map: +---+---+---+ Where: | | | | X is you. | d D T | d is a small weak dragon. | | | | D is an unkillable, massively damaging sleeping dragon. +- -+---+---+ T is some great treasure you want. | | | X | | | +---+ > n > kill dragon > e > e It would be uncomfortable if the kill command were processed after the first east. > Whaddayathink? I think Alex had the right idea is saying that be default all commands should be forced to compleat in entry order. His suggestion of also not starting processing on one until the prior command compleats is tantalising, but I think I'll extend that. My idea is that a command resulting in an event which does not call a method on the same object as the event it is sequentially dependant on, may start processing prior to the event it depends on compleating first compleating. ie Given the following sequence of entered commands: > #1 > #2 > #3 Where those commands result in events A, B and C respectively, and where event A calls a method on ObjectX, event B calls a method on ObjectX, and event C calls a method on ObjectY. A will start processing. B cannot start processing until A compleats. C may start processing before B compleats. Another example of why I want to allow interruption of a pre-entered series of commands: > n then e then e then s You go north. You go east. There is a an incredibly valuable object here! You go east. You go south. Something like: > n then e then e then s You go north. You go east. There is a an incredibly valuable object here! > !! Queued commands killed. > get incredibly valuable object. Okay. would be preferable. -- J C Lawrence Internet: coder@ibm.net ---------------(*) Internet: clawrenc@cup.hp.com ...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...