January 1998
- Mail from mud Zoran's final Imp Stephen Zepp
- Mail from mud Zoran's final Imp coder@ibm.net
- Mail from mud Zoran's final Imp Shawn Halpenny
- Mail from mud Zoran's final Imp JC Lawrence
- Mail from mud Zoran's final Imp Shawn Halpenny
- Happy new year Marian Griffith
- Totally OT... Marian Griffith
- Totally OT... (Or is it?) s001gmu@nova.wright.edu
- Mud-Dev FAQ Ling
- Mud-Dev FAQ Jon A. Lambert
- Mud-Dev FAQ JC Lawrence
- Mud-Dev FAQ Adam Wiggins
- Who's bugging who? : was- Wild West Jon A. Lambert
- my bio (was Mud-Dev FAQ) Mike Sellers
- request for comments (was: Mud-Dev FAQ) Vadim Tkachenko
- request for comments (was: Mud-Dev FAQ) Jon A. Lambert
- request for comments (was: Mud-Dev FAQ) coder@ibm.net
- request for comments (was: Mud-Dev FAQ) JC Lawrence
- request for comments (was: Mud-Dev FAQ) s001gmu@nova.wright.edu
- request for comments (was: Mud-Dev FAQ) JC Lawrence
- request for comments (was: Mud-Dev FAQ) Vadim Tkachenko
- OT: Suomi Finland Ola Fosheim Grøstad
- OT: Suomi Finland ##Make Nylander
- Totally OT... (Or is it?) (yes it is ;) Marian Griffith
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) Adam Wiggins
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) Jon A. Lambert
- Totally OT... (Or is it?) (yes it is ;) Ola Fosheim Grøstad
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Totally OT... (Or is it?) (yes it is ;) Jon A. Lambert
- Totally OT... (Or is it?) (yes it is ;) Mike Sellers
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Totally OT... (Or is it?) (yes it is ;) JC Lawrence
- Journal of MUD Research, Vol. 3, No. 1 [TEXT] coder@ibm.net
- World Seeding (was Task Parsing) Ling
- World Seeding (was Task Parsing) JC Lawrence
- World Seeding (was Task Parsing) Stephen Zepp
- threaded servers (was request for comments Mike Sellers
- MUD Economy Shawn Halpenny
- MUD Economy Adam Wiggins
- MUD Economy Shawn Halpenny
- MUD Economy Ling
- MUD Economy Brandon J. Rickman
- MUD Economy Marian Griffith
- MUD Economy Shawn Halpenny
- MUD Economy Shawn Halpenny
- MUD Economy JC Lawrence
- MUD Economy Koster, Raph
- MUD Economy Matt Chatterley
- MUD Economy JC Lawrence
- MUD Economy Jon A. Lambert
- OT: Jobs available Koster, Raph
- OT: DCOM and RMI Jon A. Lambert
- OT: DCOM and RMI Vadim Tkachenko
- OT: DCOM and RMI Vadim Tkachenko
- OT: DCOM and RMI Miroslav Silovic
- OT: DCOM and RMI Alex Oren
- OT: DCOM and RMI Chris Gray
- request for comments Miroslav Silovic
- request for comments JC Lawrence
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) Vadim Tkachenko
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) Matt Chatterley
- Event handling (was: request for comments) s001gmu@nova.wright.edu
- Event handling (was: request for comments) s001gmu@nova.wright.edu
On Sun, 11 Jan 1998, JC Lawrence wrote:
> On Fri, 9 Jan 1998 13:51:24 PST8PDT
> s001gmu <s001gmu@nova.wright.edu> wrote:
<old, and somewhat confusing attributions removed. everything in here is
mine, from my last post, JC's response, or my most recent response>
> > mmm.. I dunno that that is really a valid concern... I am leaning
> > more and more towards JC's Spoof/Watcher model, which allows for
> > such things nicely (definately planning on spoofs.. still thinking
> > about watchers..
>
> Spoofs and watchers have different function, altho their capabilities
> can cross. The intent of a watcher is purely to tragger on sate
> changes. This allows objects to react to changes in other objects:
*nod* And together with an event driven system, they make a very powerful
system.
<watchers explination and examples removed>
> I wanted a general solutionw hich could elegantly handle all of these
> without special casing.or requiring bizarre design or coding rituals.
>
> > dunno if my design goals necessarily coincide with
> > the ones you chose that lead to spoofs/watchers, JC).
>
> I presume this means that requirement that any feature must be able to
> be programmed without requiring source access to any objects other
> than the ones embodying the featuer?
*nod* I'm still debating that. I like a lot of the power that shortcuts
provide, and I'm debating wether the cost of the shortcut (restricted
further developement) is worth the benefit.
> > W/O using
> > watchers (to watch the phase of the moon), I would schedule an event
> > to go off at the beginning of the time the lycanthrop should morph,
> > to trigger the morph, and then one to go off at the end of the time,
> > to morph the poor bastich back.
>
> What happens if Bubba manages to delay or accellerate moon-rise/set?
hadn't planned on letting ppl make changes of that scope, but it does
bring up the issue for less admin controlled situations (Castle Crack and
the Bucket... ;)
> What if this was thru administrative errors (Admin reset the time and
> forgot some details)? You are creating an indepedant system which
> does not rely on or react to the data which it pretends to be
> dependant on.
Aye. There obviously has to be some form of information passing. Which
leads to... :
> There are two base approaches: watchers and messages.
>
> In the watcher case all lycanthropes merely matain a watcher on the
> relevant moon object and respond accordingly. The moon
> sets/rises/whatever, the watcher is triggered and they have a chance
> to react appropritately.
>
> In the message passing case the moon state-changes and realises that
> other objects may be dependant on that state change, and thus sends a
> message to them, or directly invokes their methods to make the changes
> itself (ugly).
>
> There really is very little difference here from the watcher model
> except that it is now the object itself determining that the state
> change is relevant, and the object itself also now needs to maintain
> its lists of who to send the state-change messages. Watchers just
> virtualise this model by having external generic non-invasive objects
> do all the work of triggering and sending the messages.
>
> The programmer for the mood doesn't need to know a thing about
> lycanthropy or wolves howling, he just needs to account for the moon.
> Similarly the programmer for the were-wolves doesn't need to hack the
> source for the moon, he just has his were-wolf objects put a watcher
> on the moon (a very standard, on-line command), and then writes a
> couple lines of code to look for the state-changes he is interested
> in.
<stream-of-consciousness>
given an event driven system, it becomes a problem of action-reaction.
each event has an unknown number of objects which are interested in the
event, IE: should react to it.
Some of those objects may have to interrupt pending events...
given the unknown number of interested parties, it makes sense to have
some centralized list, each party expressing what kinds of events it is
interested in (event masks? :)
Problem: potentially every object in the game (even those dumped in
cold-storage) could be on that list... in fact, should be.
Proximity to the event (range determined by perception method/ abitilies)
allows for most normal events to be 'broadcast' to the correct subset of
all objects... but what about non-proximate parties?
... hmmmm...
</stream-of-consciousness>
I think I need to sit down some place quiet and think about this a lot.
:) Part of me balks at adopting another's technique w/o first analyzing
it to death... :) I may go quiet for a few days as I sort things out...
> > No real worries about multiple
> > events targeting the same data at the same time, as the events would
> > occure once a month! :)
>
> Until Superman gets that moon spinning faster in a lower-orbit.
*nod* see above thoughts, etc. :)
[switching topcis]
> > I'm thinking the best solution might be to fall back on DB
> > backups... every <so often> the program dumps a 'current state' of
> > the pc to the DB. if a crash occurs, the last 'current state' is
> > loaded. Current states would include enough info to reconstruct the
> > events for the character in question. Some events would have to be
> > handled seperately... combat type events, etc. mmm.. definately
> > requires some thought. Mayhaps I shall go dig up my concurant
> > software design notes, and DB notes on rollback techniques.
>
> One of my early design had the DB do periodic saves to backups. The
> problem as you note was maintaining logical consistancy for changes to
> the DB __during__ the backup procedure without requiring the entire
> game to halt during the backup.
>
> It can be done. The solution consists of two parts:
>
> 1) for object in DB, write object to backup DB.
>
> 2) for object change during backup where object has been written to
> backup DB, flag object in backup as deleted, write changed object to
> current running DB __and__ backup DB, and update indexes appropriately.
hmm.. don't think I quite communicated our model correctly. we plan on
having active parts of the game loaded into memory, and less active parts
stored in the DB. The active parts will be changed frequently, w/o writes
to the DB. the backups I spoke of were updates to the db. Poor choice of
words on my part. We planned on having the 'db writes' for active objects
occure at some regular interval, starting from the time the object became
active. For PCs, this means when they logged in, NPCs and objects, etc,
from the time a player walked into the area (or whatever grain we go with
to pull a chunk out of cold storage). Due to the staggered times for all
of this, each player/npc/etc will be 'saved' at different times, creating
ALL SORTS of fun. :)
> > Bubba and Boffo are fighting. Bubba and Boffo are on different
> > clocks for their 'db backup' events. Combat is interrupted by a
> > crash / termination / reboot / whatever. If all events are stored
> > in the db backup, Bubba and Boffo will have different pending combat
> > events, based on the different times at which their last backup was
> > made.
>
> True.
A thought I just had.. what if events not generated by an automated
process (IE: combat, etc) are the only ones stored? mmm... no... healing
events are auto-generated. But then, I 'spose we could patch that at
login...
if (hp < max_hp)
generate_event("HEAL", &char-name);
hmmm.. we'd have to work up a fairly generic system to allow for future
expansion.. a way to store enough info to re-start the event chain
mid-way, for events that affect only the charater in question...
More fodder for thought experiements. :P
> > Easy solution, put everyone on the same clock. problem: large db
> > writes, all at once. slams system pretty good with a lot of ppl on.
>
> See above. You can make the backup thread quite low priority.
>
> > definately a DB rollback issue.
>
> Nooo. A consistancy issue.
how to maintain DB consistency in case of an unexpected shutdown? sounds
like Rollback to me...
> > Any comments from the peanut gallery? :)
>
> More salt please.
heh... 's always nice to start a monday morning with a little humor.
Granted, I didn't get around to replying to this part of the message until
evening, but hey. :)
-Greg
- Event handling (was: request for comments) JC Lawrence
- Event handling (was: request for comments) Vadim Tkachenko
- request for comments JC Lawrence
- Text vs Video; Movies, Books & muds. Nathan Yospe
- Unique items (was: Graphic MUDS/Ultima Online) Vadim Tkachenko
- Unique items (was: Graphic MUDS/Ultima Online) JC Lawrence
- Unique items (was: Graphic MUDS/Ultima Online) Brandon J. Rickman
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
- Unique items (was: Graphic MUDS/Ultima Online) Brandon J. Rickman
- Unique items (was: Graphic MUDS/Ultima Online) Marian Griffith
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Chris Gray
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Unique items (was: Graphic MUDS/Ultima Online) Adam Wiggins
- Unique items (was: Graphic MUDS/Ultima Online) coder@ibm.net
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Unique items Richard Woolcock
- Unique items Jon A. Lambert
- Unique items Vadim Tkachenko
- Unique items Jon A. Lambert
- Unique items JC Lawrence
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Delivery Notification: Delivery has failed PMDF e-Mail Interconnect
- Two Tiers Ling
- MUD Development Digest Dr. Cat
- FAQ Ling
- Clients Matt Chatterley
- Clients JC Lawrence
- Clients Shawn Halpenny
- Clients Matt Chatterley
- Event handling - some definitions Jon A. Lambert
- Event Handling Jon A. Lambert
- Simulations - was: 'A flamewar startingpoint.' Jon A. Lambert
- Formatting apology Stephen Zepp
- OT: Insane Wordwrapping Caliban Tiresias Darklock
- OT: Insane Wordwrapping Alex Oren
- Summary Marian Griffith
- Clients Andrew Wilson
- Vast areas in muds Ling
- Vast areas in muds John G.
- Vast areas in muds Nathan Yospe
- Vast areas in muds Mike Sellers
- Vast areas in muds John G.
- Vast areas in muds Nathan Yospe
- META: Web futures for the list JC Lawrence
- OT: Socket programming - platform specific Jon A. Lambert
- OT: Socket programming - platform specific Chris Gray
- OT: Socket programming - platform specific Jon A. Lambert
- OT: Socket programming - platform specific Caliban Tiresias Darklock
- OT: Socket programming - platform specific Chris Gray
- Graphical mud perspectives Richard Woolcock
- Graphical mud perspectives Nathan Yospe
- Graphical mud perspectives Richard Woolcock
- Graphical mud perspectives Koster, Raph
- Graphical mud perspectives Mike Sellers
- Graphical mud perspectives Koster, Raph
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads Nathan Yospe
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads Brandon Gillespie
- CORBA, RMI, threads Chris Gray
- CORBA, RMI, threads Marc Eyrignoux
- CORBA, RMI, threads Brandon Gillespie
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads coder@ibm.net
- CORBA, RMI, threads s001gmu@nova.wright.edu
- CORBA, RMI, threads Vadim Tkachenko
- CORBA, RMI, threads Caliban Tiresias Darklock
- CORBA, RMI, threads coder@ibm.net
- Clients based on Netscape 5? Greg Munt
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Caliban Tiresias Darklock
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Caliban Tiresias Darklock
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Vadim Tkachenko
- Clients based on Netscape 5? Chris Gray
- Clients based on Netscape 5? Marian Griffith
- Clients based on Netscape 5? coder@ibm.net
- OT? The impact of the web on muds Mike Sellers
- The Anti-Mac Interface JC Lawrence
- 3D graphics (Was: The impact of the web on muds) Jon Leonard
- 3D graphics (Was: The impact of the web on muds) Caliban Tiresias Darklock
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- 3D graphics (Was: The impact of the web on muds) Mike Sellers
- 3D graphics (Was: The impact of the web on muds) Chris Gray
- 3D graphics (Was: The impact of the web on muds) Caliban Tiresias Darklock
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- 3D graphics (Was: The impact of the web on muds) coder@ibm.net
- VRML Becomes ISO/IEC International Standard (fwd) Nathan Yospe
- Arctic's Project? Brandon Cline
- Arctic's Project? Adam Wiggins
- Arctic's Project? Brandon Cline
- Arctic's Project? Chris Gray
- FAQ Marc Eyrignoux
- Java and Javascript Greg Munt
- Java and Javascript Chris Gray
- Java and Javascript Matt Chatterley
- Java and Javascript coder@ibm.net
- Java and Javascript Matt Chatterley
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Matt Chatterley
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Chris Gray
- Java and Javascript Jon Leonard
- Java and Javascript Matt Chatterley
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Ben Greear
- Java and Javascript Jon A. Lambert
- Java and Javascript Mike Sellers
- Java and Javascript J C Lawrence
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Travis Casey
- Java and Javascript Jon A. Lambert
- Java and Javascript Sauron
- Java and Javascript Jon A. Lambert
- Java and Javascript Caliban Tiresias Darklock
- Java and Javascript Alex Oren
- Java and Javascript Chris Gray
- Java and Javascript coder@ibm.net
- Java and Javascript Matt Chatterley
- Java and Javascript coder@ibm.net
- MetaVoice, MetaFont Ling
- MetaVoice, MetaFont Richard Woolcock
- MetaVoice, MetaFont Vadim Tkachenko
- MetaVoice, MetaFont JC Lawrence
- MetaVoice, MetaFont Chris Gray
- The MLI Project Vadim Tkachenko
- The MLI Project Marc Eyrignoux
- The MLI Project Vadim Tkachenko
- The MLI Project coder@ibm.net
- The MLI Project Ling
- The MLI Project coder@ibm.net
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Travis Casey
- The MLI Project Travis Casey
- The MLI Project coder@ibm.net
- The MLI Project s001gmu@nova.wright.edu
- The MLI Project Vadim Tkachenko
- The MLI Project Travis Casey
- The MLI Project Stephen Zepp
- The MLI Project coder@ibm.net
- The MLI Project Travis Casey
- The MLI Project Chris Gray
- The MLI Project Ling
- The MLI Project Andrew C.M. McClintock
- The MLI Project Ling
- The MLI Project Chris Gray
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Chris Gray
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Niklas Elmqvist
- The MLI Project Caliban Tiresias Darklock
- The MLI Project Chris Gray
- The MLI Project Ling
- The MLI Project Caliban Tiresias Darklock
- The MLI Project J C Lawrence
- The MLI Project Chris Gray
- The MLI Project Koster, Raph
- The MLI Project J C Lawrence
- The MLI Project Vadim Tkachenko
- Races and stuff (was: FAQ) Vadim Tkachenko
- Races and stuff (was: FAQ) Marc Eyrignoux
- Races and stuff (was: FAQ) Vadim Tkachenko
- OT: I'm moving again! JC Lawrence
- MUD Development Digest Dr. Cat
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Chris Gray
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities coder@ibm.net
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities Greg Munt
- Administrative Responsibilities Jon A. Lambert
- Administrative Responsibilities coder@ibm.net
- Administrative Responsibilities Chris Gray
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Mike Sellers
- Administrative Responsibilities Adam Wiggins
- Administrative Responsibilities Greg Munt