November 1998

• ADMIN: Unsubscriptions J C Lawrence
• ScryMUD [CUSTOM] Code release. Ben Greear
• Designgoals for CoolComponentCore(Was MUD-Dev's...) Ola Fosheim Grøstad
• • Designgoals for CoolComponentCore (Was MUD-Dev's...) Niklas Elmqvist
  • • Designgoals for CoolComponentCore (Was MUD-Dev's...) Ola Fosheim Grøstad
• DevMUD: CVS Tree is ready. Are your sources? J C Lawrence
• DevMUD considerations and the Halloween article J C Lawrence
• • DevMUD considerations and the Halloween article Jon Leonard
  • • DevMUD considerations and the Halloween article Adam J. Thornton
    • DevMUD considerations and the Halloween article J C Lawrence
  • DevMUD considerations and the Halloween article Chris Gray
  • • DevMUD considerations and the Halloween article Jon Leonard
    • • DevMUD considerations and the Halloween article David Bennett
      • DevMUD considerations and the Halloween article Alex Oren
  • DevMUD considerations and the Halloween article Chris Gray
  • • DevMUD considerations and the Halloween article Marc Hernandez
  • DevMUD considerations and the Halloween article Chris Gray
  • • DevMUD considerations and the Halloween article Vadim Tkachenko
    • DevMUD considerations and the Halloween article Jon Leonard
  • DevMUD considerations and the Halloween article Alex Oren
  • • DevMUD considerations and the Halloween article Alex Oren
    • • DevMUD considerations and the Halloween article Ola Fosheim Grøstad
  • DevMUD considerations and the Halloween article Chris Gray
• Designgoals for CoolComponentCore (Was MUD-Dev's...) Chris Gray
• Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Hal Black
• • Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
  • • Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Jon Leonard
    • • Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Ola Fosheim Grøstad
• Flamebite of the day Vadim Tkachenko
• META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
• • META: DevMUD, MUD-Dev, and (list) futures Jon Leonard
  • • META: DevMUD, MUD-Dev, and (list) futures James Wilson
    • META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
  • META: DevMUD, MUD-Dev, and (list) futures J C Lawrence
• DevMud RFC #1 - Was DevMUD considerations and the Halloween article James Wilson
• My vision for DevMUD Jon Leonard
• • My vision for DevMUD Niklas Elmqvist
  • • My vision for DevMUD Jon Leonard
  • My vision for DevMUD Thandor
  • • My vision for DevMUD Robert Woods
    • • My vision for DevMUD ApplePiMan@aol.com
      • My vision for DevMUD Thandor
    • My vision for DevMUD Jon Leonard
    • My vision for DevMUD Adam J. Thornton
    • • My vision for DevMUD Jon Leonard
      • • My vision for DevMUD Adam J. Thornton
        • My vision for DevMUD Caliban Tiresias Darklock
        • • My vision for DevMUD ApplePiMan@aol.com
          • • My vision for DevMUD James Wilson
            • • My vision for DevMUD ApplePiMan@aol.com
              • • My vision for DevMUD James Wilson
                • • My vision for DevMUD Jon A. Lambert
                  • My vision for DevMUD Darrin Hyrup
                  • • My vision for DevMUD Jon Leonard
                    • • My vision for DevMUD J C Lawrence
                      • • My vision for DevMUD ApplePiMan@aol.com
                  • My vision for DevMUD ApplePiMan@aol.com
        • My vision for DevMUD ApplePiMan@aol.com
        • • My vision for DevMUD Jon A. Lambert
          • • My vision for DevMUD Hal Black
            • • My vision for DevMUD ApplePiMan@aol.com
      • My vision for DevMUD Jon A. Lambert
  • My vision for DevMUD Chris Gray
  • My vision for DevMUD Chris Gray
  • • My vision for DevMUD Ben Greear
    • • My vision for DevMUD Jo Dillon
      • • My vision for DevMUD Ben Greear
• DevMUD Prototyping (was META: DevMUD, MUD-Dev, and (list) futures) Jon Leonard
• • DevMUD Prototyping (was META: DevMUD, MUD-Dev, and (list) futures) James Wilson
• DevCore Project Management Ola Fosheim Grøstad
• • DevCore Project Management Adam Wiggins
  • • DevCore Project Management Ola Fosheim Grøstad
  • DevCore Project Management Simon Duggan
  • • DevCore Project Management Jon Leonard
  • DevCore Project Management Chris Gray
  • DevCore Project Management Darrin Hyrup
• Fallacy Watch and DevMUD Vision (was ... CoolComponentCore) Chris Gray
• Drama Theory Ling
• Moral license (My vision for DevMUD) Ola Fosheim Grøstad
• • Moral license (My vision for DevMUD) ApplePiMan@aol.com
  • • Moral license (My vision for DevMUD) Ola Fosheim Grøstad
• Fwd: My vision for DevMUD Jon Leonard
• DevMUD Prototyping Niklas Elmqvist
• Altima... Thandor
• Fwd: My vision for DevMUD Darrin Hyrup
• Tim O'Reilly's "Open Letter to Microsoft" ApplePiMan@aol.com
• • Tim O'Reilly's "Open Letter to Microsoft" Adam Wiggins
• [DevMud] quick question... Franklyn Colebrooke, Jr.
• signal to noise... Andrew Wilson
• "knights and merchants" - NYTimes review James Wilson
• ADMIN: DevMUD posting authority promotions J C Lawrence
• A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
• • A Small Conceptual Object System For MUDs Emil Eifrem
  • • A Small Conceptual Object System For MUDs Mark Gritter
    • A Small Conceptual Object System For MUDs Ola Fosheim Grøstad
    • • A Small Conceptual Object System For MUDs Jon A. Lambert
• Random Quest Generation chris@realm.zfn.uni-bremen.de
• • Random Quest Generation Chris Gray
  • Random Quest Generation Michael.Willey@abnamro.com
  • Random Quest Generation J C Lawrence
  • • Random Quest Generation J C Lawrence
• Quick socket question Dr. Cat
• • Quick socket question Jon Leonard
  • Quick socket question Ben Greear
  • Quick socket question Chris Gray
  • Quick socket question J C Lawrence
  • • Quick socket question J C Lawrence
  • Quick socket question Adam Wiggins
  • Quick socket question Petri Virkkula
• ScryMUD [CUSTOM] Released under GNU General Public License Ben Greear
• • ScryMUD [CUSTOM] Released under GNU General Public License Chris Gray
• Quick socket answer Dr. Cat
• Rebol Ling
• Spell components, chemistry, and the like... quzah [sotfhome]
• • Spell components, chemistry, and the like... Chris Gray
  • • Spell components, chemistry, and the like... quzah [sotfhome]
      From: Chris Gray <cg@ami-cg.GraySage.Edmonton.AB.CA>
      Monday, November 09, 1998 at 11:37 PM
      Subject: [MUD-Dev] Re: Spell components, chemistry, and the like...
      
      
      >[quzah:]
      >
      > >{
      > >"molten gold", COTYPE_METAL_GOLD, COFORM_LIQUID,
      > >COTEMP_HOT_HD, COSIZE_MODERATE, (volume), (weight/volume),
      > >(heat_to), (cool_to), (found where), ...
      > >},
      >
      >I'd love to help, but I'm not at all sure where the above is supposed
      >to fit in, and what all the fields are for. Is 'CO' a prefix for
      >"component", and these are things that can be spell components?
      
      
      Nod. 'CO' was the prefix for "component", just put there so I can
      at a glance tell that all of COxxx_yyy go to "component".
      
      >
      >Anyway, even while baffled, I came up with this thought:
      >
      >In the real world, the connection between one form of an element and
      >another is often not at all obvious. For example, diamond shares
      >very little with charcoal, yet they are both (mostly) carbon. Gasseous
      >carbon would be similarly different. So, if you are expressing things
      >which have different physical properties, you probabably have to do
      >all forms of any given material. In that sense elements aren't any
      >different from compounds. If you want a spell to be able to use any
      >kind of carbon, rather than just diamond, for example, then you will
      >have to link the diamond and charcoal entries together somehow.
      >Note that you can grind up both charcoal and diamond, and then they
      >behave much the same at the coarse level.
      
      
      This is what I am doing now, I have added in a few elements such as
      gold, carbon, and so on, mainly for the use of "I need a specific
      element for this spell, and it must be pure." That aside, I'm also
      tossing in things like below (rose) and whatever else (charcoal).
      
      I think I'm going to skip keeping track of the chemical makeup of
      all items (charcoal is x parts carbon, and y parts z, or whatever)
      to keep it a tiny bit simple. I am sure some people may say that
      "X contains Y so why can't I subsitute Y for this spell", but I
      think at the moment I'll take the chance of disapointing someone,
      and preserve my sanity.
      
      >Now, that is an extreme example. In the case of solid gold versus
      >gold dust, the properties are the same at the fine level, and differ
      >only at the gross level. Gold dust is sort-of a fluid and can be
      >blown away, but both are untrue for solid gold. However, the difference
      >between gold dust and a gold bar is exactly the same difference between
      >copper dust and a copper bar. So, I would suggest that gold and copper
      >both be examples of metals, which can exist in a variety of states.
      >Roses would be an example of a plant, for which those states are only
      >vaguely relevant (I suspect you can't have molten roses - heat would
      >cause chemical breakdown, and you would then have something other than
      >a rose).
      
      >
      >Hmm. I bet I haven't helped at all. That's what I get for typing at
      >midnight!
      
      
      No, actually it was a help. I have decided to keep track of it this
      way:
      
      {
      "solid_name", "liquid_name", "gas_name", (solid_temp), (liquid_temp),
      (solid_form),(liquid_form),(gas_form),(solid_form_#),(liquid_form_#),
      (gas_form_#)
      },
      
      
      Explained:
      You hit the nail right on the head with the "dust form is the same
      as bar form" idea. I've decided to toss out the entire "COTYPE_"
      which was a very large list of pointless stuff.
      
      First off, the names:
      I need to keep track of seperate names because "solid water" is not
      called that, it is called ice. Likewise, the gas form of water is not
      water any more. So, if the above were water, the solid name would be
      "ice", the liquid name would be "water", and the gas name would be ""
      
      Next, temperature:
      We only need to keep its freezing/solidifying temperature (which I
      *THINK* is always lower than its liquid form, at least that's how
      I'm doing it), and its vapor/solid-to-gas temperature. Everything
      else is solid. (Yeah, I know that water both freezes and melts at
      the same temperature, but we're going to say it freezes at one, and
      melts at one higher.)
      
      Thirdly, its form:
      I don't like it done this way, but I have to so that I can handle
      the case of the "solid" rose going to gas form (burning). This way
      I keep track of its form[s], one integer for each of its states
      (solid/liquid/gas). I'll set it to 0 if it stays the same (ie:
      water stays the same in two forms, (argueably all three) (solid
      and liquid are both water), if not, it'll hold the number of the
      form it takes on (or, a -1 for a object->vnum, a -2 for a room->vnum,
      a -3 for a mob->vnum).
      
      Finally, I have to add the "_form_#" to cope with the switching to
      a vnum. If I didn't allow items/mobs/rooms to be "components", I
      would not need these last fields; but, they have to be there so I
      can plop a vnum in them if it changed to a different object.
      
      I no longer need to store its current temperature, its current size,
      or its type. The only thing I may add is if it can be found in the
      wild/natural surroundings or not, and in what form it is found in.
      (Not much molten gold is found in the wilderness I'll suspect.)
      
      
      -----------------------------------------------------------------
      [In addition, I've squashed two replies into one, so there are
      less messages to be in your mail box.] So, inreply to:
      -----------------------------------------------------------------
      >From: JavaAl@aol.com <JavaAl@aol.com>
      >Date: Monday, November 09, 1998 11:39 PM
      >Subject: [MUD-Dev] Re: Spell components, chemistry, and the like...
      
      >Okays... this is how I would go for it.
      >
      >If spells are going to be used primarily for combat, then I would worry only
      >about the main forms that you find things in because you are not going to have
      >time in the middle of a fist fight to boil Gold, or vaporise a diamond.
      >However.. for more involved spells, I would solve the problem by making the
      >spell components actual objects, and (not know about the MERC engine much) if
      >you need to 'boil gold' use object swapping, i.e. have a liquid gold object in
      >storage that you can swap in when you type 'boil gold' for the sold gold
      >object.
      >
      >Al.
      
      Thanks for your reply also. I think the above mentioned way of setting
      it up will take care of the need to swap off objects. The name of the
      material will be determined by its current temperature. I plan on storing
      the "component" in an object, but I'll just keep reusing the same object
      for each phase/form of the component. MERC uses four values, set in an
      array to keep track of things like weapon damage and stuff like that.
      
      So, "ITEM_WEAPON" would have four values like so:
      
      value[0] = ( number of dice )
      value[1] = ( sides of dice )
      value[2] = ( say, unused for this example )
      value[3] = ( unused also )
      
      Now, that may not be exactally how those values are set for _WEAPON,
      but I didn't feel like looking them up. At any rate, how I'll do it
      is to add in "ITEM_COMPONENT", and give it values like so:
      
      value[0] = current_form (solid/liquid/gas*)
      value[1] = current_temp (ranges from "cold_high_danger" to
      "hot_high_danger" [ie: don't put your hand in molten gold])
      value[2] = current_size (weight_measurement [tiny -> large])
      value[3] = (something else, currently forgotten (need sleep))
      
      So, it'll go a bit like that. You'll be able to melt/burn/whatever
      your components, and hopefully they'll do a pseudo-realistic form
      change and maybe it'll even look neat and work.
      
      Well, I really need sleep, and I'm sure you are all tired of reading
      (if you're still reading) so I'll cut it short (cause otherwise I'll
      never shut up). Thanks everyone for your input and help, when it's
      done, I'll post a link if anyone likes, so you can look at it/have it
      if it's anything you're interested in.
      -Q-
  • Spell components, chemistry, and the like... JavaAl@aol.com
  • Spell components, chemistry, and the like... Adam Wiggins
  • • Spell components, chemistry, and the like... quzah [sotfhome]
  • Spell components, chemistry, and the like... Nathan F Yospe
  • Spell components, chemistry, and the like... quzah [sotfhome]
  • • Spell components, chemistry, and the like... Hal Black
    • • Spell components, chemistry, and the like... Ling
      • • Spell components, chemistry, and the like... Caliban Tiresias Darklock
        • Spell components, chemistry, and the like... Ben Greear
        • • Spell components, chemistry, and the like... Caliban Tiresias Darklock
        • Spell components, chemistry, and the like... quzah [sotfhome]
        • • Spell components, chemistry, and the like... Caliban Tiresias Darklock
          • • Spell components, chemistry, and the like... quzah [sotfhome]
          • Spell components, chemistry, and the like... Hal Black
          • • Spell components, chemistry, and the like... Peck, Matthew x96724c1
          • Spell components, chemistry, and the like... Nathan F Yospe
  • Spell components, chemistry, and the like... Ben Greear
  • Spell components, chemistry, and the like... JavaAl@aol.com
  • Spell components, chemistry, and the like... Chris Gray
  • • Spell components, chemistry, and the like... Nathan F Yospe
  • Spell components, chemistry, and the like... Adam J. Thornton
  • Spell components, chemistry, and the like... Franklyn Colebrooke, Jr.
  • • Spell components, chemistry, and the like... Emil Eifrem
    • • Spell components, chemistry, and the like... Nathan F Yospe
• ADMIN: Attributions J C Lawrence
• AMIN: Unsubscriptions J C Lawrence
• OO Design Question Brad Leach
• • OO Design Question J C Lawrence
• Chemistry [Warning, scientific content] Peck, Matthew x96724c1
• MUD clients, testing Chris Gray
• • MUD clients, testing Scatter
  • • MUD clients, testing J C Lawrence
• JOB: Project manager and scaling/networking guru needed for game project J C Lawrence
• More module ideas Mark Gritter
• The Innerworld Project Niklas Elmqvist
• META: FAQ's bios. Ling
• Mage 2 Mage 0.89 J C Lawrence
• Game library notes J C Lawrence
• World Building Page Ling
• ScryMUD [CUSTOM] Code release 1.8.1 Ben Greear
• DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
• • DIS: Client-Server vs Peer-to-Peer J C Lawrence
  • • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
    • • DIS: Client-Server vs Peer-to-Peer J C Lawrence
      • • DIS: Client-Server vs Peer-to-Peer Ling
        • • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
          • • DIS: Client-Server vs Peer-to-Peer Ling
            • • DIS: Client-Server vs Peer-to-Peer Nathan F Yospe
              • • DIS: Client-Server vs Peer-to-Peer Ling
            • DIS: Client-Server vs Peer-to-Peer J C Lawrence
            • • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
              • • DIS: Client-Server vs Peer-to-Peer Ola Fosheim Grøstad
                • • DIS: Client-Server vs Peer-to-Peer Marc Hernandez
                  • • DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
                    • • DIS: Client-Server vs Peer-to-Peer Marc Hernandez
                      • • DIS: Client-Server vs Peer-to-Peer Caliban Tiresias Darklock
                        • • DIS: Client-Server vs Peer-to-Peer Mik Clarke
                        • DIS: Client-Server vs Peer-to-Peer Adam Wiggins
  • DIS: Client-Server vs Peer-to-Peer Jon Leonard
  • • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
    • • DIS: Client-Server vs Peer-to-Peer Greg Underwood
  • DIS: Client-Server vs Peer-to-Peer Greg Underwood
  • • DIS: Client-Server vs Peer-to-Peer Marc Hernandez
    • • DIS: Client-Server vs Peer-to-Peer Greg Underwood
    • DIS: Client-Server vs Peer-to-Peer Niklas Elmqvist
    • • DIS: Client-Server vs Peer-to-Peer Greg Underwood
• Ruminations on CVS and developing in the Bazaar Ben Greear
• • Ruminations on CVS and developing in the Bazaar Chris Gray
  • • Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
  • Ruminations on CVS and developing in the Bazaar J C Lawrence
  • • Ruminations on CVS and developing in the Bazaar greear@cyberhighway.net
    • • Ruminations on CVS and developing in the Bazaar J C Lawrence
• Ruminations on CVS and developing in the Bazaar Petri Virkkula
• DevMUD: List data, subscription, and the rest J C Lawrence
• • DevMUD: List data, subscription, and the rest J C Lawrence
• Atention SSH/Java-developers (MindTerm update) J C Lawrence
• ScryMUD/Hegemon code Release Ben Greear