December 1998
- Hex-grid mapping Matthew R. Sheahan
- Hex-grid mapping Jon Leonard
- Hex-grid mapping James Wilson
- Hex-grid mapping Jon Leonard
- Hex-grid mapping James Wilson
- Hex-grid mapping Par Winzell
- Hex-grid mapping quzah [sotfhome]
- Hex-grid mapping Nathan F Yospe
- Hex-grid mapping Ling
- Hex-grid mapping Jon A. Lambert
- Hex-grid mapping Nathan F Yospe
- Hex-grid mapping Alberto Barsella
- Hex-grid mapping (example from PSL empire) Pericolo DiMorte
- Hex-grid mapping (example from PSL empire) Nathan F Yospe
- Hex-grid mapping (example from PSL empire) quzah [sotfhome]
- Hex-grid mapping (example from PSL empire) Pericolo DiMorte
- Hex-grid mapping (example from PSL empire) James Wilson
- ADMIN: Personalities... J C Lawrence
- Hex-grid mapping (fwd) Nathan F Yospe
- Hex-grid mapping (fwd) J C Lawrence
- Electric Communities' E Ola Fosheim Grøstad
- Electric Communities' E Ola Fosheim Grøstad
- mud client development systems Sunny Gulati
- mud client development systems Caliban Tiresias Darklock
- mud client development systems Chris Gray
- mud client development systems greear@cyberhighway.net
- mud client development systems Sunny Gulati
- mud client development systems Benjamin D. Wiechel
- mud client development systems Sunny Gulati
- mud client development systems J C Lawrence
- mud client development systems Per Vognsen
- mud client development systems Sunny Gulati
- mud client development systems Scatter
- mud client development systems Per Vognsen
- mud client development systems Chris Gray
- mud client development systems Jon Leonard
- mud client development systems Bruce Mitchener, Jr.
- mud client development systems Sunny Gulati
- mud client development systems Chris Gray
- Stack-Based NPC AI Eli Stevens {KiZurich}
- Stack-Based NPC AI Mark Gritter
- Stack-Based NPC AI Marc Hernandez
- Stack-Based NPC AI Richard Woolcock
- Stack-Based NPC AI Par Winzell
- Stack-Based NPC AI David Bennett
- Stack-Based NPC AI Mik Clarke
- Stack-Based NPC AI Felix A. Croes
- Introduction Mik Clarke
- Introduction Adam J. Thornton
- Introduction Mik Clarke
- Introduction ApplePiMan@aol.com
- Introduction Mik Clarke
- Thought Treasure Adam Wiggins
- Netscape's "Gecko" Browsing Engine (fwd) Nathan F Yospe
- Netscape's "Gecko" Browsing Engine (fwd) Adam Wiggins
- Netscape's "Gecko" Browsing Engine (fwd) Bruce Mitchener, Jr.
- Netscape's "Gecko" Browsing Engine (fwd) greear@cyberhighway.net
- Error tolerant UDP data streams J C Lawrence
- Error tolerant UDP data streams James Wilson
- Error tolerant UDP data streams J C Lawrence
- Error tolerant UDP data streams Ola Fosheim Grøstad
- ADMIN: (IMPORTNANT) Server down time and possible service interruption J C Lawrence
- [DevMUD] Error tolerant UDP data streams Darren Henderson
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) Benjamin D. Wiechel
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) Michael Willey
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Caliban Tiresias Darklock
- MUD Design doc (long) Thinus Barnard
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Adam Wiggins
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Ling
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis Casey
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Travis S. Casey
- MUD Design doc (long) Caliban Tiresias Darklock
- MUD Design doc (long) Marian Griffith
- MUD Design doc (long) Koster, Raph
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Sunny Gulati
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Benjamin D. Wiechel
- MUD Design doc (long) J C Lawrence
- MUD Design doc (long) Nathan F Yospe
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Emil Eifrem
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Mik Clarke
- MUD Design doc (long) Chris Gray
- MUD Design doc (long) Caliban Tiresias Darklock
- Hex grids. quzah [softhome]
- small dev-mud invite Chris Gray
- small dev-mud invite J C Lawrence
- mud client development systems Sunny Gulati
Wow. You folks are all amazing. I'm getting more feedback than I have
bandwidth to investigate thoroughly :)
Many thanks to Scatter for his/her pointer towards MudOS's ability to do
a secondary raw binary port built in to the mudlib. That's #1 on my
list to check out. And I'm going to take a peek at Chris Gray's socket
code.. that's #2.
Going to let my mind wander some more...
I was talking to a friend (I don't remember who) (in real life) (I think
it was my boss, AlanS@E-Markets.com), and he said:
"Sounds like you're trying to implement CORBA on a mud".
I *think* I know what CORBA is about, but its still fuzzy in my head.
Seen too many vague marketing things on it, and too many C-library
implementations of it that already assume you know what its about. I'm
doing a search on CORBA on the archives for this mailing list, see what
I can find..
oh my. the CORBA search returned a TON of stuff! I'll go read it before
I ask more.
-*-
More dreamy stuff:
Talking to another friend Steve (wells@cedarnet.org), and he was
interested in doing some Perl/GTK or Java client-side coding if I got my
ideas along far enough. This got me thinking, on the 2 hour drive back
from his place.. he wants to play, but its not the same place that I am
looking at playing... I want to do Perl/Tk (just because)... and Matt
Messier, another friend, would want to work in C++..
-> i wonder if I can make my client side objects language independent?
I mean, if Steve likes Perl, he can write a client in perl, and the
mudclient in question can still use it, even if its written in... uhhh..
picking shocking language.. uh.. COBOL! :)
-> Obviously, it would have to run in a seperate process. Need to
communicate back to the master client program (which has the connection
back to the mud). How should I do this?
Three ideas:
a) redirecting stdin/stdout/stderr - ie, i start the program in a
"subprocess", and I control its stdin, and I receive its stdout and
stderr. I know Java + Perl both do this, and I'm sure getting C to do
it wouldn't be too hard, just gotta find the right examples :)
b) named pipes (how portable are they? does Win95 have them? )
c) some sort of socket IPC stuff (how much cross-language support is
there? how about on Win95?)
-> How does that affect my idea of "addressing" between clients and
servers? Here's a harebrained idea I got during my drive back:
On the mud, the server, having established we're dealing with a neato
client, wants to pop up a window on the server for chat messages.
It calls a function to open a client-side-object of
type("instance/window/chat"), and passes a second function to call
whenever that happens (or dies).
the mud sends this connection request as a method call to the
client-side kernel object.
the client-side kernel object (written in Perl, for this example) looks
up its internal registry, to see who all can handle
"instance/window/chat" objects. It finds that the Java object handler
says it can handle it.. so it passes the request on to the Java object
handler (which is tied through stdin/stdout or a named pipe or
something).
The Java handler looks at its own configuration, finds the java object
it needs to new(), does that, returns the identifying info back to the
main client-side-kernel object, which sends that back to the mud.
Which informs whoever that the client came up, and gives them their own
mud-side chat object to talk to.
Benefit:
-> you can write a client in any language, as long as there's a
switchboard (ORB?) object for your language.
-> the distinction between protocol and client object is very distinct.
Each client object registers the ability to handle particular
protocols. Requests for services are along the lines of protocols.
-> Instanceable objects vs Static, one-copy-only objects. Note that I
said:
instance/window/chat
meaning that this is an object that you create instances of (multiple
copies), it creates a window, and its a chat object.
Other types could be url-handlers (static/url/http, static/url/lib)
which provide the user kernel methods of retrieving data. These are not
"tieable" objects.
Hmm.. rephrase this:
-> There are tied objects between client-side and mud-side
-> There are objects local to the client side
-> There are objects local to the server side (can't think of any
yet.. maybe an auth server?)
and
-> There are objects which there's only one copy of (like local
library looker-uppers)
-> There are objects which need to be cloned/instanced
That's two dimensions. I wonder if there are any others.
Drawback:
uhh.. lots of client side objects running around killing the user's
CPU. # of filehandles limits.
gotta install client objects into your system if you want the additional
functionality.
lots of chaos!
Note that I seem to be thinking about using stdin/stdout "wrapping" of
one process to another process to cross language boundaries. I guess
that this is pretty expensive. It would seem that languages that are
dynamic (Perl, Java) regarding compiling code on the fly and creating
new objects would be able to keep these sorts of expensive boundary
jumps to a minimum.
Back to the quesiton of how would I identify stuff? I was initially
thinking of something like how routed and the internet do stuff.. then I
thought the object identification could specifically describe the path
to get to it. Like:
.link. could be the telnet link (okay okay socket connection
between client and mud)
left side is client, right side is server
switcher.link is the main switcher object. Its written in perl,
for example
chat.switcher.link is the chat thingy written in perl (lives
directly off the switcher)
5.chat.switcher.link is the particular instance that we're
talking to.
java.switcher.link is the java handler
198.java.chat.switcher.link is the java instance of a chat
handler.
Wow, that's way too long to be useful. Maybe some sort of unique number
could be arbitrated? (ugh). Then again, it doesn't need to be human
readable - could just have:
198.3.45.1.0
and each handler internally knows how to dereference one more number.
So a message from/to on the server could look like:
from: 43 to: 0.68.34
0 references the link between mud and client, so that gets dereferenced
and sent over as:
from: 43 to: 68.34 (over the link)
On the other side of the link, the object there happens to call the link
0 as well:
from: 0.43 to 68.34
It looks up 68, and finds the java handler object. So it sends the
message down the pipeline to the java handler. While in the pipe, the
message looks like:
from: 0.43 to 34
The java handler grabs this, and dereferences object 34 to be the chat
window. Its linkage upstreams is 0. It sends it directly to the chat
object (since we're talking the same language and all), and there the
message becomes:
from 0.0.43 to [me]
Conceivably, one could have one client talk directly to another client
through the mud. (just like that MCP client program did with its draw
stuff).
-*-
I seem to have stabilized around the following kind of messaging
options:
Message = send a message, expect no response.
Query = send a message, expect response.
Reply = reply to a query (references a message id#)
Replyuery = reply to a query (references a message id#), expects a
response
For more details, I've posted the various braindumps i've done at:
<URL:http://www.radiks.net/~sunnywiz/epcs>
That's not including the ruminations above.
Sunny - mud client development systems Jay Carlson
- mud client development systems J C Lawrence
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Jon Leonard
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Mik Clarke
- AFAP: As fast as possible, non linear... Alex Oren
- AFAP: As fast as possible, non linear... Dan Shiovitz
- AFAP: As fast as possible, non linear... Mik Clarke
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... quzah [softhome]
- AFAP: As fast as possible, non linear... Greg Connor
- AFAP: As fast as possible, non linear... quzah [softhome]
- Graphic design, client questions Thinus Barnard
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions Jo Dillon
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions Jo Dillon
- Graphic design, client questions Thinus Barnard
- Graphic design, client questions Sunny Gulati
- Graphic design, client questions J C Lawrence
- Graphic design, client questions Caliban Tiresias Darklock
- Graphic design, client questions J C Lawrence
- Graphic design, client questions J C Lawrence
- Graphic design, client questions Jay Carlson
- Graphic design, client questions Ben Greear
- More Laws, was DIS: Client-Server vs Peer-to-Peer Koster, Raph
- More Laws, was DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
- More Laws, was DIS: Client-Server vs Peer-t o-Peer Koster, Raph
- More Laws, was DIS: Client-Server vs Peer-t o-Peer J C Lawrence
- More Laws Niklas Elmqvist
- More Laws J C Lawrence
- Re[2]:MUD Design doc (long) Michael Willey
- Re[2]:MUD Design doc (long) Adam Wiggins
- Re[2]:MUD Design doc (long) Caliban Tiresias Darklock
- Re[2]:MUD Design doc (long) J C Lawrence
- Re[2]:MUD Design doc (long) Sunny Gulati
- Re[2]:MUD Design doc (long) quzah [softhome]
- Re[2]:MUD Design doc (long) David Bennett
- Re[2]:MUD Design doc (long) quzah [softhome]
- Some useful links Niklas Elmqvist
- Response (Was MUD Design doc (long)) Ola Fosheim Grøstad
- Response (Was MUD Design doc (long)) Chris Gray
- Response (Was MUD Design doc (long)) J C Lawrence
- example custom protocol and its uses Chris Gray
- client stuff... Andrew Wilson
- Developing a MUD for the first time? Alex Oren
- Re[2]:MUD Design doc (long) J C Lawrence
- [DevMUD] Database module J C Lawrence
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module J C Lawrence
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module T. Alexander Popiel
- [DevMUD] Database module Jay Carlson
- [DevMUD] Database module cynbe@muq.org
- [DevMUD] Database module Felix A. Croes
- Re[2]:MUD Design doc (long) Caliban Tiresias Darklock
- [RRE]AAAI 1999 Fall Symposium: Narrative Intelligence Bruce Mitchener, Jr.
- (fwd) DESIGN: Proposed topic of Discussion (Injecting Pure Signal) J C Lawrence
- Terragen Vadim Tkachenko
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Bobby Bailey
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Robin Carey
- [RELEASE] Insanity To Infinity (I:I_OS) v.01a Bobby Bailey
- META: 1998 Topic Summary Jon A. Lambert
- [RELEASE] Insanity To Infinity (I:I_OS) v.02a Bobby Bailey
- ADMIN: New text formatting rule for MUD-Dev J C Lawrence
- More Laws Jon A. Lambert
- More Laws Travis Casey
- MUD Design doc - Combat Jon A. Lambert
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat cynbe@muq.org
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat quzah [softhome]
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat T. Alexander Popiel
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Adam Wiggins
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat quzah [softhome]
- MUD Design doc - Combat Dr. Cat
- MUD Design doc - Combat T. Alexander Popiel
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat J C Lawrence
- MUD Design doc - Combat James Wilson
- MUD Design doc - Combat Nathan F Yospe
- MUD Design doc - Combat James Wilson
- MUD Design doc - Combat Nathan F Yospe
- MUD Design doc - Combat diablo@best.com
- MUD Design doc - Combat Kristen Koster
- MUD Design doc - Combat Chris Gray
- MUD Design doc - Combat Scatter
- MUD Design doc - Combat Koster, Raph
- MUD Design doc - Combat Kristen Koster
- MUD Design doc - Combat Caliban Tiresias Darklock
- MUD Design doc - Combat T. Alexander Popiel
- Levels versus Skills, who uses them and when. Till Eulenspiegel
- Levels versus Skills, who uses them and when. Travis Casey
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Ling
- Levels versus Skills, who uses them and when. Till Eulenspiegel
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Justin Robinson
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Alex Oren
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Matt Wallace
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Andy Cink
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Marian Griffith
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Koster, Raph
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Holly Sommer
- Levels versus Skills, who uses them and when. Adam Wiggins
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. Matt Wallace
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. D. B. Brown
- Levels versus Skills, who uses them and when. Mik Clarke
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Vladimir Prelovac
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. Nathan F Yospe
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Jon A. Lambert
- Levels versus Skills, who uses them and when. Travis S. Casey
- Levels versus Skills, who uses them and when. Caliban Tiresias Darklock
- Levels versus Skills, who uses them and when. J C Lawrence
- Levels versus Skills, who uses them and when. Petri Virkkula