Bugs and issues in 4.1.1

[Nick]

Got a crash which happens every time I read scroll of Dispel undead with the latest nightly.

save file is http://s000.tinyupload.com/?file_id=...80253232291461
randart file is http://s000.tinyupload.com/?file_id=...90753734449853

Hopefully that is what you need.

Thanks, I'll check that when I get a chance.

[PowerWyrm]

Ugh, it's not only crashing during combat, but also sometimes on level arrival after reading ?Deep Descent or descending stairs.

I've played a bit of PWMAngband and I also have the same crash since I implemented the change about player placement. @ seems to be generated at (0,0) sometimes (when I reload after the crash, @ is placed properly, but I can see a little mapped area on the top left corner) and I guess there's a "in bounds fully" check that throws an assert in this case. Probably the game doesn't manage to find a good location for player placement in some rare cases and defaults to (0,0).

[Nick]

New builds now up on the nightlies page, fixing the crashes (which, as usual, were not at all from what I thought).

Please test vigorously.

[PowerWyrm]

I've played a bit of PWMAngband and I also have the same crash since I implemented the change about player placement. @ seems to be generated at (0,0) sometimes (when I reload after the crash, @ is placed properly, but I can see a little mapped area on the top left corner) and I guess there's a "in bounds fully" check that throws an assert in this case. Probably the game doesn't manage to find a good location for player placement in some rare cases and defaults to (0,0).

Reproduced in debug mode. The crash is due to searching for secret doors while at position (0,0), which of course is not supposed to happen. I'll just need to find out why the @ is at (0,0) now...

[PowerWyrm]

Reproduced in debug mode. The crash is due to searching for secret doors while at position (0,0), which of course is not supposed to happen. I'll just need to find out why the @ is at (0,0) now...

Easily found... no up stairs were generated by alloc_stairs() on the next level, which of course was problematic when going downstairs. Checking V code, this should not happen in V because alloc_stairs() is coded slightly differently and doesn't allow the case.

[luneya]

Easily found... no up stairs were generated by alloc_stairs() on the next level, which of course was problematic when going downstairs. Checking V code, this should not happen in V because alloc_stairs() is coded slightly differently and doesn't allow the case.

Which is one of the reasons why I suggested that if we want to do safe player placement, the best way to do that is to leave alloc_stairs unchanged from 4.1.0, and instead place the player without any regard to stairs at all, generating an extra stairs at the player location in the case where the player arrived by connected stairs.

An additional benefit of reverting to the old alloc_stairs code is that the stairs could be placed anywhere on the level, so the player can't metagame the stair placement code in hunting for downstairs.

[PowerWyrm]

As mentioned in another thread, randart jewelry which fire stuff will not ask for a direction until completely IDed. IMO it should do so as soon as the effect is known, basically after the first activation.

[luneya]

As mentioned in another thread, randart jewelry which fire stuff will not ask for a direction until completely IDed. IMO it should do so as soon as the effect is known, basically after the first activation.

Interestingly, I did NOT encounter this bug with the not-fully-ID'd ring of digging that I mentioned earlier in the thread; I had full ability to control the stone-to-mud bolt despite the item remaining "marble ring." Moreover, it worked fine for both the original cursed digging ring, and the uncursed digging ring that I later found (and which still remained "marble ring" despite all of its runes being known). So if there is a remarkable bug to be found, it must be specific to the elemental rings. But hopefully, it's not an issue, as the change to make these rings known once their base runes are discovered should render this bug report irrelevant.

[Nick]

Interestingly, I did NOT encounter this bug with the not-fully-ID'd ring of digging that I mentioned earlier in the thread; I had full ability to control the stone-to-mud bolt despite the item remaining "marble ring." Moreover, it worked fine for both the original cursed digging ring, and the uncursed digging ring that I later found (and which still remained "marble ring" despite all of its runes being known). So if there is a remarkable bug to be found, it must be specific to the elemental rings. But hopefully, it's not an issue, as the change to make these rings known once their base runes are discovered should render this bug report irrelevant.

In fact, my first fix to the "Band of &Band~" problem could have potentially introduced this bug (along with others). Now that that fix has been fixed it should be fixed

[PowerWyrm]

Interestingly, I did NOT encounter this bug with the not-fully-ID'd ring of digging that I mentioned earlier in the thread; I had full ability to control the stone-to-mud bolt despite the item remaining "marble ring." Moreover, it worked fine for both the original cursed digging ring, and the uncursed digging ring that I later found (and which still remained "marble ring" despite all of its runes being known). So if there is a remarkable bug to be found, it must be specific to the elemental rings. But hopefully, it's not an issue, as the change to make these rings known once their base runes are discovered should render this bug report irrelevant.

The bug doesn't involve IDing the flavor of activatable jewelry, this is now fixed. It involves firing randomly until you have completely IDed the item. It doesn't happen with regular items, as the only ones concerned are the elemental rings, and since the only unknown property (resist element) is immediately learned as the ring activates for temporary resistance, you will have the ring IDed after the first try. Even if it's cursed, because curses now don't wount towards ID for jewelry. So the problem can only happen for randart rings and amulets with a targetable activation.

[Nick]

OK, new builds up (or nearly so) with a fix to the artifact direction thing. Let me know if there are any further problems with this or anything else.

[jevansau]

Build 2b9b84fd - no-selling - cannot donate a war hammer (3d3) (+6, +2) {??} with no known runes or curses to either the Temple or the Weapon Smiths.

[Sky]

This always applies when the curse makes the item value go to 0 or lower.