Dungeon Crawl Reference

On Wed, Nov 04, 2009 at 12:53:31PM -0700, Matthew Cline wrote:
> On Wednesday 04 November 2009 11:30:10 am KiloByte wrote:
> 
> > +    case SPARM_INTELLIGENCE:
> > +        if (type == ARM_HELMET)
> > +            return (false);
> 
> Anything *but* helmets can be SPARM_INTELLIGENCE?

Ook.

-- 
1KB		// Microsoft corollary to Hanlon's razor:
		//	Never attribute to stupidity what can be
		//	adequately explained by malice.

On Tue, Nov 3, 2009 at 11:08 PM, David Ploog <ploog@...> wrote:
> Hm, I don't like either of these: "chute" sounds as technical as
> "springloaded hatch" (or however we explain the mechanic of hatches). And
> "ladders" should by no means be unidirectional -- you can walk one up as
> well as down.

I suspect that the significance of my suggestion may have been lost in
translation.
Please see:
* http://www.wpromote.com/blog/wp-content/uploads/2008/09/chutesladders.gif
* http://en.wikipedia.org/wiki/Snakes_and_ladders

:-)

Brendan

On Wed, 4 Nov 2009, Brendan Hickey wrote:
> On Tue, Nov 3, 2009 at 11:08 PM, David Ploog <ploog@...> wrote:
>> Hm, I don't like either of these: "chute" sounds as technical as
>> "springloaded hatch" (or however we explain the mechanic of hatches). And
>> "ladders" should by no means be unidirectional -- you can walk one up as
>> well as down.
>
> I suspect that the significance of my suggestion may have been lost in
> translation.
> Please see:
> * http://www.wpromote.com/blog/wp-content/uploads/2008/09/chutesladders.gif
> * http://en.wikipedia.org/wiki/Snakes_and_ladders

Uh oh :) Too much to do to catch jokes. I'll try better next time.

David

On Tue, Nov 3, 2009 at 11:08 PM, David Ploog <ploog@...> wrote:

> I still think that "hole" and "shaft" work nicely. "Hole" clearly
> transports the mental image of something that's stable and you can go down
> it you really want to. "Shaft" indicates something that is cramped, so
> less stable

I'm not trying to be argumentative, but to me those words do not
connote any of those things.  (Cramped, maybe.)

> Summary of my proposal, which at least managed to convince Alex:
> * brown < is removed
> * brown > is renamed "Hole", no change in functionality
> * shafts ^ can be traps and work then as now
> * shafts can also be generated known
> * you can go down known (generated or detected) shafts with ">"
> * brown > are only generated in bubbles and closed vaults; else use shafts

So other than the terminology change, am I understanding that the main
changes here are:
(1) the removal of brown <.
(2) Change (most) brown > into shaft traps, which act like brown >
when detected?

This seems really different to me than the proposals above.  Pre-known
shafts now seem identical to down-hatches, so why have both?  Also,
what happened to brown > being single use and not letting monsters
follow? I thought that was a particularly good idea.

When I go back and read your original reasons for why hatches need
changing (i.e. nobody uses them), I don't feel like this proposal
solves any of that, whereas the original proposal potentially could.

I will counter-propose this set of changes:

* Upward escape hatches (brown <) are removed.
* Detected shaft traps (^) can now be used by choice with ">".
* Downward escape hatches (brown >) are single-use, monsters don't follow.
* Downward escape hatches in bubbles become (detected?) shaft traps.
* No naming changes.  Escape hatch and shaft trap are good names.

-Enne

2009/11/4 Enne Walker <enne.walker@...>:
> So other than the terminology change, am I understanding that the main
> changes here are:
> (1) the removal of brown <.
> (2) Change (most) brown > into shaft traps, which act like brown >
> when detected?
>
> This seems really different to me than the proposals above.  Pre-known
> shafts now seem identical to down-hatches, so why have both?  Also,
> what happened to brown > being single use and not letting monsters
> follow? I thought that was a particularly good idea.
>
> When I go back and read your original reasons for why hatches need
> changing (i.e. nobody uses them), I don't feel like this proposal
> solves any of that, whereas the original proposal potentially could.
>
> I will counter-propose this set of changes:
>
> * Upward escape hatches (brown <) are removed.
> * Detected shaft traps (^) can now be used by choice with ">".
> * Downward escape hatches (brown >) are single-use, monsters don't follow.
> * Downward escape hatches in bubbles become (detected?) shaft traps.
> * No naming changes.  Escape hatch and shaft trap are good names.

