March 1997
- Linear Quadtrees Carter T Shock
- Linear Quadtrees gzhang1234@yahoo.com
- q-tree stuff Chris Gray
- q-tree stuff Carter T Shock
- q-tree stuff coder@ibm.net
- Issues from the digests and Wout's list Alex Oren
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Caliban Tiresias Darklock
- Issues from the digests and Wout's list coder@ibm.net
- Issues from the digests and Wout's list Miroslav Silovic
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list S001GMU@nova.wright.edu
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Travis Casey
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Orion Henry
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Ling
- Issues from the digests and Wout's list Shawn Halpenny
- Issues from the digests and Wout's list Nathan Yospe
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Jon A. Lambert
- Issues from the digests and Wout's list clawrenc@cup.hp.com
- Issues from the digests and Wout's list Jeff Kesselman
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Chris Gray
- Issues from the digests and Wout's list Adam Wiggins
- Issues from the digests and Wout's list Jeff Kesselman
- ListMail dupes coder@ibm.net
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues Chris Gray
- Threads, IO handling, and Event Queues coder@ibm.net
- Threads, IO handling, and Event Queues Carter T Shock
- Threads, IO handling, and Event Queues Nathan Yospe
- Threads, IO handling, and Event Queues claw@null.net
- Threads, IO handling, and Event Queues coder@ibm.net
- mud grammar (was Just a bit of musing) Carter T Shock
- mud grammar (was Just a bit of musing) Nathan Yospe
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar (was Just a bit of musing) claw@null.net
- mud grammar (was Just a bit of musing) Chris Gray
- mud grammar Carter T Shock
- mud grammar Nathan Yospe
- mud grammar Alex Oren
- mud grammar Nathan Yospe
- mud grammar Adam Wiggins
- mud grammar Chris Gray
- Just a bit of musing (VRML) Dmitri Kondratiev
- Just a bit of musing (VRML) claw@null.net
- Room coding Nathan Yospe
- Room coding Furball
- command parsing Chris Gray
- command parsing Adam Wiggins
- command parsing claw@null.net
- Room coding S001GMU@nova.wright.edu
- Room coding Chris Gray
- Resets and repops Furball
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
On Tue, 18 Mar 1997 claw@null.net wrote:
:On 17/03/97 at 12:17 PM, "Jon A. Lambert" <jlsysinc@ix.netcom.com> said:
:>I heartily agree with your sentiments. I am attempting something
:>similar. I treat most NPCs identically to characters. The subsystems
:>that NPCs run issue commands to an input buffer. In like fashion, the
:>players' input buffers are written to by the network process.
The problem here is that you get the same overhead on an NPC as on a PC,
with the interpreter, but twice, as you have to create the NPC commands in
the first place. I do allow for this in my own system, but I also have
lower level command access for both PCs and NPCs, and in general, PCs tend
to use the command buffer more, NPCs the lower level access. Nonetheless,
PC reflexes, for example, take advantage of low level access, adn some
people will undoubtably use the high level access when programming NPC
behavior. My PCs and NPCs are not different classes... there is a single
tag with enumerated values Player/AI/Comp Control/Switched Out for the
four basic states of behavior. Imms cannot enable anything but their own
bodies and Comp Control bodies... In other words, no player body stealing,
and no disruption of complex evolutionary AIs.
:I don't distinguish between any sort of objects, be they rooms, mobiles,
:dumb objects, or players. They're all the same, all do the same things,
:and outside of the IO going to a connection object for players, all run
:exactly the same code.
That's interesting... you use a free user programming system, though,
don't you? My Characters are not physically there... they are sort of a
core for a creature to be built around, out of Item components... an Item
is simply a composite of Item components with no Character mind behind it.
I guess this is partly a result of my limb component system... any Item
component, capable of being a full fledged Item in its own right, has a
set of Types it inherits behaviors and characteristics from, many of which
are precoded in binary form, but which can be added to by internal
programming. As such, you can program a Character, but you can also
specifically program its arm to be, say, a cybernetic cannon with special
targetting...
:What I don't do is bind player characters or non-player objects to using
:the parsed command line. Any object may directly call any method, with
:any set of arguments, on any other object. Of course it is then up to the
:receiving object's security criteria as to how and if it accepts the call
:(stolen straight from COOL). As such the automation code for mobiles
Very few of my objects can be called at all by anything outside of the
Environmental Nuance And Balance/Localized Event State (don't blame me,
one of my friends is an acronym freak and suggested the above when I
attempted to describe the enables system.) What this means is that my
system cannot be commanded to act, except by proxy or programmed response.
Everything is based on the ability of every object to REact. This means
that every object has a set of reactions to poll through for various
impulses, but does not have to react to any specific impulse. (Though, for
example, gravity is a very persuasive impulse, with a reaction that
cannot, in the current version, be overridden, merely countermanded.)
:(that's all a mobile is: a normal object with an event chain that causes
:state changes in the mobile) can directly call the relevant methods to
:affect the subject mobile, or it can lodge command strings to be parsed
:into a direct method call (which in truth is just another method call with
:the command as an argument).
For me, a Character is an object capable of taking commands (from the
Player, AI, etc) and delivering impulses to associated Item components.
(Sort of a nervous system representation)
:Part of the neat aspect of this is that I expect players to augment
:themselves and their character objects with home-grown, purchased, stolen,
:or otherwise acquired code to implement various neat features. Earlier
:discussion focussed on the Combat Packages aspect of this (more or less
:intelligent user-written combat AI libraries), but I can also see it
:happening with socials, naming cards (objects which
:auto-register/de-register names on teh recipient), mana factories/sinks,
:etc.
Hmm. Of course, having made my world highly dependent on real world
physics, none of this is relevant to me, but my codebase certainly doesn't
forbid it, should an admin of some less scientific version decide to make,
for example, programming equivalent to spell design/learning/casting.
Again, this would require some interesting constraints on programming...
making the programs cost the programmers big time in some manner...
:BYOC takes a whole new meaning.
Heh. As opposed to my system: BYOI - bring your own intelligence. A player
cannot write code to violate physics, but there is nothing to prevent AI
writing, though the AI will have the same limits as a player... merely,
possibly, faster reflexes. I expect and encourage players to write AIs for
whatever they feel an AI could handle better than they could... then rate
builder's products on how much Player AI is used in the builder's zone.
Certainly ups the creativity factor... and since the rating factors into
how many mortality points a builder can gain (which make the difference in
terms of reincarnation, as well as purchasing more builder resources,
creating new Characters, etc...) for an area, builders vie for the most
complex Area AIs and challenges.
:>I also agree with the concept that NPC activity continues in areas/zones
:>that players are not present in. There can be significant overhead
:>involved with this.
:Hehn. I took a classic (for me) tack, and decided to ignore the problem
:on the basis that it would invalidate the server both for simulation
:work, and because addressing it would cause any unrelated synergy across
:the MUD world to dissappear (eg rumours of events in areas not populated
:with players would no longer propagate, which would cause remote reactions
:to their rumours (cf watchers, spoofs and triggers) to no longer occurr).
This, for me, can be handled completely by the update factors... and I
could never run a simulation without a TuringAI controlling at least one
Character in the simulation region, and TuringAIs trigger action the same
as Players. TuringAIs are designed to convince Players that they are
Players, thus upping the apparent Player density... and forcing people to
look alive, lest they be mistaken for a poorly designed TuringAI. The less
desirable Players get kind of weeded out by these things. In any case, the
overhead on the system, if I ran _everything_ would be far too great.
Better to run a handful of Areas where the Players are... it also keeps
track of where people go quite well.
:>I have attempted to balance this by programming some
:>NPCs to be "marshalls" for other NPCs or controllers of city/town
:>subsystems. Thus not all NPC scripts are active and consuming resources
:>all the time. For instance city guard captains are programmed to issue
:>patrol orders and attack orders to their charges. An interesting side
:>affect is that by taking out a "marshall" or subsystem controller, a
^e?
:>great amount of chaos ensues until a replacement NPC is found.
:Cute. I like this.
Hmmm. I tend to like everything remotely active to be completely active,
thinking for itself to a greater or lesser extent.
:>In a related vein, I was inspired by Nathan's description of his
:>implementation of the physical laws of the universe to do something not
:>altogether dissimilar in my server. While Nathan's model seems highly
:>appropriate to a real world with real laws of physics, my world's physics
:>are entirely subject to the whims of the gods. I don't believe in
:>physics, I believe in divine intervention. (*grin*) It was my original
:>intention that all immortals/deities actually be THAT. They can be
:>player/administrator run and can be used literally as gods. My immortal
:>pantheon is very similar to the greek mythos albeit with different names.
*grin* I modeled a bit of that into my graphical project... I like it too,
and hope someone will eventually run such a world with a Physmud++ base...
I certainly provided enough support for that, and for alternative physical
models... nonetheless, any consistant model will create a better mud,
whatever the model may be.
:>They demand sacrifices, quests and generally participate in mortal
:>affairs. As such they are roleplayed by whomever is granted with the
:>responsibility. With this in mind, I have done away with my solar/lunar
:>timer events and have assigned maintenance and execution of these events
:>to the Apollo NPC's and Artemis NPC's subsystems.
Quite nice. How do you model the Deiatic charis
:> It may be that Apollo might wish to delay the sunrise to allow a favored
:>player to gain advantage in an early morning attack or Artemis decides
:>that an eclipse would be appropriate to auger a significant event. With
:>the NPC always "playing", it is possible for them to respond in an
:>automated way to sacrifices, prayers and quests. There are many other
:>possibilities, as I decide which dieties' subsystems control which mud
:>events.
Linking scheduling is quite simple in my system, partly because I had to
allow for the distorted physics of the region around a black hole, the
effects of time dialation, and simpler matters such as different planetary
systems, differing gravitational fields, free fall localities, fluid
environments... I think I could link in a "gods" system fairly easilly.
The whole point of Physmud++ is that it can model any, _any_ set of laws
to the universe.
:cf the original Gods system. You can find a passable description in
:Bartle's original MUD survey.
Uh... what survey would this be?
__ _ __ _ _ , , , ,
/_ / / ) /_ /_) / ) /| /| / /\ First Light of a Nova Dawn
/ / / \ /_ /_) / \ /-|/ |/ /_/ Final Night of a World Gone
Nathan F. Yospe - University of Hawaii Dept of Physics - yospe@hawaii.edu - Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Travis Casey
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Shawn Halpenny
- Resets and repops Jeff Kesselman
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Jon A. Lambert
- Resets and repops Nathan Yospe
- Resets and repops Furball
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops claw@null.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops coder@ibm.net
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops clawrenc@cup.hp.com
- Resets and repops S001GMU@nova.wright.edu
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops claw@null.net
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Adam Wiggins
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Nathan Yospe
- Resets and repops Chris Gray
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops lhulbert@czn.com
- Resets and repops claw@null.net
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops Adam Wiggins
- Resets and repops Chris Gray
- Resets and repops Chris Gray
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- Resets and repops claw@null.net
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar claw@null.net
- List software claw@null.net
- List software Nathan Yospe
- List software Chris Gray
- List software claw@null.net
- List software claw@null.net
- I got your message..! MAYA DASWANI
- 3D graphics claw@null.net
- Sorry for the dups (again) coder@ibm.net
- mud grammar Jon A. Lambert
- mud grammar claw@null.net
- mud grammar Nathan Yospe
- mud grammar coder@ibm.net
- mud grammar Nathan Yospe
- mud grammar Chris Gray
- mud grammar claw@null.net
- EVOLUTION response claw@null.net
- EVOLUTION response Jon A. Lambert
- EVOLUTION response claw@null.net
- Garbage Collector Artur 'Revinor' Biesiadowski
- A perspective out of time - the mudreport document Nathan Yospe
- A perspective out of time - the mudreport document claw@null.net
- Old missing posts from old list coder@ibm.net
- Execution Chris Gray
- Mixture Furball
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Adam Wiggins
- Resets and repops (a really short post) claw@null.net
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) Nathan Yospe
- Resets and repops (a really short post) <= hah! Chris Gray
- VT100 codes ... Khanone@aol.com
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- VT102 codes Adam Wiggins
- Dupes coder@ibm.net
- Efficiency Chris Gray
- Event Handling Nathan Yospe
- Event handling Shawn Halpenny
- Event handling Vadim Tkachenko
- Event handling Maddy
- A brief introduction.. ok, you got me: an introduction Greg Munt
- A brief introduction.. ok, you got me: an introduction Adam Wiggins
- A brief introduction.. ok, you got me: an introduction coder@ibm.net
- Greetings. :) Michael Hohensee
- Greetings. :) claw@null.net
- Greetings. :) Nathan Yospe
- Greetings. :) Michael Hohensee
- Greetings. :) coder@ibm.net
- Greetings. :) Nathan Yospe
- Greetings. :) Chris Gray
- Greetings. :) coder@ibm.net
- Greetings. :) Chris Gray
- Greetings. :) Nathan Yospe
- Greetings. :) Jeff Kesselman
- Greetings. :) Chris Gray
- Greetings. :) Greg Munt
- Greetings. :) Jon A. Lambert
- Greetings. :) Nathan Yospe
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Furball
- Greetings. :) Chris Gray
- Greetings. :) clawrenc@xsvr1.cup.hp.com
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) Jeff Kesselman
- Greetings. :) Shawn Halpenny
- Greetings. :) Jon A. Lambert
- Greetings. :) clawrenc@cup.hp.com
- Greetings. :) Jeff Kesselman