PatR
e5180d1587
Reported by entrez: if magic whistle summoned a pet onto a trap, the messages produced could be in the wrong sequence or contradictory. The code was collecting counts and name-of-first for shift (was seen before whistling, seen at different spot after), for appear (wasn't seen before, now is), and for disappear (was seen before, now isn't) before dealing with a trap at arrival location. The trap could issue a message (including pet killed, pet sent away--teleport trap, hole, &c--or pet changed shape--which occurred after its name/old shape was saved for use when it was the only one in its category), and finally the summary message was issued. Change the code to handle arriving in a trap before the collection into the three categories that provide feedback, and skip the latter if any message was given during mintrap(). That handles the most glaring anomalies like killed followed by shifted location or takes on new shape followed by old shape shifted or appeared. But it no longer gives specific shift/appear/disappear feedback for those cases. Pets that don't land on traps or who land on ones that don't issue any feedback aren't affected. The accessibility aspect of this--message feedback in order to avoid tedious screen reading of the map--will need to be satisfied by the trap feedback unless/until someone comes up with a better solution. One possibility is an option to allow player to have rloc() always issue its vanish and appear messages. Right now it does so when magic whistle hasn't been discovered yet, then avoids that hyper-verbosity (if hero has multiple pets) once it has. Or the whistle code could count the number of pets first, then behave as if such an option is in effect when the count is small and only resort to the current summary method if the count is larger than some threshold.
122 KiB
122 KiB