Fix an interaction of fallback randarts and acquirement (12277)
authoradvil <rawlins@gmail.com>
Thu, 11 Jun 2020 19:03:48 +0000 (15:03 -0400)
committeradvil <rawlins@gmail.com>
Thu, 11 Jun 2020 22:16:27 +0000 (18:16 -0400)
commit7b83aa72e5150c5c73abd3a3f303e1689a9fe21b
treede335c1b71371ce0b97481f9724f1cadfc69bbf9
parent6eddd28265679e8ee1d430b8fc82912006bdbd0d
Fix an interaction of fallback randarts and acquirement (12277)

I hadn't fully understood one of the ways in which acquired objects
could interfere with unrand generation. After this commit, unrands that
place outside of levelgen (acquirement) or in the abyss or a trove
should always cause later instances of that unrand to simply be replaced
with a fallback randart, and have no other effect on item generation
during levelgen. Before this commit, unrands that were forced by vaults
would be correctly replaced with a fallback if they had already been
acquired, but unrands that were placed randomly (e.g. by | in a vault;
Slime:5 was a good place to check) could be affected by previous
acquirements in a way that had unpredictable results for those items.
I'm pretty sure that this bug had no impact on item generation (or
levelgen more broadly) outside of those specific grids.

This commit may change some seeds as I'm adding a subgenerator the will
impact certain rare cases of unrand placement (mainly for uniques who
can come with a special unrand). These uniques may need further testing.

No save compat for this, so upgrading will lead to the same behavior as
games from before this commit would have.

(cherry picked from commit 850bfe61e39c27fcdc3dcf3f7b28b0b55a6c1371)
crawl-ref/source/artefact.cc
crawl-ref/source/makeitem.cc
crawl-ref/source/unique-item-status-type.h