This sounds very good to me. Yes to "detected?" in the fourth point.
You can already place "known shaft trap" in vaults, so it should all
work out pretty neatly.

This needs cleaning up the vault files but that's just a job to do.
Some discretion can be used if the best solution to replace a down/up
hatch is to use a known shaft trap, a known teleport trap, a portal to
Abyss.. :) Shafts can be nasty as they can drop a couple of levels
down. This is most important on the earlier vaults. Still using
hatches for later vaults - I'm two minds about that: as a risk I'm ok
with it, getting stranded is something you can work against by
conserving teleport items. But being starved in a bubble is an unfun
way to die, and if you're a mummy or a vampire, you're forced to quit,
which is pretty bad (there's no in-gameworld way to end the
situation). So.. I would just avoid using them. Shafts are pretty
good.

There's a remaining issue of what to do for upward hatches in branch
end vaults and other vaults that are on the bottom floor (I forget who
brought it up and where, but thanks for doing so!). Can't quite do
teleport traps for V:8 or Snake:5. :)

--Eino

David Ploog <ploog@...> wrote:
> I still think that "hole" and "shaft" work nicely. "Hole" clearly
> transports the mental image of something that's stable and you can go down
> it you really want to. "Shaft" indicates something that is cramped, so
> less stable. Also note that neither needs mechanical tools to exist.

A shaft is a long, straight tunnel, which means it's almost always
artificial and shored-up with beams and other reinforcement.

> David

-Wm

Enne Walker wrote:
> I will counter-propose this set of changes:
>
> * Upward escape hatches (brown <) are removed.
> * Detected shaft traps (^) can now be used by choice with ">".

Doesn't it work this way already? (Not that I ever tried, I just thought
it did.)

> * Downward escape hatches (brown >) are single-use, monsters don't follow.
> * Downward escape hatches in bubbles become (detected?) shaft traps.
> * No naming changes.  Escape hatch and shaft trap are good names.

Fully seconded!

Johanna

On Wed, 4 Nov 2009, Enne Walker wrote:
> On Tue, Nov 3, 2009 at 11:08 PM, David Ploog <ploog@...> wrote:
>
>> I still think that "hole" and "shaft" work nicely. "Hole" clearly
>> transports the mental image of something that's stable and you can go down
>> it you really want to. "Shaft" indicates something that is cramped, so
>> less stable
>
> I'm not trying to be argumentative, but to me those words do not
> connote any of those things.  (Cramped, maybe.)

I will simply stop worrying about words. Whenever I want to discuss 
gameplay, I end up discussing words. I really don't like "escape hatch" 
but all I am interested in is making those brown stairs interesting, 
perhaps by replacing them with brown ^ if it helps.

> So other than the terminology change, am I understanding that the main
> changes here are:
> (1) the removal of brown <.
> (2) Change (most) brown > into shaft traps, which act like brown >
> when detected?

Yes on (1). No on (2). Here is the true (2):

(2) Change most brown > into known ^. Known ^ (known from detecting a 
secret one, or because it was generated known) can be used with > BUT they 
disappear after use AND monsters don't follow.
Your (2) is also misleading in that all ^ go deeper than just one level, 
although this is slightly less important to me than the other bits.

> This seems really different to me than the proposals above.  Pre-known
> shafts now seem identical to down-hatches, so why have both?  Also,
> what happened to brown > being single use and not letting monsters
> follow? I thought that was a particularly good idea.

^^ It was always implied, at least by me.
>
> When I go back and read your original reasons for why hatches need
> changing (i.e. nobody uses them), I don't feel like this proposal
> solves any of that, whereas the original proposal potentially could.
>
> I will counter-propose this set of changes:
>
> * Upward escape hatches (brown <) are removed.
> * Detected shaft traps (^) can now be used by choice with ">".
> * Downward escape hatches (brown >) are single-use, monsters don't follow.
> * Downward escape hatches in bubbles become (detected?) shaft traps.
> * No naming changes.  Escape hatch and shaft trap are good names.

Not only that we now have many different proposals around, you have 
essentially reinvented my original proposal. The first idea was extremely 
simple: brown stairs can be used only once, monsters don't follow. I 
believe this alone would make them interesting.
Things started to get more complicated when Adam complained that it's 
nonsensical to have "escape hatches" disappear (so I came up with the 
change of terminology) and that having brown <> in vaults/bubbles 
disappear would be unfair (so I came up with known ^ alongside the >).

