Bugs and issues in 4.1.1

[Sky]

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

[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.

[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.

[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]

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

[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.

[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]

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]

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.

[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...

[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]

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]

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.

[mrfy]

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.

[Ingwe Ingweron]

4.1.2, 4.2 is still a long way off.

I've done a little testing and had one crash - looked mimic-related. Sounds like they shouldn't be too hard to generate

Don't know if it's mimic related or not. I can't get a savegame that reliably crashes everytime, but I have crashes developing in seemingly unrelated instances: upon level creation; in combat when hitting a monster whether or not it dies; in combat when firing missiles, whether or not the monster dies; when neither hitting nor firing, but monster moves. The deeper in the dungeon, the more often it happens.

You can probably use wizard mode to generate a @ take it to DL98 and stair scum probably less than 10 times to get a level creation crash. Don't know if that would also point to the solution for the combat or monster movement crashes.