Preparation for 4.1 release

[Nomad]

If you see any of the weird behaviour (and the torch still exists) a savefile would be helpful.

Okay, here's a savefile taken just after one of the buggy torches has gone out. The character still has the Wooden Torch (0 turns) equipped, and if you check back in the message history you'll see the "Your Wooden Torch has recharged" notification about half a dozen messages back.

[Pete Mack]

@Derakon--
That's not the reason. It's because it's so easy to kill hounds 1 on 1. Killing a dozen of them when only one can hit you (and at most two can breathe) is trivial. Killing them in a room is hard (except in a moat or checkerboard.)

[Derakon]

I've always found it strange that hounds stay in their rooms unless the @ is significantly wounded. Every hound is very well trained! Nonetheless, I understood it as a game necessity, so as not to overwhelm players with hounds continually hunting them down (especially in older versions when the hound packs were huge).

It's not so much to avoid overwhelming the player; the "smart packs" AI change was intended to make hounds harder to deal with because they wouldn't just stream towards you so you could pick them off one by one around a corner. Now you have to engage them in rooms, where there's more potential for things to go wrong and multiple hounds to get LOS on you. For example, if you fail to kill a hound in one turn, it can flee into the open room while a fresh hound moves in to attack you.

Hounds are also now a royal pain if encountered in long, straight corridors, as they'll happily pepper you with breath attacks while staying well out of melee range.

[Ingwe Ingweron]

This doesn't seem like a bug...

Unless there was a purposeful change in the behavior of hounds, then it is a bug. If the change was purposeful, what was the logic?

I've always found it strange that hounds stay in their rooms unless the @ is significantly wounded. Every hound is very well trained! Nonetheless, I understood it as a game necessity, so as not to overwhelm players with hounds continually hunting them down (especially in older versions when the hound packs were huge).

The new pathing has resulted in new behavior, where hounds stay in sections of rooms and force @ to be exposed to the entire pack at one time. If the change is meant to occur, than that's fine. Highly intelligent hounds, though.

[Pete Mack]

Nick--this should be easy to fix. Add the squelch check to the initial predicate. The only time the message should fail is if the drop actually fails because of insufficient space (and this can be fixed by giving the drop a Boolean return value.)

Nope, not fixed yet. One way to reproduce this would be to fight just around the corner of the moat, or in a small anti-summoning closet, to the side of an Ainur pit. If @ has ignored a lot of the possible drops, you will assuredly get the superfluous "rolls beneath your feet" message many times.

[Pete Mack]

This doesn't seem like a bug...

On the latest nightly (and noticed on the previous ones too), another pathfinding issue, this one with hounds. These nether hounds are awake, one found @, which was promptly killed, the other four will wait forever without coming to get @ unless he moves up into line of sight, even though he is in the "room". Have hounds lost there sense of smell? Or, has their definition of "room" been seriously circumscribed?

[Ingwe Ingweron]

I've also attempted a fix for the bogus "roll beneath your feet" message, but I'm not sure if it will be successful as that is hard to reproduce.

Nope, not fixed yet. One way to reproduce this would be to fight just around the corner of the moat, or in a small anti-summoning closet, to the side of an Ainur pit. If @ has ignored a lot of the possible drops, you will assuredly get the superfluous "rolls beneath your feet" message many times.

[Derakon]

if i (R)est for * time, can i rest until all my debuffs are over?

Currently * only rests until both HP and SP are recovered. It would be cool if i could rest out of blindness or slow.

Try resting for &, I think it does what you want.

[Ingwe Ingweron]

On the latest nightly (and noticed on the previous ones too), another pathfinding issue, this one with hounds. These nether hounds are awake, one found @, which was promptly killed, the other four will wait forever without coming to get @ unless he moves up into line of sight, even though he is in the "room". Have hounds lost there sense of smell? Or, has their definition of "room" been seriously circumscribed?

[Nick]

Here's a new crash. This is in top of tree a few days ago (g535565d):

Thanks for the details. Now I just need to work out how that could possibly have happened...

[Nick]

