February 1998
- OT: Following in the footsteps of JCL Alex Oren
- OT: Following in the footsteps of JCL Nathan Yospe
- OT: Following in the footsteps of JCL Richard Woolcock
- OT: Following in the footsteps of JCL Chris Gray
- OT: Following in the footsteps of JCL coder@ibm.net
- OT: Following in the footsteps of JCL Marc Eyrignoux
- Ada? Andrew C.M. McClintock
- Monthly FAQ posting Koster, Raph
- Monthly FAQ posting Adam Wiggins
- Monthly FAQ posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Chris Gray
- Monthly FAQ Posting Ling
- Monthly FAQ Posting J C Lawrence
- Monthly FAQ Posting J C Lawrence
- Monthly FAQ Posting Alex Oren
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting s001gmu@nova.wright.edu
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling
- Monthly FAQ Posting Ling Lo
- Monthly FAQ Posting Koster, Raph
- Monthly FAQ Posting Ling Lo
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting Marian Griffith
- Monthly FAQ Posting Greg Miller
- Monthly FAQ Posting Ling Lo
- Databases Shawn Halpenny
- OT: This is a test coder@ibm.net
- OT: This is a test Alex Oren
- Clients and things [Was: OT: This is a test] Matt Chatterley
- Clients and things [Was: OT: This is a test] coder@ibm.net
- Clients and things [Was: OT: This is a test] Matt Chatterley
- MUD Development Digest Dr. Cat
- DBs and Events Greg Munt
- DBs and Events Nathan Yospe
- DBs and Events Greg Munt
- DBs and Events Nathan Yospe
- DBs and Events Felix A. Croes
- DBs and Events Jon A. Lambert
- DBs and Events coder@ibm.net
- DBs and Events s001gmu@nova.wright.edu
- DBs and Events Jon A. Lambert
- DBs and Events coder@ibm.net
- (subject missing) Ben Greear
- META: Unsubscribed users dur to bounces coder@ibm.net
- META: Unsubscribed users dur to bounces Adam Wiggins
- Source Code Release Greg Munt
- Source Code Release Ben Greear
- Source Code Release Greg Munt
- Source Code Release Ben Greear
- Source Code Release Greg Munt
- Source Code Release Richard Woolcock
- Source Code Release Ben Greear
- Source Code Release Chris Gray
- Source Code Release Greg Munt
- Source Code Release coder@ibm.net
- Source Code Release Richard Woolcock
- Source Code Release Stephen Zepp
- Source Code Release Jon A. Lambert
- Source Code Release Greg Munt
- Source Code Release Jon A. Lambert
- Source Code Release Greg Munt
- Source Code Release Travis Casey
- Source Code Release Jon A. Lambert
- Source Code Release Jon A. Lambert
- [RESEARCH]MUD articles archive (fwd) Greg Munt
- Socket programming (Was: The impact of the web on muds) Jon Leonard
- Socket programming (was: The impact of the web on muds) Vadim Tkachenko
- Socket programming (was: The impact of the web on muds) Richard Woolcock
- byte-code anyone? Chris Gray
- byte-code anyone? Jon Leonard
- byte-code anyone? Chris Gray
- byte-code anyone? Jon Leonard
- byte-code anyone? Chris Gray
- user-centered design (was Clients) Mike Sellers
- OT: Linux g++ Greg Munt
- OT: Linux g++ Ben Greear
- OT: Linux g++ coder@ibm.net
- OT: Linux g++ Shawn Halpenny
- OT: Linux g++ Chris Gray
- OT: Clients Vadim Tkachenko
- OT: Clients Adam Wiggins
- OT: Clients coder@ibm.net
- META: OS wars coder@ibm.net
- META: OS wars Mike Sellers
- Clients Stephen Zepp
- Clients Ling
- Clients Travis Casey
- Clients Katrina McClelan
- Clients Nathan F Yospe
On Tue, 17 Feb 1998, Katrina McClelan wrote:
Hi, Kat!
:On Tue, 17 Feb 1998, Travis Casey wrote:
:> Why? I mud from a variety of locations, and don't want to get used to
:> using an interface that I won't always be able to have. If that
:> interface can only be used on some muds, I'd be even less likely to
:> want to use it.
:That's one of my problems in general with clients and the issue of telnet
:is bad. I'll be the first to agree that telnet is a very silly protocol.
:However, it's supported on almost any platform without extra downloads or
:such. The solution I'd eventually use, and that I have mostly implemented
:is a [psuedo] terminal server, terminfo, and lib curses. Yes, curses CAN
:be used on multiple "terminals" from within the same program. I actually
:have the starts of a nethack like game over telnet for multiple players.
:I got bored with the whole thing (mostly because the game system was
:stupid; the project was more a matter of getting menus to work over telnet
:sockets than it was to have a good game), so I didn't finish it, but you
:could log in and go through a character creation sequence that was all
:menu driven. I suppose that curses limits features to text, but with full
:screen manipulation of it, it's still quite versitile. Particularly if
:you use ncurses and expect (partually dangerous) the the receiving client
:supports colors in some way or another (doesn't have to be vt100 with
:ncurses). The only real downside to this is character mode is required,
:and that sometimes locally handling text requires that you retransmit it.
:But if you're considering web based clients, character mode isn't THAT bad
::)
The real question is, do you want to support the client as well as the
server? There are a lot of "telnet" clients out there. Most suck. Most
players, now, are unfortunately servents of the Borg, and the MStelnet
is one of the worst. There are also a number of mud clients that don't
follow any sort of standard, and tend to cater to one of the big three
bases. So the options remain: Take your chances with telnet; Write the
client for M$ (and possibly a few other OS's); Write the client in the
form of a web extension; Write the client as a Java application... the
advantages and disadvantages of each are: Telnet really isn't that hot
a client; M$ is evil (and besides, there _are_ other OSs, and portable
code isn't as easy as it sounds); web extensions tend to bring in that
unspeakable element, and are slow to boot (even java applets); Java is
not the most stable or efficient language at the moment. As for what I
advocate... I chose the last option. I'm hoping Java1.1.x remains more
or less viable for a while to come, and counting on JITs and native or
optimizing recompilers, chunks of bottleneck code written in native on
the big three or so platforms (Solaris, MacPPC, PPC, and x86), and the
(hopeful) raw power of users' computers. I'm also releasing a hostable
version that runs in a unix csh, so that users can run it on accounts,
and thus get pretty close to the effect of a VT100 telnet interface. I
also have started working on a system for storing a datafile in a form
that is platform neutral, to be stored on a remote access account like
a .newsrc, allowing a player to run different copies of the client and
different machines at different locations with the same account setups
and the same characters. The problem is, this datafile is the core for
the neural net, and gets rather large. I anticipate sizes over 4MB, or
possibly larger... I'm hoping to find a way to store it by dated entry
modification files... The advantages to supporting a client is that it
becomes the repository for oft-repeated player by player computations,
data, and even communication, (I'm working on distributed hosting, and
the idea of interplayer message-only communication nodes appeals to my
sense of elegance in design, as does DCClike linkage between any pair,
or possibly even trio, of clients.) ... it can handle any protocol you
might need it to, (I'm creating my own data service protocols for both
alternate media (graphics and sound) and database updates (new regions
and materials, new behavior patterns, new models).) ... and it gives a
player the option of game related persistance beyond simple macros. If
I were to state one primary reason for supporting a client, however, I
would point to the massive text parsing effort of just about every mud
codebase I have seen. LP, Diku, Tiny*, or Cold, all use more cycles on
text parsing than anything else (OK, maybe not always, but generally.)
and none of them really even do anything fantastic with it. Now, where
I branched off was the generated text... and this almost demands a new
approach. What are the disadvantages to clients? Clients are not safe,
tucked away on the server. They can be hacked. They can be made to put
a programmer at an advantage in the game, if too much resides in them.
I really don't much care, as I see any hacking for smarter response as
advanced macro construction. ;) I don't have a typical mud, though, so
my lack of worry may be more a reflection of a mistaken belief in this
bulletproof solution to simulation. I don't think there is any data in
my model that can be recognized enough to be tweaked by a player for a
favorable balance through hacking, and not by any other means. The big
risk of a client, in my opinion, is that it tends to limit the changes
to the server, if not designed intentionally to maximum flexability. I
am extremely aware of this problem, and quite vulnerable. I expect the
client to be upgraded as often as the server, and only the datafile to
be secure, and even that not during the first couple of testing years.
--
Nathan F. Yospe - Aimed High, Crashed Hard, In the Hanger, Back Flying Soon
Jr Software Engineer, Textron Systems Division (On loan to Rocketdyne Tech)
(Temporarily on Hold) Physics student, University of Hawaii dept of Physics
yospe#hawaii.edu nyospe#premeir.mhpcc.af.mil http://www2.hawaii.edu/~yospe/ - Clients Chris Gray
- Clients coder@ibm.net
- Clients Nathan F Yospe
- Clients Greg Munt
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) Adam Wiggins
- Moore's Law sucks (was: 3D graphics) Chris Gray
- Moore's Law sucks (was: 3D graphics) coder@ibm.net
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) Mike Sellers
- Moore's Law sucks (was: 3D graphics) Chris Gray
- Moore's Law sucks (was: 3D graphics) Ben Greear
- Moore's Law sucks (was: 3D graphics) Ling
- Moore's Law sucks (was: 3D graphics) Brandon J. Rickman
- Moore's Law sucks (was: 3D graphics) coder@ibm.net
- Moore's Law sucks (was: 3D graphics) Alex Oren
- Version Control (was: DBs and Events) Vadim Tkachenko
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Vadim Tkachenko
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Jon A. Lambert
- Version Control (was: DBs and Events) s001gmu@nova.wright.edu
- Version Control (was: DBs and Events) Raph & Kristen Koster
- Version Control (was: DBs and Events) coder@ibm.net
- Version Control (was: DBs and Events) Felix A. Croes
- Net protocols for MUDing (was: Moore's Law sucks) Jon Leonard
- Net protocols for MUDing (was: Moore's Law sucks) coder@ibm.net
- Net protocols for MUDing (was: Moore's Law sucks) s001gmu@nova.wright.edu
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Caliban Tiresias Darklock
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Vadim Tkachenko
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- Net protocols for MUDing (was: Moore's Law sucks) Chris Gray
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) Ben Greear
- Net protocols for MUDing (was: Moore's Law sucks) Adam Wiggins
- Net protocols for MUDing (was: Moore's Law sucks) s001gmu@nova.wright.edu
- Net protocols for MUDing (was: Moore's Law sucks) Jon A. Lambert
- Net protocols for MUDing (was: Moore's Law sucks) J C Lawrence
- VEIL (was: Clients) Brandon Gillespie
- LDMs (large dynamic maps) was Unique items Mike Sellers
- Describing the environment Stephen Zepp
- Describing the environment Richard Woolcock
- Back on the list Niklas Elmqvist
- Back on the list Chris Gray
- Back on the list coder@ibm.net
- Unique items The Eternal City
- Unique items coder@ibm.net
- Position sorting Adam Wiggins
- Position sorting coder@ibm.net
- Unique items coder@ibm.net
- Unique items Nathan F Yospe
- BOOK: Myer's Silverlock coder@ibm.net
- BOOK: Myer's Silverlock Chris Gray
- BOOK: Myer's Silverlock Adam Wiggins
- Dynamic Loading of Modules (was: Back on the list) Niklas Elmqvist
- Dynamic Loading of Modules (was: Back on the list) Vadim Tkachenko
- Dynamic Loading of Modules (was: Back on the list) J C Lawrence
- Dynamic Loading of Modules (was: Back on the list Jon A. Lambert
- Net protocols for MUDing s001gmu@nova.wright.edu
- Net protocols for MUDing Stephen Zepp
- Net protocols for MUDing Chris Gray
- Net protocols for MUDing Adam Wiggins
- Net protocols for MUDing J C Lawrence
- Net protocols for MUDing Shawn Halpenny
- Net protocols for MUDing J C Lawrence
- Net protocols for MUDing Chris Gray
- Dynamic Loading of Modules Niklas Elmqvist
- Senses (was: The MLI Project) s001gmu@nova.wright.edu
- bar-time (was The MLI Project) Mike Sellers
- 3D engines for MUDs (was: The MLI Project) Niklas Elmqvist
- 3D engines for MUDs (was: The MLI Project) J C Lawrence
- 3D engines for MUDs (was: The MLI Project) Michael Hohensee
- 3D engines for MUDs (was: The MLI Project) Miroslav Silovic
- 3D engines for MUDs (was: The MLI Project) Michael Hohensee
- Why not compile java into object code? Ben Greear
- Why not compile java into object code? Cynbe ru Taren
- Why not compile java into object code? Caliban Tiresias Darklock
- Why not compile java into object code? Nathan F Yospe
- Why not compile java into object code? Niklas Elmqvist
- Why not compile java into object code? Ben Greear
- Why not compile java into object code? Jon A. Lambert
- Why not compile java into object code? Travis Casey
- Why not compile java into object code? Chris Gray
- Tutorial: Comments on Hand-crafting a compiler Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part I: Introduction Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part II: Expression Parsing Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part I: Introductio Chris Gray
- Tutorial: Let's build a Compiler! - Part I: Introductio s001gmu@nova.wright.edu
- Tutorial: Let's build a Compiler! - Part I: Introductio coder@ibm.net
- MUD Development Digest Dr. Cat
- MUD Development Digest Koster, Raph
- MUD Development Digest Mike Sellers
- Tutorial: Let's build a Compiler! - Part III: More Expressions Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part IV: Interpreters Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part V: Control Constructs Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VI: Boolean Expressions Jon A. Lambert
- Tutorial: Let's build a Compiler! - Comments Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VII: Lexical Scanning Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part VIII: A Little Philosophy Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part IX: A Top View Jon A. Lambert
- Tutorial: Let's build a Compiler! - Part X: Introducing TINY Jon A. Lambert
- Compilers: Toy available for ftp Chris Gray