Re: CF: Object decay, and various other matters of direction

[David Andrew Michael Noelle <>]

> David Andrew Michael Noelle wrote:
> 
> >     Agreed.  So the no_magic flag should suffice to prevent either one.  As
> > long as there's anti-magic around anything players shouldn't be able to
> > magically get into, secret rooms will be safe.  Now, two more questions -
> > Why can you see through walls (with x-rays) that you can't dimension door
> > through?  And how do you attack someone who's inside a wall?
 
Mark Wedel wrote:
>  Because x-ray doesn't look at no magic flags.
> 
>  It basically sets the area (3x3 or something like that) around the player as
> visible and ignores all the line of sight and other logic.
> 
>  It would not be hard to say that a no magic area would not appear in the xray
> vision.  But doing calculation that say 'if X has no magic, allow X to be seen,
> but not the space beyond X' is a little more complicated.

    Not too much more complicated, I think.  I haven't looked at the vision
and line-of-sight code, but if instead of just setting a visible area and
ignoring line-of-sight, the check for whether a space is opaque was skipped
for spaces adjacent to a player if they have the x-ray flag, then they'd see
the same area they do now, plus they'd see normally, with lighting and
opacity, beyond that area.  That's how I always thought x-ray vision should
work.  And that would make it easy to throw in a check for anti-magic to
block x-ray vision.  It would be a play balance issue, though, since x-rays
would then be much better than normal vision, without the short range
drawback.  Maybe x-ray vision without normal sight could have en effective
darkness level that would only allow short-range vision.
    Of course, I might be all wrong about how complicated all this is
anyway, since I haven't looked at that code yet.  I should probably go do
that instead of continuing to babble about things I don't know.


[...material archetypes...]
>  But it has to point to something.  If you are pointing to predefined values,
> then arguably you don't even need the pointer - just set up appropriate
> materials or something.

    The idea was to get away from hard-coded (ick) numbers.  By making the
materials objects, the pre-defined values for basic materials would be
archetypes, editable in the arch tree like any others, instead of buried in
the code.  And special material objects could be written into maps.  Of
course, the standard materials would all use pointers to the same standard
material object, the archetype's "clone", instead of each object having its
own copy.  There shouldn't be any need to change an object's material, but
if it happens, a new object of that archtype can always be created when it
is needed.

    Allowing sub-types and arbitrary materials would be less important if we
had a few more materials to choose from.  I had very little trouble adding
liquid to the list, since there are rather few places materials ever come
into play.  Perhaps this material archetypes business is too much trouble
for too little gain.  With enough hard-coded (ick) materials, the only
benefit would be cosmetic.

-- 
            -Dave Noelle,                 
            -the Villa Straylight,  http://www.straylight.org
Coalition Against Unsolicited Commercial Email  ==  http://www.cauce.com

Disclaimer: Disciples of E(vi)L may receive guidance in alt.religion.emacs.
GNU Emacs is The One True Editor.  The $PATH to redemption is /util/gnu/bin.
U.C.L.A. doesn't share my opinions; even Emacs can't make life that good.

Quote of the Day:
"The fastest way to accelerate a Macintosh is 9.8 m/s^2"
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]