This has become such a mess that I'd really like to abandon this 
altogether. Were I not convinced that single-use levelchange features 
which have monsters not follow is a damn good idea (by Borsuk, by the 
way).

David

On Wed, Nov 4, 2009 at 10:19 AM, David Ploog <ploog@...> wrote:
> Not only that we now have many different proposals around, you have
> essentially reinvented my original proposal. The first idea was extremely
> simple: brown stairs can be used only once, monsters don't follow. I
> believe this alone would make them interesting.
> Things started to get more complicated when Adam complained that it's
> nonsensical to have "escape hatches" disappear (so I came up with the
> change of terminology) and that having brown <> in vaults/bubbles
> disappear would be unfair (so I came up with known ^ alongside the >).
>
> This has become such a mess that I'd really like to abandon this
> altogether. Were I not convinced that single-use levelchange features
> which have monsters not follow is a damn good idea (by Borsuk, by the
> way).

David, I also like your original proposal. However, the need to
preserve their current role in vaults/bubbles seems to complicate
things quite a bit, so here's my recommendation:

1. "Unused escape hatches" allow you to escape once without being
followed (and/or hit), and then they become "used escape hatches" that
work exactly like escape hatches do now.

And a couple variant ideas that I think would go decently with the above.

2. (To make them a little less like a "free extra life" could make the
degree and/or chance of their escape success based on your Trap &
Doors skill. That makes complete sense to me, seeing as "hatch" is a
synonym for "trapdoor.")

3. Also, since upward escape hatches would generally be better than
downward ones, we could potentially make them only usable by airborne
players/monsters, as someone else suggested.

On Wed, Nov 4, 2009 at 12:06 AM, David Ploog <ploog@...> wrote:


> Sure, but not if they spam. A single ancient lich being able to fill the
> room in few turns with frightening monsters: good. A single vampire being
> able to fill the room with rats: bad. Also, the tendency of monster
> summoners to spam is very bad: it encourages level change, waiting out the
> summons and having another go. It would be much better if monster summons
> would summon in smaller batches and/or do other things in between.
>
>
OK. But the proposed mechanic doesn't address this. By limiting the total HD
a monster can summon, it eliminates the genuinely scary summons, while
leaving small mammal spam in place.

Why not address the problem directly by simply reducing the frequency with
which vampires cast Summon Small Mammals? Are there monsters other than
vampires for which this is a problem?

Lemuel

On Nov 4, 2009, at 14:36, Lemuel Pitkin wrote:
> OK. But the proposed mechanic doesn't address this. By limiting the  
> total HD a monster can summon, it eliminates the genuinely scary  
> summons, while leaving small mammal spam in place.

I read the proposed mechanic to limit the number of summons by  
summoner HD. That should prevent mammal spam, though it does hurt  
boggarts badly. Though boggarts could easily be special-cased.

Cheers
Robert

On Wed, Nov 4, 2009 at 9:05 AM, Robert Vollmert <rvollmert-lists@...:

>
> On Nov 4, 2009, at 14:36, Lemuel Pitkin wrote:
> > OK. But the proposed mechanic doesn't address this. By limiting the
> > total HD a monster can summon, it eliminates the genuinely scary
> > summons, while leaving small mammal spam in place.
>
> I read the proposed mechanic to limit the number of summons by
> summoner HD. That should prevent mammal spam, though it does hurt
> boggarts badly. Though boggarts could easily be special-cased.
>
>
But why not address the problem directly? Identify the monsters that are
summoning too much, and reduce the frequency with which they cast those
spells.

Lemuel

On Wed, 4 Nov 2009, Lemuel Pitkin wrote:
> On Wed, Nov 4, 2009 at 12:06 AM, David Ploog <ploog@...> wrote:
>
>> Sure, but not if they spam. A single ancient lich being able to fill the
>> room in few turns with frightening monsters: good. A single vampire being
>> able to fill the room with rats: bad. Also, the tendency of monster
>> summoners to spam is very bad: it encourages level change, waiting out the
>> summons and having another go. It would be much better if monster summons
>> would summon in smaller batches and/or do other things in between.
>>
> OK. But the proposed mechanic doesn't address this. By limiting the total HD
> a monster can summon, it eliminates the genuinely scary summons, while
> leaving small mammal spam in place.
>
> Why not address the problem directly by simply reducing the frequency with
> which vampires cast Summon Small Mammals? Are there monsters other than
> vampires for which this is a problem?

Yes. Your very own demon (courtesy of Makhleb or Xom) may do this. That's 
why a general formula to keep summoning in check is desirable: it should 
work for all monsters, whether yours or enemies, and on all levels, not 
just vampires. I agree that boggarts get the short end of the stick, but 
that's exactly one special case.

