[MUD-Dev] Re: Spell components, chemistry, and the like...

[quzah]

From: Chris Gray <cg at 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 at aol.com <JavaAl at 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-