August 1998

• Affordances and social method (Was: Wired Jon A. Lambert
• (Fwd) **NOTICE REGARDING YOUR SEARCHLIGHT SOFTWARE** Jon A. Lambert
• • (Fwd) **NOTICE REGARDING YOUR SEARCHLIGHT SOFTWARE** John Bertoglio
  • • (Fwd) **NOTICE REGARDING YOUR SEARCHLIGHT SOFTWARE** Caliban Tiresias Darklock
• OT: BBSs, s001gmu@nova.wright.edu
• Ansii color, needing some specs and or pointer Jon A. Lambert
• • Ansii color, needing some specs and or pointer Caliban Tiresias Darklock
• (fwd) "Smart" monsters Nathan Fenenga Yospe
• Interesting poll Koster, Raph
• • Interesting poll John Bertoglio
• Milgram experiment (was WIRED: Kilers have more fun) Mike Sellers
• Implementing god. quzah
• • Implementing god. Adam J. Thornton
  • • Implementing god. J C Lawrence
    • • Implementing god. Adam J. Thornton
      • • Implementing god. Koster, Raph
        • • Implementing god. Adam J. Thornton
          • • Implementing god. Koster, Raph
        • Implementing god. J C Lawrence
        • • Implementing god. Marian Griffith
          • • Implementing god. Adam J. Thornton
            • • Implementing god. Andy Cink
• Blender: free version J C Lawrence
• Blender: free version J C Lawrence
• • Blender: free version Adam Wiggins
• UOL/Linux client URLs J C Lawrence
• Socket-Script: Socket-capabable script language and matching library J C Lawrence
• • Socket-Script: Socket-capabable script language and matching library Adam J. Thornton
  • • Socket-Script: Socket-capabable script language and matching library J C Lawrence
  • Socket-Script: Socket-capabable script language and matching library Chris Gray
  • Socket-Script: Socket-capabable script language and matching library Chris Gray
  • • Socket-Script: Socket-capabable script language and matching library Oliver Jowett
  • Socket-Script: Socket-capabable script language and matching library Adam J. Thornton
  • • Socket-Script: Socket-capabable script language and matching library Nathan F Yospe
    • • Socket-Script: Socket-capabable script language and matching library Adam J. Thornton
    • Socket-Script: Socket-capabable script language and matching library ##Make Nylander
    • • Socket-Script: Socket-capabable script language and matching library Adam J. Thornton
  • Socket-Script: Socket-capabable script language and matching library Ola Fosheim Grøstad
  • • Socket-Script: Socket-capabable script language and matching library J C Lawrence
• Why threading? (Was: Output Classification Notes) Ola Fosheim Grøstad
• • Why threading? (Was: Output Classification Notes) J C Lawrence
• Secrets of the Game Designers s001gmu@nova.wright.edu
• 3D World Models Leach, Brad BA
• • 3D World Models S. Patrick Gallaty
• Toba Java->C Adam J. Thornton
• [IDEAS] Starting from scratch Franklyn Colebrooke, Jr.
• • [IDEAS] Starting from scratch Adam J. Thornton
  • [IDEAS] Starting from scratch Hans-Henrik Staerfeldt
  • • [IDEAS] Starting from scratch Adam Wiggins
  • [IDEAS] Starting from scratch Leach, Brad BA
  • • [IDEAS] Starting from scratch T. Alexander Popiel
    • [IDEAS] Starting from scratch Adam Wiggins
    • [IDEAS] Starting from scratch J C Lawrence
  • [IDEAS] Starting from scratch Ross Nicoll
  • • [IDEAS] Starting from scratch T. Alexander Popiel
    • • [IDEAS] Starting from scratch Holly Sommer
      • • [IDEAS] Starting from scratch T. Alexander Popiel
        • • [IDEAS] Starting from scratch Nathan F Yospe
          • [IDEAS] Starting from scratch Holly Sommer
          • • [IDEAS] Starting from scratch T. Alexander Popiel
    • [IDEAS] Starting from scratch s001gmu@nova.wright.edu
    • [IDEAS] Starting from scratch Matt Chatterley
  • [IDEAS] Starting from scratch Ross Nicoll
  • [IDEAS] Starting from scratch Ross Nicoll
  • [IDEAS] Starting from scratch Ross Nicoll
  • • [IDEAS] Starting from scratch J C Lawrence
  • [IDEAS] Starting from scratch J C Lawrence
  • • [IDEAS] Starting from scratch Adam Wiggins
      On Thu, 10 Sep 1998, J C Lawrence wrote:
      > Franklyn Colebrooke,<colebrookef@post.uwstout.edu> wrote:
      > > The idea I have in mind is to create a server that robust
      > > enough to do several things: 1. maintain quality connections with
      > > players in such a manner that it will actively ping the players and
      > > drop anyone within the admin's described margins. If not drop them,
      > > then to put them on a holding queue until the connection improves.
      >
      > Translation: Attempt to handle network lag and latency in an
      > intelligent manner.
      
      This is a tough one. In the end, having a slow connection will suck for
      the client, no matter what you do. But there are a few neat tricks which
      can alliviate their misery a small bit.
      
      > There are a whole lot of possible approaches, all with trade-offs.
      > One of the old standards is using dead recking and other predictive
      > algorithms to update client displays with where other objects are
      > likely to be along with what they are likely to be doing (much tougher
      > -- definite AI candidate). This allows the frequency and accuracy of
      > inter-client updates to fall without (significantly) impacting the
      > perceived responsiveness of the game.
      >
      > The problem of course are the "jumps" when the predicted states are
      > resolved against the actual states (eg local client lags, predicts
      > motions of other options, comes out of lag and finds that its
      > predictions were not accurate, ditto for remote clients and your
      > perception of them). NB This bas heeb discussed (briefly) in the
      > archives along with such concepts as how to resolve critical events
      > (does a missile impact an enemy ship or not when the position of both
      > is possibly predictive), and with the use of non-error correcting
      > protocols to allow cheap fail-overs and predictive kick-in for lost
      > frames.
      
      ...in effect, the code the client is running is very similar, perhaps
      identical, to that the server is running - it just knows a lot less about
      the game world, and always defers to the server in case of disagreement.
      
      > But, getting back to your prorposal of degrading the player's state in
      > the game world dependant on the state of his net connection: You're
      > asking for trouble. Not technically mind you, but socially. Players
      > will notice the feature, will come to rely on it, and will then find
      > it doesn't work. Why doesn't it work? Its unreliable. Latency
      > changes are highly transitory and typically have extremely sharp
      > corners (ie they don't build up or fall down slowly -- they're
      > typically instant on/off situations, square waves as it were). This
      > means that unless your sample happens to hit during the event you
      > won't detect it. This also means you either sample with a very high
      > frequency (and drown those on slow connections and cause your own lag
      > conditions thru bandwidth consumption) or sample infrequently and
      > accept fairly bad average cases of undetected lag.
      
      I think you can choose sample times which will get you enough information
      to work with: ie, if a certainly player has consistantly getting sharp
      connection hangups which last multiple seconds with no packet
      comminucation whatsoever, the game could choose to not let them into a
      high-speed area (say, a quake-style arena), or it could be as simple as a
      lag-o-meter that the player can check. That is to say, in a text mud
      people have a very good feel for their connection, sine they see the
      content of the packets arrive directly. Frequently people will say, "No,
      I don't want to go to high-level area X right now...I'm lagging too hard
      and will probably get into trouble." In a game which is translating
      packets into more subtle data and doing motion prediction, the game
      continues to run at 30fps even when there are no packets coming in. Thus
      the player doesn't have a feel for what kind of lag they are in until they
      start shooting at things and missing because they aren't where they think
      they are.
      
      > Further, the main "lag" problem with telnet-based MUD clients
      > (actually with TCP based clients) is not actually lag. Its dropped
      > packets. The old classic of the telnet session hanging for several
      > seconds before "coming back to life" is not caused by lag (ie high
      > ping time) but by one of the telnet packets being lost en route, the
      > protocol having to wait until timeout, and the packet to be resent
      > (successfully). During this whole time the average ping time between
      > the ends can approximate 0ms.
      >
      > Translation: The problem is in TCP, not in 'net routing and traffic
      > storms. Your problem is to decide whether or not data correctness (no
      > dropped or lost packets) is more important than responsiveness, or
      > even whether you can't multiplex your data connections and
      > multi-thread your state machines to asynchronously accept updates from
      > your data connections and thus allow your data connections to rely on
      > TCP error correction.
      
      I was futzing around with UDP a few months back after chatting with some
      folks about it at CGDC. IMO as soon as you go to a non-text based system
      where packets are more of an object-update style, UDP can solve a lot of
      problems for you. I doesn't guarentee in-order devivery, or even delivery
      at all. However, in a realtime simulation, you could care less about
      where an object was ten seconds ago - what you care about is where it is
      *now*, and waiting for the old packets that didn't make it to get resent
      is a waste of time. Consider:
      
      Buffy is flying her sandskimmer due east across the desert.
      Boffo is observing.
      Buffy veers to the left.
      Server sends a packet to Boffo to indicate Buffy's new position and
      direction of motion.
      On the way to Boffo's machine, the server's update packet about Buffy's
      position gets hung up.
      Buffy veers to the right.
      Server sends a new packet with Buffy's new position and direction of
      motion.
      
      At this point neither the client nor the server cares about that hung-up
      packet making it through; but with TCP, you have to wait for it. With UDP
      you can just forget about it.
      
      This, of course, assumes that the objects complete state is stored in each
      packet. If packets are more like state deltas (ie, "I just turned left",
      "I just moved forward") this won't work.
      
      Although this isn't terribly useful for a traditional text-based mud, you
      could probably still get some net optimization with a custom client using
      UDP, doing its own ack'ing. Sending messages in packet-sized chunks with
      predictable id numbers (ie, each one is the previous id + 1), you could
      avoid the massive resending you get with TCP when the net gets hung up,
      since TCP actually restarts at the first unacked byte. If you packetized
      it, you could queue up a set of received messages until ever message up to
      a certain number has been received.
      
      For example:
      
      Server fires messages 1, 2, 3, 4, 5 and 6 to the client.
      
      Client receives messages 1, 4, and 5. It sends a status message to the
      server indicating it has recieved messages 2 - 3 and the highest message
      it has received is 5. It outputs message 1 to the player and queues up 4
      and 5.
      
      Server resends 2 and 3.
      
      Client receives 2 and 3 and outputs them to the user, along with 4 and
      5 (since all the intervening packets have been resolved).
      
      Server times out (highest packet received == 5, highest packet sent =6) and resends message 6.
      
      
      I doubt this would be worthwhile if you're doing straight text, since
      distribution a telnet which looks effectively just like telnet (to the
      user) and works only with your mud and only for the platforms you happen
      to have access to would be a big deterent from people playing your game.
      But if you already have a client which is largely based on scrolling text
      (such as that old TSN game, Shadow of Yserbius), you might as well.
      
      > > 2. I would like to be able to attach muds to the server as nodes.
      >
      > Why not run a simple front-end daemon which mrely accepts connections
      > and then in turn opens connections to the actual MUD server via
      > streams or some other high-speed low-overhead IPC mechanism? This way
      > the MUD can go down for whatever reason, come back up, poll the
      > front-end, and re-establish all its connections transparently.
      
      I recommend an archive search for "Armageddon" and "uncrashable".
      
      > I'll leave the questions of retaining or regenerating server and
      > character state across such re-connects to you or a lter discussion.
      
      Also mentioned in the "uncrashable mud" thread.
      
      > > I've also had ideas of having the mud itself have the basics(number
      > > of levels, max players, number of races, etc) be read from an ini
      > > file.
      >
      > What possible advantage dores working from an INi file give you over
      > any other data storage format?
      
      I assume he meant a generic initialization file of some sort, the actual
      format is probably not terribly relevant.
      
      Adam
