Bugs and issues in 4.1.0

[dreembeard]

The realism of falling damage gets destroyed in a world where you take full health damage hundreds of times over in the course of a few hours. That, and it would have to be scaled somehow, since trapdoors can appear on level 1.

As for scaling, that could easily be achieved by making falling damage do a percentage of maxhealth, but whats the point ? The relevant aspects of trap doors would remain to be 1) the irreversible removal of the current level and 2) the possibility to land in a monster horde. If you have to port out, it doesnt matter much if you are at full health or low. Whatever demigod status @ has achieved wont be changed by increasing falling damage.

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.

[kandrc]

Just got this in current top-of-tree:

(gdb) run
Starting program: /home/sheaffer/angband/src/angband 

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6dcaff6 in strlen () from /lib64/libc.so.6
(gdb) bt
#0  0x00007ffff6dcaff6 in strlen () from /lib64/libc.so.6
#1  0x00000000004e94b8 in my_strcpy (buf=0x7fffffffd750 "\003", src=0x0, 
    bufsize=8) at z-util.c:174
#2  0x0000000000429b33 in get_chamber_monsters (c=0xc6a1e8, y1=7, x1=70, 
    y2=35, x2=102, name=0x7fffffffd750 "\003", area=957) at gen-monster.c:357
#3  0x000000000043111f in build_room_of_chambers (c=0xc6a1e8, y0=21, x0=86, 
    rating=0) at gen-room.c:2859
#4  0x00000000004314d7 in room_build (c=0xc6a1e8, by0=0, bx0=0, profile=..., 
    finds_own_space=true) at gen-room.c:2994
#5  0x000000000042526b in modified_chunk (depth=10, height=63, width=196)
    at gen-cave.c:1682
#6  0x00000000004257f2 in modified_gen (p=0x9a5958) at gen-cave.c:1785
#7  0x00000000004209c9 in cave_generate (c=0x7514e0 <cave>, p=0x9a5958)
    at generate.c:898
#8  0x000000000041e9bb in run_game_loop () at game-world.c:1001
#9  0x00000000004b2224 in play_game (new_game=false) at ui-game.c:435
#10 0x00000000004ea7b3 in main (argc=1, argv=0x7fffffffdbf8) at main.c:524
(gdb)

It's trying to copy the name of a pit type, but it seems the pit is invalid:

(gdb) up
#1  0x00000000004e94b8 in my_strcpy (buf=0x7fffffffd750 "\003", src=0x0, 
    bufsize=8) at z-util.c:174
174             size_t len = strlen(src);
(gdb) 
#2  0x0000000000429b33 in get_chamber_monsters (c=0xc6a1e8, y1=7, x1=70, 
    y2=35, x2=102, name=0x7fffffffd750 "\003", area=957) at gen-monster.c:357
357                     my_strcpy(name, dun->pit_type->name, sizeof(name));
(gdb) print dun->pit_type
$2 = (struct pit_profile *) 0x9a58d8
(gdb) print *dun->pit_type
$3 = {next = 0x0, pit_idx = 0, name = 0x0, room_type = 0, ave = 0, rarity = 0, 
  obj_rarity = 0, flags = "\000\000\000\000\000\000\000\000\000", 
  forbidden_flags = "\000\000\000\000\000\000\000\000\000", 
  spell_flags = "\000\000\000\000\000\000\000\000\000\000", 
  forbidden_spell_flags = "\000\000\000\000\000\000\000\000\000\000", 
  bases = 0x0, colors = 0x0, forbidden_monsters = 0x0}
(gdb)

And then it went on and tried to panic save, but of course, since it crashed while generating the dungeon, it crashed while saving it, too:

Program received signal SIGSEGV, Segmentation fault.
0x000000000049dc0a in wr_dungeon_aux (c=0x0) at save.c:763
763             wr_string(c->name ? c->name : "Blank");
(gdb) bt
#0  0x000000000049dc0a in wr_dungeon_aux (c=0x0) at save.c:763
#1  0x000000000049e218 in wr_dungeon () at save.c:931
#2  0x000000000049e952 in try_save (file=0xc4b428) at savefile.c:336
#3  0x000000000049ed44 in savefile_save (
    path=0x773840 <savefile> "/home/sheaffer/angband/lib/save/Sheaffer")
    at savefile.c:404
