Tweet
I was playing around with the summon random monster command debug mode (^as), trying to test something I was working on. I thought it was supposed to summon ordinary monsters, and ^an was for uniques. I was surprised when I kept getting uniques from ^as, so I debugged into it.
If I'm not mistaken it looks like the top level call in wiz-debug.c:
is passing a literal zero for the 4th parameter, which eventually gets written to summon_specific_type as the type to summon. There was probably once an assumption that type 0 meant ANY.
But because (I think) the parser is reversing the entries from summon.txt as it writes them to the fixed-size summons array, entry zero is not ANY as it probably used to be. Rather it's the last entry in summons.txt, UNIQUE. The result is that the code above always summons a unique as all the regular monsters get zero for their prob2 and prob3 values.
It's not clear to me how many other places in the code there is an assumption that type 0 means ANY, since I can't find any #defines for this, and there aren't any calls anywhere to summon_name_to_idx("ANY").
It looks from grepping like there's at least one: chests with a summon-monster trap might always summon uniques too. That would probably count as a bug (assuming anything having to do with debug mode could be blown off as working-as-coded).
A cheap and sleazy fix would be to move the ANY entry in summons.txt to the bottom and put in a comment saying it must be last. Or of course the parse could be changed to not reverse the entries by filling in the permanent array last-to-first as is done for some other things (and then add a comment to summon.txt saying ANY must be first).
If I'm not mistaken it looks like the top level call in wiz-debug.c:
Code:
effect_simple(EF_SUMMON, source_player(), "1", 0, 0, 0, 0, 0, NULL);
But because (I think) the parser is reversing the entries from summon.txt as it writes them to the fixed-size summons array, entry zero is not ANY as it probably used to be. Rather it's the last entry in summons.txt, UNIQUE. The result is that the code above always summons a unique as all the regular monsters get zero for their prob2 and prob3 values.
It's not clear to me how many other places in the code there is an assumption that type 0 means ANY, since I can't find any #defines for this, and there aren't any calls anywhere to summon_name_to_idx("ANY").
It looks from grepping like there's at least one: chests with a summon-monster trap might always summon uniques too. That would probably count as a bug (assuming anything having to do with debug mode could be blown off as working-as-coded).
A cheap and sleazy fix would be to move the ANY entry in summons.txt to the bottom and put in a comment saying it must be last. Or of course the parse could be changed to not reverse the entries by filling in the permanent array last-to-first as is done for some other things (and then add a comment to summon.txt saying ANY must be first).
Comment