CF: Object decay, and various other matters of direction

[David Andrew Michael Noelle <>]

Mark Wedel wrote:
> 
> David Andrew Michael Noelle wrote:
> >     Wouldn't it be *much* better to just implement LOGIC objects so map
> > designers don't have to putz around with secret rooms full of monsters and
> > buttons and boulders and gates?  A few simple logic objects would simplify
> > that whole mess considerably.  Throw in "dice" objects, described in a
> > previous thread, and "insert" objects that can be connected to triggers and
> > can deploy a creature or produce an item from their inventory (so it doesn't
> > have to be an archetype), and a lot of the complicated, unstable
> > contraptions currently used for special effects could be replaced with fewer
> > objects that are much easier to use.
> 
>  I think there are several factors on this.
> 
>  One is that if the map maker is a non programmer, they will look for this
> creative use of objects to get the job done.  And of course, other people see
> that, and do the same thing.

    True.  Copying the current maps will perpetuate the current mess.  I'll
volunteer to implement logic objects, document them, and alter old maps to
use them as examples, when 0.96 objects become availble.  And it doesn't
take a programmer to use things like "If ALL of 1, 2, 3 are true, trigger 4,
5" and "If ANY of 1, 3, 5 are true, trigger 7"  The best alternative I can
think of would be script objects with the same basic logic functions, which
would require more processing to execute.  Unless, of course, the scripts
are compiled when the map is loaded...  hmm...


>  Thats true - no magic currently works.  The idea on that was to make it a bit
> more visible or different.  One problem that does happen when map designers
> start changing objects too much is difficulty in other designers down the road
> to figure out the map.  So by actually having different objects that have
> different names or otherwise appear differently in the editor would make it
> easier on other maps (or the other would be to have an overlay - ie, show me all
> the non magic spaces, show me all the no pass spaces, etc)

    I'd like to see those overlays implemented, but I'd settle for
indicators, when viewing the objects on a space, of whether or not that
space has anti-magic, unholy, and/or no-pass.  Just scan the objects, OR
their flags together, and light up some simple little indicator for each
relevant bit that is set.  If you want to take it one step further, allow a
right-click to clear that bit in everything present and a left-click to set
that bit in the bottom floor or wall object.


>  If you can't dimension door, you probalyb should not be able to get past
> ethereally and vice versa.  And i think trying to get too refined on the
> different attributes may just add extra complication and other errors.

    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?

>  In terms of wall height - not sure how much it really adds.  If anything, you
> coul have a 'climb_chance' field.  If non zero, it is climable, or you could fly
> over.  You could use this to take into consideration wall difficulty or
> whatever.
> 
>  But in reality, it probably does not make a big difference - either you can get
> over the wall or you can't.  The difficulty is not likely to make a big
> difference, as if the wall is climbable, the player will just try over and over
> again until they can do it, and likely with the fast paste nature of crossfire,
> that time to do so would not be a big deal.

    Good point.  I'd like to see that climb chance implemented anyway,
though.  That, together with the map difficulty for a level, would determine
an amount of climbing (Dex) experience to award for success.


>  The problem is that there are lots of other stuff needed to support this.  If
> it is a server option that is enabled, yet no maps have the necessary repair
> altars, it really doesn't do any good.  Likewise, if a fair number of people
> turn it off, when they make up new maps or objects, they may not think about
> decomposition of objects, so you quickly get a bunch of objects that don't
> decompose or don't decompose at a reasonable rate.

    You're right.  I hadn't thought beyond warning server admin to make sure
they use maps that are compatible with their settings.  Settings like that,
which significantly alter play, might pose a threat of schism if they're
controversial enough.  And I suspect item degradation would be that
controversial.


>  IMO, for balance issues, configuration options that affect the game play really
> need to be removed (there are some options which affect the server, but not
> really how the game plays that much).  If you have 40 different possible
> combinations (spell speed, object decay, alchemy, gods, etc), it is likely
> things will never get balance pretty well.

    I'm willing to go through the code and remove obsolete options while I'm
playing with my experiments, if it is agreed that they are really useless
now.  Things like skills, alchemy, and multi-god should probably be
considered permanent additions by now.


>  Now we could come up with an official configuration, and only worry about
> balancing that, but even that is likely to be slower (as some players won't use
> that, so there suggestions on balance may not be totally accurrate).  And some
> options may have opposite affect on balance.

    For right now, it probably isn't necessary, but when it comes time to