No. Ordinary bog standard Wooden Torches. Happens pretty frequently. Although, weirdly, sometimes it doesn't, and I still can't figure out what's different about those particular torches. It might be that it's only dungeon-found ones rather than inherited/town-bought? (Though I'd swear I have had it happen with the torch I start the game with sometimes.)

I can't seem to reproduce it by just taking a town-bought torch into the dungeon and resting for 5000 turns, unfortunately.

If you see any of the weird behaviour (and the torch still exists) a savefile would be helpful.

[kandrc]

Here's a new crash. This is in top of tree a few days ago (g535565d):

Program received signal SIGABRT, Aborted.
0x0000007fb7c77528 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x0000007fb7c77528 in __GI_raise (sig=sig@entry=6)
    at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x0000007fb7c789e0 in __GI_abort () at abort.c:89
#2  0x0000007fb7c70c04 in __assert_fail_base (
    fmt=0x7fb7d5d0c0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion@entry=0x545810 "!c->squares[y][x].mon", 
    file=file@entry=0x5457e0 "player-util.c", line=line@entry=870, 
    function=function@entry=0x545888 <__PRETTY_FUNCTION__.10919> "player_place")
 at assert.c:92
#3  0x0000007fb7c70cac in __GI___assert_fail (
    assertion=0x545810 "!c->squares[y][x].mon", file=0x5457e0 "player-util.c", 
    line=870, function=0x545888 <__PRETTY_FUNCTION__.10919> "player_place")
    at assert.c:101
#4  0x00000000004b08d8 in player_place (c=0x841908, p=0x799288, y=28, x=48)
    at player-util.c:870
#5  0x000000000043c96c in new_player_spot (c=0x841908, p=0x799288)
    at gen-util.c:354
#6  0x000000000042fe90 in lair_gen (p=0x799288) at gen-cave.c:2328
#7  0x0000000000427ddc in cave_generate (c=0x5748d8 <cave>, p=0x799288)
    at generate.c:898
#8  0x00000000004256d4 in run_game_loop () at game-world.c:999
#9  0x00000000004d69f4 in play_game (new_game=false) at ui-game.c:434
#10 0x000000000051bd80 in main (argc=1, argv=0x7ffffff408) at main.c:524
(gdb) up
#1  0x0000007fb7c789e0 in __GI_abort () at abort.c:89
89      abort.c: No such file or directory.
(gdb) 
#2  0x0000007fb7c70c04 in __assert_fail_base (
    fmt=0x7fb7d5d0c0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
    assertion=assertion@entry=0x545810 "!c->squares[y][x].mon", 
    file=file@entry=0x5457e0 "player-util.c", line=line@entry=870, 
    function=function@entry=0x545888 <__PRETTY_FUNCTION__.10919> "player_place") at assert.c:92
92      assert.c: No such file or directory.
(gdb) 
#3  0x0000007fb7c70cac in __GI___assert_fail (
    assertion=0x545810 "!c->squares[y][x].mon", file=0x5457e0 "player-util.c", 
    line=870, function=0x545888 <__PRETTY_FUNCTION__.10919> "player_place")
    at assert.c:101
101     in assert.c
(gdb) up
#4  0x00000000004b08d8 in player_place (c=0x841908, p=0x799288, y=28, x=48)
    at player-util.c:870
870             assert(!c->squares[y][x].mon);
(gdb) print c->squares[y][x].mon
$1 = 99
(gdb)

[Sky]

if i (R)est for * time, can i rest until all my debuffs are over?

Currently * only rests until both HP and SP are recovered. It would be cool if i could rest out of blindness or slow.

[Nomad]

Was it, or had it ever been, cursed?

No. Ordinary bog standard Wooden Torches. Happens pretty frequently. Although, weirdly, sometimes it doesn't, and I still can't figure out what's different about those particular torches. It might be that it's only dungeon-found ones rather than inherited/town-bought? (Though I'd swear I have had it happen with the torch I start the game with sometimes.)

I can't seem to reproduce it by just taking a town-bought torch into the dungeon and resting for 5000 turns, unfortunately.

[Nick]

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

• Healers now excluded from warrior pits
• Devices no longer get the {tried} label from a failed use
• Monsters with fire immunity can walk, and pathfind, through lava
• Lava gives the player a message when it is damaging them
• Lava actually damages the player every turn they're standing in it
• The show_damage option shows damage for throwing
• Artifact lanterns no longer claim to refill other lanterns
• Saving and reloading no longer shows extra info about distant items
• Inspecting un-wielded items no longer leaks info about unknown runes (like extra blows)

I've also attempted a fix for the bogus "roll beneath your feet" message, but I'm not sure if it will be successful as that is hard to reproduce.