#4  0x00000000004d1abe in handle_signal_abort (sig=11) at ui-signals.c:203
#5  <signal handler called>
#6  0x00007ffff6dcaff6 in strlen () from /lib64/libc.so.6
#7  0x00000000004e94b8 in my_strcpy (buf=0x7fffffffd750 "\003", src=0x0, 
    bufsize=8) at z-util.c:174
#8  0x0000000000429b33 in get_chamber_monsters (c=0xc6a1e8, y1=7, x1=70, 
    y2=35, x2=102, name=0x7fffffffd750 "\003", area=957) at gen-monster.c:357
#9  0x000000000043111f in build_room_of_chambers (c=0xc6a1e8, y0=21, x0=86, 
    rating=0) at gen-room.c:2859
#10 0x00000000004314d7 in room_build (c=0xc6a1e8, by0=0, bx0=0, profile=..., 
    finds_own_space=true) at gen-room.c:2994
#11 0x000000000042526b in modified_chunk (depth=10, height=63, width=196)
    at gen-cave.c:1682
#12 0x00000000004257f2 in modified_gen (p=0x9a5958) at gen-cave.c:1785
#13 0x00000000004209c9 in cave_generate (c=0x7514e0 <cave>, p=0x9a5958)
    at generate.c:898
#14 0x000000000041e9bb in run_game_loop () at game-world.c:1001
---Type <return> to continue, or q <return> to quit---
#15 0x00000000004b2224 in play_game (new_game=false) at ui-game.c:435
#16 0x00000000004ea7b3 in main (argc=1, argv=0x7fffffffdbf8) at main.c:524
(gdb)

[Nick]

No idea the reason behind monster_near_permwall(), but this part of the code explains why Morgoth and all other passwall monsters seem to move erratically...

/* PASS_WALL & KILL_WALL monsters occasionally flow for a turn anyway */
if (randint0(99) < 5) return true;

This means 1/20 chance of using the "flow" code, which now means trying to chase the player via sound... which often means going backwards (KILL_WALL) or nowhere (PASS_WALL).

Maybe that line should just be removed.

[Pete Mack]

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.

[Derakon]

So how do we call this cruel concoction of yours then?

"Thwomp" comes to mind.

[dreembeard]

I chose the word "demigod" carefully, because we are, after all, planning to kill Morgoth, who is himself a demigod. It stands to reason that anything that can kill a demigod ought to be of roughly similar power, no?

But fair point that demigodliness does not necessarily extend to everything the character does. Maybe if we rephrased the trap? E.g. it's not a trap door, it's a pillar of stone descending from the ceiling and smashing you through the floor to the level below. That's the kind of thing that would absolutely give the player problems...and feather fall wouldn't do anything useful about it, hm.

That's true. Killing Morgoth really requires demigod status. At the very least.
For my own variant that's something I 'll probably change. As half did in Sil. But in vanilla, it's a fact to reckon with, of course.

So how do we call this cruel concoction of yours then? What about "punchcard trap"? Thus, it would fit in the existing category of "ancient mechanism" traps.
OTOH, if the rock pillar is pointy and shoots up through the floor instead of down, we could call it a pinup trap. That could be the start of a blossoming new category!

[PowerWyrm]

No idea the reason behind monster_near_permwall(), but this part of the code explains why Morgoth and all other passwall monsters seem to move erratically...

/* PASS_WALL & KILL_WALL monsters occasionally flow for a turn anyway */
if (randint0(99) < 5) return true;

This means 1/20 chance of using the "flow" code, which now means trying to chase the player via sound... which often means going backwards (KILL_WALL) or nowhere (PASS_WALL).

[PowerWyrm]

Can anyone confirm that KILL_WALL monsters properly pathfind the player in the latest version?

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

Hard to tell with a screenshot, would have been easier with a txt dump. This is PWMAngband, so I can't tell if this also happens in V.