David

2009/11/4 David Ploog <ploog@...>:
> On Tue, 3 Nov 2009, Lemuel Pitkin wrote:
>> The replacement for incredible healing ability is very weak (certainly
>> weaker than e.g. berserk, and with a much higher cost).
>
> Hm, may need to apply changes here. Ideas:
> 1) longer duration
> 2) stronger effect
> 3) cheaper piety cost
>
> Eino, what do you think? I'd be fine with ad hoc changes a la 1) and/or
> 3).

Hmm. Not sure, but I'd add food cost to the list of possibilities.
Pacification style requires keeping an eye on the hunger (I seem to
recall this vividly), and with HaHe, robusting cut my pacification
resources by making me quite hungry.

I guess I should look at playing with the numbers at some point! I
haven't done a non-pacifying ellyite though, that needs to be
considered too.

>> And life-saving from prayer is less useful than it looks on paper.
> Well, players did die under maximal piety before. Not having that happen
> anymore is a clear improvement.

I can never even remember the praying possibility, myself..

--Eino

On Wed, Nov 04, 2009 at 09:31:48AM +0100, jploog@... wrote:
> > commit 1bf203aaf578284d268fdca67c9d334a79a53c0d
> > Author: Matthew Cline <zelgadis@...>
> > Date:   Tue Nov 3 18:34:01 2009 -0800
> >
> >     Fixed MONS_NO_MONSTER == NUM_MONSTERS + 1
> >
> >     Fixed MONS_NO_MONSTER == NUM_MONSTERS + 1, which was a problem because
> >     MONS_NO_MONSTER can end up in savefiles, meaning that when
> >     NUM_MONSTERS increased old save files would become broken.
> 
> Doesn't adding new monsters break compatibility anyway, esp. seeing as we
> usually add them somewhere within an existing group (uniques, water
> monsters) etc.? Not that it's a bad change, just wondering.

Out of (possibly misguided) concern for reducing the frequency of save breaks
(and thus increasing the length of game you can reasonably play on the public
beta server) I've been adding most stuff to the end of various enumerations,
in the expectation of a Great Renumbering some time not long before 0.6.

Stefan

On Tue, Nov 3, 2009 at 10:09 PM, David Ploog <ploog@...> wrote:
> On Tue, 3 Nov 2009, Brett Scarborough wrote:
>
>> ... though this may change if some combat stuff I'm gonna play with in
>> December ends up being useful.
>
> Thank you.
>
> David
>

The general idea is to merge slays and weapon enchants, then lower the
overall effect (or the possible range) of them till I get something
acceptable that doesn't change the big weapon status quo too much
while giving a subtle boost to the small, fast weapons no one uses.
I'll probably start with replacing the current flat addition of slays
to 1d(slays+enchant) and fiddle with it from there till I get numbers
that feel about right.   That formula makes damage slays roughly half
as powerful as they are currently while ~doubling the effect of
enchants.

On Tue, 3 Nov 2009, Brett Scarborough wrote:

> The general idea is to merge slays and weapon enchants, then lower the
> overall effect (or the possible range) of them till I get something
> acceptable that doesn't change the big weapon status quo too much
> while giving a subtle boost to the small, fast weapons no one uses.
> I'll probably start with replacing the current flat addition of slays
> to 1d(slays+enchant) and fiddle with it from there till I get numbers
> that feel about right.   That formula makes damage slays roughly half
> as powerful as they are currently while ~doubling the effect of
> enchants.

This sounds like a very good agenda. Both aspects of it.

David

2009/11/4 David Ploog <ploog@...>:
> On Tue, 3 Nov 2009, Brett Scarborough wrote:
>
>> The general idea is to merge slays and weapon enchants, then lower the
>> overall effect (or the possible range) of them till I get something
>> acceptable that doesn't change the big weapon status quo too much
>> while giving a subtle boost to the small, fast weapons no one uses.
>> I'll probably start with replacing the current flat addition of slays
>> to 1d(slays+enchant) and fiddle with it from there till I get numbers
>> that feel about right.   That formula makes damage slays roughly half
>> as powerful as they are currently while ~doubling the effect of
>> enchants.
>
> This sounds like a very good agenda. Both aspects of it.

Agreed! One expects the weapon damage pluses to be more important than
they actually are, and indeed, slaying bonuses to work the same as
weapon pluses. So this also has spoiler-reducing effects on top of the
balance ones.

--Eino