Bugs and issues in 4.1.0

[Estie]

Yes, scaling hp damage is necessary if you want "substantial but not lethal" damage on any level. (min depth for trapdoors is 2 in 4.1.0, btw.)
But hp damage is not my main concern. I even prefer to keep that low, to ensure that @ is unlikely to die from a trapdoor fall alone. It's the other plausible consequences of a fall that I find interesting: stunning/cutting and loss of inventory items.

My problem with vanilla trapdoors: once you are past the very early game, falling through a trap door is virtually equivalent to accidentally taking the stairs down in a game with unconnected stairs. The only difference is the hp damage, and that is barely noticeable. And because of that, trapdoors are boring, unless there are items on the level that you 'd really like to have.

As for porting out upon arrival, it may not matter a whole lot how far @'s hp is below hp_max, but being severely stunned is a relevant handicap if you rely on a spell or device to port out. Even more so with a reduced stack of curing/healing potions (due to breakage), a broken teleportation staff, and/or several inventory items (rods, books, scrolls, ...) spread out across the floor. Depending on what monsters are there, it can be a tough decision what to do first: pick up some of those items, quaff a potion to combat the stunning, or try to teleport out right away.
Thus, a trapdoor can serve as a believable game mechanic to bring @ in a situation that is more challenging - or at least less common - than most situations in his normal everyturn life.

As reflected by the phrase "porting out", escaping a tight spot in vanilla is usually easy and nearly synonymous with teleportation. One of my main goals for my own variant is to nerf that and to promote a more varied spectrum of escape methods. So teleportation will get nerfed by adding a side effect (similar to confusion) that can be prevented (at a cost) but not cured. Likewise, habituation will be a lurking danger with most potions. So that quaffing a potion to cure stunning becomes a decision instead of a reflex.

If that is where you are headed, why are you bothering with Vanilla at all and don´t move over to Sil ? It seems that would be much closer to what you are envisioning.

[Gwarl]

I also intend to add teleportation sickness to any variant I ultimately make.

[PowerWyrm]

I think what OP meant by needing demigod status to kill Morgoth is that Morgoth IS a demigod, so who else could kill him? The whole plot of LOTR was around how relatively ordinary (English)men (or hobbits) could defeat demigods by being clever and NOT trying to kill them in face-to-face battle.
Frodo and Sam certainly wouldn't survive a direct confrontation with Sauron.

Not sure about that... each time Sauron tried a face-to-face confrontation with anything (Huan, Ar-Pharazon, Isildur...), he got his ass kicked.

[PowerWyrm]

I'm sure, since the code in V does the same thing, that's also the case when, for example, a passwall monster aims at a @ in a room north of a permawalled vault:

#################
##...........@..#
##.########.....#
##.#######XXXXXXX
##.####P##XvaultX
##.....###XXXXXXX
#################

This should trigger the endless loop.

Confirmed with latest V (angband-4.1.0-41-gace666f). I have a game with the above layout, and Morgoth moves back and forth from one spot to the spot left of it.

See http://angband.oook.cz/screen-show.php?id=4434

[Nick]

Not sure about that... each time Sauron tried a face-to-face confrontation with anything (Huan, Ar-Pharazon, Isildur...), he got his ass kicked.

He made a mess of Finrod, though. Also Gorlim, Thráin and Gollum, but those weren't really fair.

[PowerWyrm]

Confirmed with latest V (angband-4.1.0-41-gace666f). I have a game with the above layout, and Morgoth moves back and forth from one spot to the spot left of it.

See http://angband.oook.cz/screen-show.php?id=4434

I tried to figure out a better way to handle pass/killwall monsters, but I didn't manage to come out with something simple. If you revert monster_near_permwall(), they will be blocked by vaults. If you allow them to use the new pathfinding system, they will try to find a better route, but will revert to the normal behavior once they're far enough from a vault.

The best I can think of is replacing the plain "any permawall two squares away" by "any permawall on the straight path to the player". In that case, the monster will use pathfinding first to get a clean route to the @, and then go straight for it.

[dreembeard]

If that is where you are headed, why are you bothering with Vanilla at all and don´t move over to Sil ? It seems that would be much closer to what you are envisioning.

Thanks for the tip. Maybe I 'll have a 2nd look at Sil then. I looked at it very briefly 5 years ago, and decided that I liked vanilla better. And since then, I've been taking notes on things I'd like to change in vanilla.

I just downloaded exe and src of Sil 1.3. It seems that development and forum activity stopped about 2 years ago. But I'll have a look at it anyway.

OTOH I've been scribbling down ideas long enough now. I don't fancy the idea of starting another round of note taking with Sil. But maybe I should stop ventilating ideas too, and focus on preparing for their implementation. Decide which source to start from, and try to find an adequate debugger.
That's where my last attempt of substantial development stranded. In gdb on V 3.2.0.

[dreembeard]

Um. Trap doors as currently exist serve two purposes:
* guaranteed escape like a stairs if you are standing on them. Helpful if you're picking a fight with an uncertain outcome like an ancient dragon that may or may not breath for big damage.
(...)

After beefing up trapdoor effects, they can still be used as escape routes of course. Just make sure that you wear those slippers of slow descent.

But I guess you're right if you meant to say that they are not totally boring.

[dreembeard]

I also intend to add teleportation sickness to any variant I ultimately make.

Just curious: were you inspired by flights in small airplanes too...?

-----
I vividly remember my barfbag over the Nazca lines.

[PowerWyrm]

Just curious: were you inspired by flights in small airplanes too...?

-----
I vividly remember my barfbag over the Nazca lines.

Nope, I think that's a Harry Potter reference.

[Sky]

the Dracolich (offscreen) breathes nether! You resist the effect.

ok, first off, i'm alive. don't worry. i had 18/200 CON and 800hp so i survived.

second, while i do get that "the effect" is XP drain, shouldn't this be "you avoid the effect" ? I don't resist nether, i don't see why this message should imply that i do.

[dreembeard]

tri-hued energy vortices

Detected energy vortices on dlev 21 with color changing (at subsequent detections) between light slate (#808080), light blue (#00ffff), and dark blue (#0040ff).

Edit:<some of the useless info removed; rest dimmed>
Looking at this again, it's a feature instead of a bug. But it's one I would rather not have. IIRC, multi-hued monsters used to flicker. Since 3.x, they just change color every player turn. Imo, that largely spoils the esthetic effect. It still has some information value for multi-hued breathers, but an energy vortex only breathes lightning, so having it show up with varying colors is misleading. Especially in detection. If @, who is immune to acid, steps into a room where he only detected a slate vortex, he'll be pissed off if he loses his poison resistance ring to lightning breath. And rightly so.

Re-edit: As Gwarl's reply reveals, this post was a bit of a blunder. The only correct part: With the animate_flicker option off, monster detection can be misleading for monsters with the ATTR_FLICKER flag (in that an energy vortex can look like a water vortex).

[Gwarl]

Man it's an option you change in the menu. Called shimmer_continuously or something.

[dreembeard]

Man it's an option you change in the menu. Called shimmer_continuously or something.

Ah, you're right. Stupid me.

[PowerWyrm]

The best I can think of is replacing the plain "any permawall two squares away" by "any permawall on the straight path to the player". In that case, the monster will use pathfinding first to get a clean route to the @, and then go straight for it.

Implemented in PWMAngband.

But this still doesn't work in some cases. Sometimes, the straight path moves the monster to a position where the straight path is blocked and pathfinding moves the monster back where it was, so there's still an endless loop. In that case, the loop must be broken by still continuing using pathfinding one more time.