@ started the level in the southeastern part of the screenshot, with a KILL_WALL monster on the "SP" line right to the door. @ then started moving north to its current position and activated the Arkenstone for clairvoyance. We can see from the starting monster position a little corridor heading southeast towards the initial position, then the corridor stops, the monster decided to go backwards through its own corridor in an attempt, I think, to take the existing corridor going up then right then down to the room where @ is standing. But after a couple steps northwest, the monster decided to dig through walls again, making a little S-shaped area. At this point, @ is simply pressing "5" over and over and the monster (the little white # on the "LAG" line) is moving back and forth between its position and the square to its northeast.

Note: the blue # 3 squares right to the monster is an ice wall, which is a permanent wall.

Here's what's happening in get_move_advance() when I use debug mode:
- step 1 (see screenshot): monster_near_permwall() returns false (permawall 3 squares east), passwall monster can aim directly at @, moves northeast
- step 2 (northeast of position): monster_near_permwall() returns true (permawall 1 square south 2 squares east), passwall monster uses regular pathfinding and aims back at corridor behind it, thus moving back southwest

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.

[Estie]

The realism of falling damage gets destroyed in a world where you take full health damage hundreds of times over in the course of a few hours. That, and it would have to be scaled somehow, since trapdoors can appear on level 1.

As for scaling, that could easily be achieved by making falling damage do a percentage of maxhealth, but whats the point ? The relevant aspects of trap doors would remain to be 1) the irreversible removal of the current level and 2) the possibility to land in a monster horde. If you have to port out, it doesnt matter much if you are at full health or low. Whatever demigod status @ has achieved wont be changed by increasing falling damage.

[Derakon]

I chose the word "demigod" carefully, because we are, after all, planning to kill Morgoth, who is himself a demigod. It stands to reason that anything that can kill a demigod ought to be of roughly similar power, no?

But fair point that demigodliness does not necessarily extend to everything the character does. Maybe if we rephrased the trap? E.g. it's not a trap door, it's a pillar of stone descending from the ceiling and smashing you through the floor to the level below. That's the kind of thing that would absolutely give the player problems...and feather fall wouldn't do anything useful about it, hm.

[dreembeard]

(...)The kinds of demigods we casually sling around in Angband -- people who are gearing up with loads of magical artifacts and implausible statistical enhancements -- should easily be able to survive such a fall. All they need do is straighten their legs, land feet first, and then dig themselves out of the impact crater.

In general I would caution against applying realism too liberally. Angband is a game, so we should apply realism where we think it will make the game more fun, not just for the sake of realism. How would vastly nastier trap doors make the game more fun?

I guess in the end it's a matter of taste. I agree that having a fun game comes first, before realism. But for me, the game would be more fun if my characters were a bit less demigod than they are now. Here and there.
I 'd still like to be capable of taking out a great wyrm single-handedly, and wipe out hordes of orcs as if I'm mowing the lawn, but getting cut/stunned and losing objects if I take a fall through a trapdoor would make the game more fun for me; not less. Especially if I survive the onslaught of awakened monsters that follows...

And for those who really prefer their characters to be demigods in every respect, we have debug mode.

[Nick]

New builds up on the nightlies page with the following changes:

• "Radius x light" only reported for light sources
• Buffer overflow in keymaps fixed
• A whole bunch of memory leaks (especially in unit tests) plugged, and a couple of compiler warnings dealt with

[Nick]

"Radius +light" is displayed for everything, not only lights. I think it should only be displayed for lights, as other items always have +1 light and "radius 1 light" is quite meaningless in that case. So instead of "remove +light", read "remove radius +light" in my comment, but just for non light sources.

Yes, on checking you're right, and you solution sounds sensible.

[PowerWyrm]

This is actually correct behaviour. The "+x light" refers to magical bonus to light (so, for example, Sting has +1 light); the "radius x light" line is only in descriptions of lights (ie things that go in the light slot). So lanterns say "radius 2 light" as they have that as an innate property, and it is possible that you might get an artifact lantern with +1 light, which would then say "radius 3 light".

"Radius +light" is displayed for everything, not only lights. I think it should only be displayed for lights, as other items always have +1 light and "radius 1 light" is quite meaningless in that case. So instead of "remove +light", read "remove radius +light" in my comment, but just for non light sources.

[Nick]

Items with +light both say "+x light" and "radius x light". Maybe remove the "+x light" line.

This is actually correct behaviour. The "+x light" refers to magical bonus to light (so, for example, Sting has +1 light); the "radius x light" line is only in descriptions of lights (ie things that go in the light slot). So lanterns say "radius 2 light" as they have that as an innate property, and it is possible that you might get an artifact lantern with +1 light, which would then say "radius 3 light".