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

nu.kanga.list.mud-dev

48: Re: Just a bit of musing

[Full Header] [Plain Text]
From: "Chris Gray" <cg@ami-cg.GraySage.Edmonton.AB.CA>
Newsgroups: nu.kanga.list.mud-dev
Date: Thu, 13 Mar 97 18:09:35 MST
Organization: Kanga.Nu
:Yes this is a specialized client.  It is designed to run on my server and
:only
:my server.   In fact it's quite impossible to connect to any other mud with
:it.
:The client app is actually part of the servers database and is
:automatically
:updated if necessary by the mud web server.  As a standalone client it is
:worthless.

I assumed your client would only work with your server, but I guess I'm
not used to the concept of a server that only runs one scenario! I was
thinking that all of the stuff about what meters, etc. exist would be
defined in the database, and so subject to change.

--
Chris Gray   cg@ami-cg.GraySage.Edmonton.AB.CA
patiently... > > The assassin should have recieved a message when Ross zipped by, triggered > by the request to the room to move Ross from point A to point B in the > assassin's corridor. Now, if the event waiting state of the assassin was > tight on the trigger, fire on the first thing that moves, there should > have been a toss up between Ross and the assassin, no typing needed on the > assassin's part, in that permission to move request. I agree on the no typing bit, it seems insane to have to control your character's every move down to the smallest detail. Muds which do require fast reactions tend to be dominated by the clients with the fastest triggers. > :The reason I present such a weird scenario is coz, if there are > :transparent exits and characters run, in my system, the characters would > :appear in the mudworld at certain points skipping the intervening space... > > Right, noticed this. > > :Any ideas on this one? > > Running should poll ahead, not just for assassins, but for covered pits, > loose gravel, etc, etc, etc. Of course, this does work better in an event > driven system with sleeping events, a concept I borrowed from threads. My > events are very much based on threads, in fact. Aside from that, perhaps > smaller, faster steps? If you are running on a pulsed cycle, that may not > be possible.... Yep, I'm running on a pulsed cycle, which means I can't run any real time movement effectively but I can try. Maybe I could spend the summer hacking away at a driver. Anyone care to teach me something on this? :) A solution I just thought up whilst typing is to place an object the size of the assassin's field of vision on the floor of the corridor. Anything colliding with the object will trigger a reaction on behalf of the assassin. Although, I need to work out how to check collisions first... Ling aka Ceilidh at a few muds. | _O_O_ Ling - Freshwater fish