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
- 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 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
[Nathan Y, on not reseting areas until PCs enter]
> : Scrying
> Again, this would create a local Player controlled bodyless Character
> manifestation, and adhere to the rules.
Well, the tricky part is:
> scry elven archwizard
When there is no such character in the game, since no PC has been by
to reset his area. I guess this would require a bit of extra code
to quickly search places that _could_ be reset, given the entrance of a PC,
and if so does anything that would be reseting answer to their scry?
No big deal, but I find any time you find yourself implementing a system
that requires 'a bit of extra' code to make a given world-feature work,
probably means it's going to take more bits of extra code elsewhere, and
it's easier to just do it For Real(tm). Of course if you've got
processor constraints then you have to make some concessions, I suppose.
Just pointing out the inherent difficulties in this sort of thing.
> : High altitude overview (for those with 3D)
> Occupied Areas get slow refreshes even in unoccupied Rooms. Anything
> covered by line of sight from a Player is operating full speed.
Yeah, agreed. When I mentioned the item-delay counter we have for
players 'interacting' with objects, viewing the object counts
as interaction. Meaning if you stand on a hill and watch the sword
stuck in the ground off in the distance, it will never disappear as long
as you keep it in your sight.
> : Remotely controlled/possessed mobiles.
> Sounds like a Player controlled Character to me.
I agree, although once again this is a gotcha to watch out for. Hopefully
your object display routine (which updates the "viewed by PC" info) is
set up in such a way that viewing something remotely (through the eyes
of another). That is...your display_obj routine has to be at the same
abstraction level as the "viewed by player" stuff, or otherwise how
will it know?
> : 'Bots.
> Player controlled.
Again, a gotcha. What if the bot has no display unit, only reports through
the remote its current position, speed, and bearing, as well as the size
and proximety of nearby objects? The display_obj routine above never
gets called; instead, it's a complex algorithm to diseminate the info
about local objects into basic information as reflected by the bot's
sensors, which is then pumped through a remote panel (which may or may
not be in the possesion of a player).
So, you'd have to have a pretty robust set of routines to be able to detect
that when a player is mind controlling a mobile 10 miles away, directing
it to a control panel from which it operates a bot located on a spaceship
orbiting the planet, you need to reset the stuff on the ship (since the
robot is viewing/manipulating it, which is sent through a convulted pipeline
to the remote control panel, which the mobile is viewing, which the character
can gain information about). Far-fetched, yes, but doing it the brute-force
way still works just fine in this situation, whereas you'd have to be pretty
careful to make the above work with a pop-on-view method.
> :Thusly you could have a mobile ctor which creates a baby/child and
> :launches an event stream which slowly "grows" the mobile from infancy
> :to old age and decrepitude, with any deaths along the way just leading
> :to the (semi-) randomly timed creation of new infants to take up the
> :progression.
>
> Hmmm. Never thought of the grow from an infant model... nah, too costly.
> I'll leave support, if anyone wants to do it with my code, but hardly
> needed for sci-fi.
Probably not really necessary or interesting for _any_ mud, but it does
solve some problems (like making 'resets' essentially unnecessary)
and brings in some interesting elements:
Ollihute the old human shopkeeper is here.
(next week)
A young, sandy-haired man is tending shop here.
You say, "Where's Ollihute?!"
A young, sandy-haired man introduces himself as Brendrik, son of Ollihute.
Brendrik says, "My father passed away this week.."
Just adds another layer of detail to absorb the player. This isn't terribly
relevant to gameplay, but it certainly brings a sense of humanity to your
mobiles if they are generated like humans instead of like clones on
an assembly line.
> :Handling minor details like closing opened doors, re-locking chests,
> :and resetting traps and the like is similarly handled, with the
> :secondary event either doing it directly ("A sudden strangely cold
> :breeze slams the dtor shut"), to the animation and trekking of a
> :work-horse mobile to the door/trap/whatever to reset it "manually" (cf
> :MirrorWorlds "man in a white lab coat")..
>
> Ugh. Lets just have it happen when no one is looking. Incidentally, I have
Agreed.
> explained my system to allow a Player to experience an Occurance, the
> results of which are permanent to that Player, and that Player alone,
> haven't I? Things like blowing up a complex or triggering a thermonuclear
> detonation can be coded to become a part of that Player's history, and
> that Area will forever after be a destroyed complex or glass lined crater
> to that Player's Characters... and anyone else that is introduced to the
> aftermath.
Eh...interesting. You mean by this that they didn't actually blow it up,
just thought they did? Or that you actually mean to maintain seperate
game-worlds this way? Either way could get messy, but I do like
the idea, in the first case:
The ugly troll massacres Bob on the neck.
Bob slumps to the ground, spouting blood!
You scream, "Agggh! Bob!!!"
The ugly troll turns toward you with a grin.
> flee
Later, you see:
Bob, who you thought was dead, is standing here.
It might be that it's Bob's specter/ghost returned from the grave, or that
he didn't actually die, or maybe that it's his son and just looks similar.
Hmmm. Interesting to store this sort of data along with the memory;
we do this to a certain extent right now, in that we store your relationship
with that person and the last state you saw them in, thus if someone shows
up with their beard shaved off you might not recognize them (this is handy
for wanted people, especially with the 'disguise' skill), and also you can
do the 'recall' command which has the dual affect of showing you what
you know about them and how you feel about them, plus shuffling their
memory node to the top of your list to make you less likely to forget them
due to memory-cleaning:
> recall bob
You think back to your memories of Bob the male human.
He sure is a good friend.
Suppose it wouldn't be too hard to toss in a clause for death or POW, ie:
You will miss him, and cherish his memory. R.I.P.
or
You wonder whatever happened to your good old pal Bob...
Amusing. Could even toss player notes onto a given memory, thus:
> note silke this asshole tried to steal my hat!
And later...
Silke has arrived from the north.
> ponder
> recall Silke
You seem to remember thinking, 'This asshole tried to steal my hat!'
> growl
Hmmm. Dang, that could be useful in real life:
A tall man approaches you.
A tall man says, "Adam! How's it going? Been a long time!"
> say uhh....
> recall man
You think really hard, trying to remember anything you can about the tall man.
Hmmm, you think his name might be "Phil."
> ' how's it going phil
Phil says, "Uh, it's 'Bill'."
> doh
> name phil bill
You will now call him 'Bill'.
> :You get into coding a full economy -- a thing rife with positive and
> :negative feedback loops (cf Palace's early economy mishaps and happy
> :accidents). Its something I don't think I'd even attempt. What I
> :think would be easier, and provide a LOT more fun, is to implement
> :independant economies with their own internal methods of production
> :and consumption which are not dependant on other economies.
>
> dangerous.
What are you guys, a bunch of pussies? All this high talk of
advanced programming and no one even wants to tackle an economy.
Next you're gonna tell me that writing mob AI that makes NPCs indistinguishable
from players is too hard. :)
> I like this! Consistant laws! (Which means it can be implemented in
> Physmud++!!)
I like constant laws because they're...uh...constant. Tends to make
it rather easy to say, "It's _always_ like this" as oposed to, "Well,
it's like this, except for these seven special cases..."
> Love your item names. Hmmm. A possibility: enchant an opponent's sword to
> destroy it? Or inconvenience the enemy, at the least. Or would it drain
> from you by proximity? That could be cool... an overenchanted sword that
> must feed off of magical prey constantly, or drain its owner dry. I can
> just see it.... here, unicorn, unicorn, unicorn.... my sword really wants
> to make your acquaintance!
Yeah, that's what's cool about a system like this - players, being as
clever as they are, will come up with tricks along these lines that you never
thought of when programming it, but still working perfectly within the system
(because it is all consistant). Not to mention I love concepts which
are neither good nor bad...they just _are_. What you want to make of
them is up to you as the player.
> :The nice thing about this sort of system is that it becomes self
> :balancing. Opportunities for mana consumption exceed mana production,
> :so the system always runs starved (try to run it fat and you get
> :positive feedback). While there can be synergy between the mana
> :economy and other economies, even positive and negative feedback
> :(again cf Palace and the guns and coins), you don't get the direct
> :causal dependancies where the stonemason can't build castles because
> :the lumberyard has no wood because the robbers robbed the bank so the
> :woodsman can't get paid for the trees he cut, and the elves can't sell
> :their silks anymore anyway (no money), and now pro0hibit all tree
> :cutting.
>
> I have to say, you guys create universes every bit as cool as my own. And
> killer bases for those universes. No wonder the newsgroups have decayed so
> much... we keep sapping out the talent.
Ha...I still read and post to r.g.m.*, mostly because they have pretty
low traffic anyways (especially when you cut out the spam with a nice
killfile or a quick next-message-key finger), but I do get tired of the
"Are you out of your MIND?!?!?" and "Why would anyone want to play any
mud that isn't exactly like all the ones that are existing right now?
You ought to quit wasting your time and just code yet another druid
class, or maybe C00L ANS1 C0L0RZ." - 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 Adam Wiggins
- 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