• Question regarding Java threads Jon A. Lambert
• • Question regarding Java threads Chris Gray
  • • Question regarding Java threads Vadim Tkachenko
    • • Question regarding Java threads Ben Greear
    • Question regarding Java threads J C Lawrence
  • Question regarding Java threads Ben Greear
  • • Question regarding Java threads Jon A. Lambert
  • Question regarding Java threads Chris Gray
  • Question regarding Java threads Matt Chatterley
  • • Question regarding Java threads Ben Greear
• Protocols Vadim Tkachenko
• Events s001gmu@nova.wright.edu
• after the plague: mud report S. Patrick Gallaty
• • after the plague: mud report quzah
  • • after the plague: mud report Adam Wiggins
    • after the plague: mud report Ling
• Object Storage Fact Book, Release 4.0 (fwd) Nathan F Yospe
• Affordances and social method (Was: Wire d Magazine...) J C Lawrence
• META: List combat character and racial memory (was Re: J C Lawrence
• • META: List combat character and racial memory (was Re: kamikaze@kuoi.asui.uidaho.edu
  • • META: List combat character and racial memory (was Re: J C Lawrence
• Black Isle's Baldur's Gate J C Lawrence
• • Black Isle's Baldur's Gate Koster, Raph
  • Black Isle's Baldur's Gate Chris Gray
  • Black Isle's Baldur's Gate Koster, Raph
• 208.240.161.41 Adam J. Thornton
• • 208.240.161.41 Vadim Tkachenko
• ADMIN: Advertising on MUD-Dev J C Lawrence
• • ADMIN: Advertising on MUD-Dev Chris Gray
  • • ADMIN: Advertising on MUD-Dev Caliban Tiresias Darklock
    • • ADMIN: Advertising on MUD-Dev Ola Fosheim Grøstad
      • ADMIN: Advertising on MUD-Dev J C Lawrence
    • ADMIN: Advertising on MUD-Dev Vadim Tkachenko
    • • ADMIN: Advertising on MUD-Dev Adam Wiggins
      • • ADMIN: Advertising on MUD-Dev Robert Woods
        • ADMIN: Advertising on MUD-Dev Richard Woolcock
        • • ADMIN: Advertising on MUD-Dev Jeroen Ruigrok/Asmodai
          • • ADMIN: Advertising on MUD-Dev quzah
            • ADMIN: Advertising on MUD-Dev Richard Woolcock
            • • ADMIN: Advertising on MUD-Dev Jeroen Ruigrok/Asmodai
  • ADMIN: Advertising on MUD-Dev T. Alexander Popiel
  • ADMIN: Advertising on MUD-Dev Mike Sellers
  • • ADMIN: Advertising on MUD-Dev J C Lawrence
  • ADMIN: Advertising on MUD-Dev Michael Hohensee
  • • ADMIN: Advertising on MUD-Dev s001gmu@nova.wright.edu
    • • ADMIN: Advertising on MUD-Dev J C Lawrence
      • • ADMIN: Advertising on MUD-Dev quzah
        • ADMIN: Advertising on MUD-Dev John Bertoglio
      • ADMIN: Advertising on MUD-Dev Caliban Tiresias Darklock
      • ADMIN: Advertising on MUD-Dev quzah
      • • ADMIN: Advertising on MUD-Dev Caliban Tiresias Darklock
        • • ADMIN: Advertising on MUD-Dev s001gmu@nova.wright.edu
  • ADMIN: Advertising on MUD-Dev Chris Gray
  • ADMIN: Advertising on MUD-Dev Scatter
  • ADMIN: Advertising on MUD-Dev J C Lawrence
• Adverts in email on the list. Ben Greear
• • Adverts in email on the list. quzah
  • • Adverts in email on the list. Jon A. Lambert
    • • Adverts in email on the list. quzah
  • Adverts in email on the list. Holly Sommer
  • • Adverts in email on the list. Vadim Tkachenko
• Ethernet NICS, maximum connections..mud testing. Ben Greear
• • Ethernet NICS, maximum connections..mud testing. Vadim Tkachenko
• Ethernet NICS, maximum connections..mud testing. Ben Greear
• Ethernet NICS, maximum connections..mud testing. Chris Gray
• • Ethernet NICS, maximum connections..mud testing. Ben Greear
• lurker emerges James Wilson
• • lurker emerges Chris Gray
  • • lurker emerges Adam J. Thornton
  • lurker emerges Chris Gray
  • lurker emerges Petri Virkkula
  • • lurker emerges T. Alexander Popiel
    • • lurker emerges James Wilson
      • • lurker emerges T. Alexander Popiel
      • lurker emerges Vadim Tkachenko
      • • lurker emerges Ben Greear
        • • lurker emerges J C Lawrence
        • lurker emerges T. Alexander Popiel
        • • lurker emerges Vadim Tkachenko
          • • lurker emerges T. Alexander Popiel
            • • lurker emerges Vadim Tkachenko
              • • lurker emerges T. Alexander Popiel
                • • lurker emerges Vadim Tkachenko
                  • • lurker emerges T. Alexander Popiel
                    • • lurker emerges Vadim Tkachenko
                • lurker emerges Vadim Tkachenko
  • lurker emerges Chris Gray
  • • lurker emerges Vadim Tkachenko
    • lurker emerges J C Lawrence
  • lurker emerges Petri Virkkula
  • lurker emerges J C Lawrence
  • lurker emerges Petri Virkkula
  • lurker emerges Chris Gray
  • • lurker emerges J C Lawrence
• Adverts in email on the list. Chris Gray
• • Adverts in email on the list. quzah
• Fw: lurker emerges James Wilson
• • Fw: lurker emerges T. Alexander Popiel
• Ethernet NICS, maximum connections..mud testing. Chris Gray
• • Ethernet NICS, maximum connections..mud testing. Ben Greear
• Ethernet NICS, maximum connections..mud testing. Chris Gray
• • Ethernet NICS, maximum connections..mud testing. Ben Greear
• Neat surrealistic graphical mudclients in Java? Ola Fosheim Grøstad
• Ethernet NICS, maximum connections..mud testing. Chris Gray
• • Ethernet NICS, maximum connections..mud testing. J C Lawrence
  • • Ethernet NICS, maximum connections..mud testing. Adam J. Thornton
  • Ethernet NICS, maximum connections..mud testing. Ben Greear
• META/ADMIN: ADMIN: Advertising on MUD-Dev Mike Sellers
• • META/ADMIN: ADMIN: Advertising on MUD-Dev Ola Fosheim Grøstad
• Rule #3 S. Patrick Gallaty
• OT: Ethernet NICS, maximum connections..mud testing. Shawn Halpenny
• • OT: Ethernet NICS, maximum connections..mud testing. Vadim Tkachenko
• META: List combat character and racial memory (was Re: Chris Gray
• List of rules suggestionbox Hans-Henrik Staerfeldt
• • List of rules suggestionbox Caliban Tiresias Darklock
• async i/o and threads (was: lurker emerges) James Wilson
• • async i/o and threads (was: lurker emerges Jon A. Lambert
  • • async i/o and threads (was: lurker emerges James Wilson
    • • async i/o and threads (was: lurker emerges Jon A. Lambert
• Amoeba: Distributed OS release J C Lawrence
• clients anyone?... Andrew Wilson
• • clients anyone?... Adam J. Thornton
  • • clients anyone?... Andrew Wilson
    • clients anyone?... Hans-Henrik Staerfeldt
    • • clients anyone?... Adam J. Thornton
      • clients anyone?... Bruce Mitchener, Jr.
      • • clients anyone?... James Wilson
        • clients anyone?... Adam J. Thornton
        • • clients anyone?... Andrew Wilson
          • • clients anyone?... Adam J. Thornton
            • • clients anyone?... Andrew Wilson
              • • clients anyone?... Adam J. Thornton
      • clients anyone?... Adam Wiggins
    • clients anyone?... Andrew Wilson
  • clients anyone?... J C Lawrence
  • • clients anyone?... Andrew Wilson
• Re:Methods to Reduce Ecological Wipeout Michael.Willey@abnamro.com
• ADMIN: Over quoting (again) J C Lawrence
• JASSS: The Journal of Artificial Societies and Social Simulation J C Lawrence
• Methods to Reduce Ecological Wipeout Leach, Brad BA
• • Methods to Reduce Ecological Wipeout s001gmu@nova.wright.edu
  • • Methods to Reduce Ecological Wipeout quzah
    • • Methods to Reduce Ecological Wipeout Michael.Willey@abnamro.com
  • Methods to Reduce Ecological Wipeout Koster, Raph
  • • Methods to Reduce Ecological Wipeout Michael.Willey@abnamro.com
    • • Methods to Reduce Ecological Wipeout Koster, Raph
      • • Methods to Reduce Ecological Wipeout Brandon J. Rickman
        • • Methods to Reduce Ecological Wipeout quzah
          • Methods to Reduce Ecological Wipeout Marian Griffith
        • Methods to Reduce Ecological Wipeout Damion Schubert
        • Methods to Reduce Ecological Wipeout J C Lawrence
    • Methods to Reduce Ecological Wipeout J C Lawrence
• LinuxThreads and SIGUSR1 (Ref: [MUD-Dev]) Adam J. Thornton
• Eye movement. quzah
• • Eye movement. James Wilson
  • • Eye movement. quzah
    • • Eye movement. S. Patrick Gallaty
      • • Eye movement. T. Alexander Popiel
    • Eye movement. Hans-Henrik Staerfeldt
• OGR: Ion Storm's Witchboy talks about the functionality of enemy AI. J C Lawrence
• • OGR: Ion Storm's Witchboy talks about the functionality of enemy AI. s001gmu@nova.wright.edu
  • • OGR: Ion Storm's Witchboy talks about the functionality of enemy AI. J C Lawrence
• Methods to Reduce Ecological Wipeout (fwd) Marc Hernandez
• avoiding ecological wipeout Laurel Fan
• Passing file descriptors to other processes Adam J. Thornton
• Yet another update on threads and signals Adam J. Thornton
• • Yet another update on threads and signals s001gmu@nova.wright.edu
  • Yet another update on threads and signals Chris Gray
  • • Yet another update on threads and signals Adam J. Thornton
  • Yet another update on threads and signals Chris Gray
  • • Yet another update on threads and signals Adam J. Thornton
  • Yet another update on threads and signals Chris Gray
  • • Yet another update on threads and signals Adam J. Thornton
• OT: access s001gmu@nova.wright.edu
• Affordances and social method cat
• Affordances and social method cat
• • Affordances and social method Caliban Tiresias Darklock
  • • Affordances and social method Ola Fosheim Grøstad
• Missing MUD-Dev post (fwd) Dr. Cat
• FW: UBE/high: W IRED: Kilers have more fun Koster, Raph
• Affordances and social method Koster, Raph
• Marian's Tailor Problem Koster, Raph
• • Marian's Tailor Problem Brandon Cline
  • Marian's Tailor Problem Hans-Henrik Staerfeldt
  • • Marian's Tailor Problem Brandon Cline
    • • Marian's Tailor Problem Ola Fosheim Grøstad
      • Marian's Tailor Problem Damion Schubert
  • Marian's Tailor Problem Chris Gray
• UBE/high: W IRED: Kilers have more fun Koster, Raph
• • UBE/high: W IRED: Kilers have more fun Mike Sellers
  • UBE/high: W IRED: Kilers have more fun s001gmu@nova.wright.edu
  • UBE/high: W IRED: Kilers have more fun Marian Griffith
• Question for the list (Semi-OT) Nathan F Yospe
• • Question for the list (Semi-OT) Oliver Jowett
  • • Question for the list (Semi-OT) Jon Leonard
  • Question for the list (Semi-OT) Ben Greear
• FW: UBE/high: W IRED: Kilers have more fun Jon A. Lambert
• Private Affordances and social method Mike Sellers
• • Private Affordances and social method Marian Griffith
  • • Private Affordances and social method Mike Sellers
• FW: UBE/high: W IRED: Kilers have more fun Marian Griffith
• UBE/high: FW: UBE/high: W IRED: Kilers have more fun Dr. Cat
• • UBE/high: FW: UBE/high: W IRED: Kilers have more fun S. Patrick Gallaty
• free XML Parser (was clients anyone?...) James Wilson
• UBE/high: FW: UBE/high: W IRED: Kilers Jon A. Lambert
• • UBE/high: FW: UBE/high: W IRED: Kilers Koster, Raph
  • • UBE/high: FW: UBE/high: W IRED: Kilers S. Patrick Gallaty
    • UBE/high: FW: UBE/high: W IRED: Kilers quzah
    • • UBE/high: FW: UBE/high: W IRED: Kilers James Wilson
      • UBE/high: FW: UBE/high: W IRED: Kilers Damion Schubert
    • UBE/high: FW: UBE/high: W IRED: Kilers J C Lawrence
• UBE/high: UBE/high: FW: UBE/high: W IRED: Kilers Dr. Cat
• Marion's Tailor Problem s001gmu@nova.wright.edu
• • Marion's Tailor Problem Caliban Tiresias Darklock
  • • Marion's Tailor Problem jwilson@rochester.rr.com
    • Marion's Tailor Problem Travis Casey
    • • Marion's Tailor Problem Caliban Tiresias Darklock
      • • Marion's Tailor Problem Adam J. Thornton
        • Marion's Tailor Problem Travis S. Casey
  • Marion's Tailor Problem Jynx {Wyrm / Tygr / Myth} Ryn
  • • Marion's Tailor Problem s001gmu@nova.wright.edu
    • • Marion's Tailor Problem Damion Schubert
    • Marion's Tailor Problem Damion Schubert
    • • Marion's Tailor Problem Ola Fosheim Grøstad
  • Marion's Tailor Problem Adam Wiggins
  • • Marion's Tailor Problem quzah
    • Marion's Tailor Problem Marian Griffith
    • Marion's Tailor Problem J C Lawrence
    • • Marion's Tailor Problem Marian Griffith
      • • Marion's Tailor Problem Koster, Raph
  • Marion's Tailor Problem Matthew R. Sheahan
  • • Marion's Tailor Problem quzah
    • • Marion's Tailor Problem Matthew R. Sheahan
  • Marion's Tailor Problem Koster, Raph
  • • Marion's Tailor Problem Marian Griffith
    • • Marion's Tailor Problem Ola Fosheim Grøstad
      • • Marion's Tailor Problem J C Lawrence
        • • Marion's Tailor Problem Ola Fosheim Grøstad
        • Marion's Tailor Problem Marian Griffith
• Slightly-OT: RPG Mapping Tool Holly Sommer
• UBE/high: UBE/high: FW: UBE/high: W IRED: Kilers Dr. Cat
• UBE/high: FW: UBE/high: W IRED: Kilers Scatter
• • UBE/high: FW: UBE/high: W IRED: Kilers Marian Griffith
  • • UBE/high: FW: UBE/high: W IRED: Kilers Scatter
    • UBE/high: FW: UBE/high: W IRED: Kilers Brandon J. Rickman
    • • UBE/high: FW: UBE/high: W IRED: Kilers Damion Schubert
      • • UBE/high: FW: UBE/high: W IRED: Kilers quzah
        • UBE/high: FW: UBE/high: W IRED: Kilers Marian Griffith
      • UBE/high: FW: UBE/high: W IRED: Kilers Adam Wiggins
      • UBE/high: FW: UBE/high: W IRED: Kilers Travis Casey
      • • UBE/high: FW: UBE/high: W IRED: Kilers Brandon J. Rickman
        • • UBE/high: FW: UBE/high: W IRED: Kilers Koster, Raph
• Thoughts on Marian's Tailor Problem s001gmu@nova.wright.edu
• Standard Mud Room Format? plateau
• • Standard Mud Room Format? T. Alexander Popiel
  • • Standard Mud Room Format? Michael.Willey@abnamro.com
  • Standard Mud Room Format? J C Lawrence
  • Standard Mud Room Format? Adam J. Thornton
  • Standard Mud Room Format? Holly Sommer
  • • Standard Mud Room Format? Matthew R. Sheahan
  • Standard Mud Room Format? Hans-Henrik Staerfeldt
  • Standard Mud Room Format? Scatter
• Tangent to the Tailor Marc Bowden
• PerLDAP, usefull for your perl-mud? quzah
• UBE/high: Affordances and social method Dr. Cat
• UBE/high: FW: UBE/high: W IRED: Kilers have more fun Dr. Cat
• Article: A Summary of Principles for User-Interface Design. J C Lawrence
• • Article: A Summary of Principles for User-Interface Design. Adam J. Thornton
  • Article: A Summary of Principles for User-Interface Design. Ola Fosheim Grøstad
• Sockets permanently in CLOSE_WAIT state. (fwd) Oliver Jowett
• Fw: BlackSquad Releases File Formats Damion Schubert
• Revenants (Marion's Tailor Problem) Damion Schubert
• Finer points of Telnet programming ... Jynx {Wyrm / Tygr / Myth} Ryn
• • Finer points of Telnet programming ... quzah
  • • Finer points of Telnet programming ... J C Lawrence
    • • Finer points of Telnet programming ... quzah
      • • Finer points of Telnet programming ... J C Lawrence
  • Finer points of Telnet programming ... Marc Hernandez
  • Finer points of Telnet programming ... Ben Greear
  • • Finer points of Telnet programming ... Greg Munt
    • • Finer points of Telnet programming ... Ben Greear
  • Finer points of Telnet programming ... Jynx {Wyrm / Tygr / Myth} Ryn
  • • Finer points of Telnet programming ... Caliban Tiresias Darklock
    • • Finer points of Telnet programming ... Adam Wiggins
      • • Finer points of Telnet programming ... Caliban Tiresias Darklock
    • Finer points of Telnet programming ... quzah
  • Finer points of Telnet programming ... Greg Munt
• [off-topic] Email Jeroen Ruigrok/Asmodai
• Minimal MUD-kernel (was Finer points of Telnet programming ...) Niklas Elmqvist
• Modular MUD [Was:Finer points of Telnet programming ...] Jynx {Wyrm / Tygr / Myth} Ryn
• • Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
  • • Modular MUD [Was:Finer points of Telnet programming ...] Adam J. Thornton
    • • Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
      • • Modular MUD [Was:Finer points of Telnet programming ...] Adam J. Thornton
        • • Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
          • • Modular MUD [Was:Finer points of Telnet programming ...] pomales
            • • Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
              • Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
              • • Modular MUD [Was:Finer points of Telnet programming ...] pomales
          • Modular MUD [Was:Finer points of Telnet programming ...] Jeroen Ruigrok/Asmodai
          • • Modular MUD [Was:Finer points of Telnet programming ...] James Wilson
    • Modular MUD [Was:Finer points of Telnet programming ...] Jynx {Wyrm / Tygr / Myth} Ryn
    • • Modular MUD [Was:Finer points of Telnet programming ...] Caliban Tiresias Darklock
• Modular MUD Caliban Tiresias Darklock
• • Modular MUD Ola Fosheim Grøstad
  • • Modular MUD Caliban Tiresias Darklock
    • Modular MUD Jeroen Ruigrok/Asmodai
    • • Modular MUD D. B. Brown
      • • Modular MUD quzah
        • • Modular MUD Caliban Tiresias Darklock
          • • Modular MUD Adam J. Thornton
            • • Modular MUD Caliban Tiresias Darklock
              • • Modular MUD Adam J. Thornton
                • • Modular MUD quzah
                  • • Modular MUD J C Lawrence
                    • Modular MUD Adam J. Thornton
                    • • Modular MUD Bruce Mitchener, Jr.
                      • Modular MUD Holly Sommer
                      • • Modular MUD Adam J. Thornton
                    • Modular MUD Caliban Tiresias Darklock
                  • Modular MUD Vadim Tkachenko
                  • Modular MUD John Bertoglio
• Modular MUD [Was:Finer points of Telnet progra Jon A. Lambert
• OS Wars [Was: Modular MUD] Jynx {Wyrm / Tygr / Myth} Ryn
• Modular MUD [Was:Finer points of Telnet progra Jon A. Lambert
• Modular MUD [Was:Finer points of Telnet programming ...] Chris Gray
• The 'consider' command Richard Woolcock
• • The 'consider' command Damion Schubert
  • • The 'consider' command Jon Leonard
  • The 'consider' command Hans-Henrik Staerfeldt
• Scripting:was Modular Mud Jon A. Lambert
• Quake 3: How to do OpenGL J C Lawrence
• lockless system - foolproof? James Wilson
• • lockless system - foolproof? Chris Gray
  • • lockless system - foolproof? J C Lawrence
    • lockless system - foolproof? James Wilson
  • lockless system - foolproof? J C Lawrence
  • • lockless system - foolproof? James Wilson
    • • lockless system - foolproof? J C Lawrence
      • • lockless system - foolproof? T. Alexander Popiel
        • • lockless system - foolproof? J C Lawrence
          • • lockless system - foolproof? T. Alexander Popiel
            • • lockless system - foolproof? J C Lawrence
        • lockless system - foolproof? James Wilson
        • • lockless system - foolproof? J C Lawrence
• Admin: OS wars and avocacy are off-topic J C Lawrence