fine-tune the balance, I think an official configuration will be necessary. 
Anyone who wants to use other options will have to edit their config files
to set them, where they'll be warned that if their choices aren't balanced
with the maps they use, it's their own fault and their own problem.  But for
the time being, most of the balance issues are too severe to worry about
such settings.

 
>  Thats true.  The acid was a simple example.  OF course, changing the sword to
> admantite gives it more than immunity to just acid - I believe it basically
> makes it immune to everything.  So your counter example is not perfect.

    Good counterpoint.  Adamantium is indeed immune to everything.  Stone
would have been a better example.  It's fairly close to iron in most of its
saving throws, but it doesn't rust.

 
[... material archetypes ...]
>  I think this is going a bit on overkill/overcomplication.

    You're probably right.  We do need either a few more material types or a
different system.  Specifically, I'm adding "liquid" material to my tests at
the moment.

> >     This would allow interesting new materials with imaginative
> > descriptions, without eating up very much memory, since all the common
> > objects would point to the same few basic combinations, like flesh, wood and
> > iron, glass and liquid, iron and crystal, paper, and maybe a handful more.
> 
>  IF anything, just add a flag which is basically has the program use the item
> message field for the description, and basically have the program not say
> anything about the item except maybe its worth.
> 
>  In that way, you could have the message describe the item any way you like
> without conflict from the program saying it is adamantium.

    That's a good idea.  I like that.  You don't even need a flag for it. 
If a material string is present, use it.  If not, describe the flags that
are set.

>  In any case, the pointer method still does not do anything for saving throws,
> since they are hard coded into the program (ie, iron needs a XXX against acid,
> yyy against fire, etc).  So the pointer really doesn't add anything at all to
> the possible destruction of the items.

    It does if it's a pointer to an array of additive protection ratings, or
in the case of the suggestion I was making, an object with a description of
the materials and an integer protection rating for each attacktype.  On most
architectures, that pointer wouldn't be much larger than the bitmask we
currently have.  That way, the object saving throws would no longer be
hardcoded.


> > This reminds me... apparently ghosts have some kind of pass_thru_door flag??
[...]

>  Not positive.  But chances are that the logic which actually looks to see if a
> monster can reach you stops at the wall.  The function probably doesn't look to
> see if that wall actually affects the monster or not, so for all purposes, it is
> a flag that doesn't do anything.
> 
>  This has been broken for as long as I can remember (broken in that I never
> remember seeing ghosts go through walls), and thats a long time.  However, if
> fixed, this could create bad situations (the ghost is in the wall and attacks
> the player, but the player can't attack back because the wall is there.)  I am
> not sure if the code is smart enough to see that there is in fact a ghost there
> to attack or not.

    I'm pretty sure that wouldn't be handled well.  Spells won't go through
walls, even if they aren't marked no_pass.  I suspect weapons might work,
but only if the creature is below the wall, so that the routine that checks
what's there encounters the creature before the wall.


>  Plus, it hasn't worked in such a long time I have a feeling if it was fixed at
> this point, the balance/difficulty of some maps would radically change.

    I can think of a couple maps off the top of my head where it would be
entirely unfair to have ghosts coming at you from the walls, where you can't
even see them until it's too late.  The same problem would come up with
aethereal creatures like vampires.  They'd just stand in the wall, draining
you, and you wouldn't even know where the attack was coming from.
    I suggest that the matter of walking through walls should be set aside
until monsters can be prevented from seeing through walls.  If they couldn't
see you because they were inside the wall, they'd have to step out to
attack, but they could run away easily by going through the wall.  We just
need line of sight for monsters first.


>  I certainly think some items will have to be immune to the destructive/aging
> aspects - items key to completing quests one of them.

    Either that or have a large supply of the items and try to get one of
them from point a to point b without it being destroyed.  That could make
for an interesting quest that isn't quite as hack'n'slash as most.


>  Note that this is true right now however.  If you launch a fireball in a room,
> kill the guy with the scroll, and he drops the scroll when he dies (like all
> monsters do), it could then burn up at that time.
> 
>  The problem would certainly be worse with if inventory also got hit.  One
> unrealistic way would only have inventory get burned for players, and not
> monsters.  After all, we are trying to balance the players more than the
> monsters.

    If monster inventories start taking damage while it's alive, fire spells
are going to be a bit less popular.  The most important treasure for mages
is the stuff that burns easiest.  Perhaps spellbooks should have a bonus to
their saving throws, because of some inherent magical nature.  Probably it
should be based on the level of the spell.  And any important scrolls could
be stored in specialized containers, scroll cases, that are made of some
sturdier material.  At least wood if not iron.

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

Disclaimer: "I am the Lorax, I speak for the trees!"

Quote of the Day:
Today is the tomorrow you worried about yesterday.
-
[you can put yourself on the announcement list only or unsubscribe altogether
by sending an email stating your wishes to ]