4.0.2 Bugs

[kandrc]

So, one of the costs of the convenience of "ignoring" items is that occasionally you will run across a mimic that you won't know about until bumping into it or it casts a spell.

Having user interface convenience impact gameplay certainly should not be desired behaviour. Ignoring coins is a convenience for me, the human at the keyboard. Presumably,, my @ still sees them in the fantasy world; it does pick them up, after all. Claiming that getting attacked by them without ever detecting them is "desired behavior" is contradictory.

As another example of the utter badness of this, say an instadeath big breather is down the corridor and around the corner. @ has the speed to safely wait at TO, but insufficient HP or resists to engage. @ waits, breather enters LoS, @ uses TO, undetectable mimic is sent away, breather breathes, and @ dies.

A similar issue (UI convenience leading to gameplay instadeath) is the autosquelch+perception interaction. @ picks something up, explores, gets into situation where every turn counts, item is IDed and auto-dropped (which costs a turn) and @ dies. Either drop must be free, or it must not happen automatically (at least not by default). The tedium of explicitly dropping everything can be avoided by adding an expunge command that drops all ignored items (similar to what happens in town with "KK"; in fact, it could be used instead of the kludgey "KK").

Rule of thumb in HCI: When UI impacts use, it's indicative of bad design.

[Derakon]

A similar issue (UI convenience leading to gameplay instadeath) is the autosquelch+perception interaction. @ picks something up, explores, gets into situation where every turn counts, item is IDed and auto-dropped (which costs a turn) and @ dies. Either drop must be free, or it must not happen automatically (at least not by default). The tedium of explicitly dropping everything can be avoided by adding an expunge command that drops all ignored items (similar to what happens in town with "KK"; in fact, it could be used instead of the kludgey "KK").

The auto-drop is free, so you don't need to worry about this.

Rule of thumb in HCI: When UI impacts use, it's indicative of bad design.

Okay, let's turn this around: when the squelch UI can be used to detect mimics, it's indicative of bad design. A UI feature should not have gameplay interactions, sure, but that goes both ways: it shouldn't interfere with how you play the game, but it also shouldn't be abusable to gain knowledge that you shouldn't otherwise have. IMO there's no clear solution here; the current behavior is suboptimal, but so is allowing squelch to freely detect mimics.

[kandrc]

The auto-drop is free, so you don't need to worry about this.

Then there is a bug. I've witnessed it affecting gameplay on multiple occasions. For instance, if it kicks in immediately after detecting, you don't get to see the monsters. This is an obvious issue. I haven't been able to confirm whether it uses a turn, and I haven't dove into the code, but the detection certainly "disappears" and you have to recast (if you can). I've seen this multiple times. And I believe I've witnessed it costing me a turn in combat, but I'm not certain of that.

Agreed that players shouldn't be able to exploit the UI to detect mimics, but frankly, if a player wants to get skummy with mimics to win the game, more power to them. I've given a couple examples of how the current behavior can lead to instadeath. The easiest and most complete solution is to simply remove them from the game. I'm not actually advocating for that--they're cute and flavorful--but that would solve the problem. Perhaps see/detect invis could discern them?

[Nick]

Then there is a bug. I've witnessed it affecting gameplay on multiple occasions. For instance, if it kicks in immediately after detecting, you don't get to see the monsters. This is an obvious issue. I haven't been able to confirm whether it uses a turn, and I haven't dove into the code, but the detection certainly "disappears" and you have to recast (if you can). I've seen this multiple times. And I believe I've witnessed it costing me a turn in combat, but I'm not certain of that.

The detection thing is definitely a bug. I don't believe any of the other issues are - the auto-drop doesn't cost a turn, but picking up the item possibly could, which is a consequence of your pickup settings not ignoring as such.

[MattB]

Having user interface convenience impact gameplay certainly should not be desired behaviour. Ignoring coins is a convenience for me, the human at the keyboard. Presumably,, my @ still sees them in the fantasy world;

I argued exactly this a couple of years ago and Takkaria persuaded me I was wrong. His take was that if you squelch something, those things are beneath @'s notice. If you decide that @ doesn't see bronze coins then they no longer register in his consciousness. ("I've seen so many of them that I no longer even notice them.") If that pile of bronze coins bites his ankle on the way past, THEN you start noticing it!

[AnonymousHero]

I argued exactly this a couple of years ago and Takkaria persuaded me I was wrong. His take was that if you squelch something, those things are beneath @'s notice. If you decide that @ doesn't see bronze coins then they no longer register in his consciousness. ("I've seen so many of them that I no longer even notice them.") If that pile of bronze coins bites his ankle on the way past, THEN you start noticing it!

That's acutally pretty amazing reasoning and/or rationalization. (Depending on which side of the issue you fall on.)

[PowerWyrm]

More findings here, especially typos in help files: http://angband.oook.cz/forum/showthread.php?t=7196

[Ingwe Ingweron]

... the auto-drop doesn't cost a turn, but picking up the item possibly could, which is a consequence of your pickup settings not ignoring as such.

I don't think this is accurate. For instance, if @ picks up an unknown dagger and has the quality ignore settings set to "Excellent but not Splendid" for edged weapons, when auto-id kicks in and finds the dagger to be "average" then there is a cost of a turn when the item is automatically dropped from the @'s pack. Similarly, if @ ID's an item in the pack and the ignore settings are on for that item, it costs a turn when the item is automatically dropped from the pack. Contrast the situation when @ ID's an item on the floor. If the ignore settings are on for the item, it disappears without the cost of turn.

I believe this behavior is appropriate. Dropping items from the pack should require a turn. Just because a player uses the convenience of "ignore" settings, does not mean the player should get a free turn when dropping an item. Sure, if auto-id kicks in during melee it could mean a bad day when @ has to absorb an extra blow, but that's the chance you take when you use ignore settings. Personally, it's worth the risk and by the time @ is up against things where that move might matter, pretty much everything is already identified.

[takkaria]

I argued exactly this a couple of years ago and Takkaria persuaded me I was wrong. His take was that if you squelch something, those things are beneath @'s notice. If you decide that @ doesn't see bronze coins then they no longer register in his consciousness. ("I've seen so many of them that I no longer even notice them.") If that pile of bronze coins bites his ankle on the way past, THEN you start noticing it!

I stand by this! It still seems like the most elegant solution to the problem. It's either that or disable squelch for items that can be mimicked, IMO...

[Werbaer]

Potential crash bug in 4.0.2 with the note command (':') when using the '%' sign in the note text.
Windows version (others may behave different.)

Examples:

:Using Aglarang over Pain. 5% less damage.
(in messages window): Using Aglarang over Pain. 5 3.049216e-307ss damage.
(in player history): Using Aglarang over Pain. 5% less damage.

:Now 5%% more
(in messages window): Now 5% more
(in player history): Now 5%% more

:5% speed
--> program terminates

It looks like the user input is used in a printf funtion as argument. '%%' becomes %, and '% le' wants to print a long int in scientific notation, and '% s' tries to print a string and fails.

[Nick]

It looks like the user input is used in a printf funtion as argument. '%%' becomes %, and '% le' wants to print a long int in scientific notation, and '% s' tries to print a string and fails.

Nice catch.

As I mentioned in another thread, I have been mostly out of action for the last three weeks or so, but hope to be back fixing some of these soon - especially since PowerWyrm has definitely not been out of action.

[Timo Pietilä]

I stand by this! It still seems like the most elegant solution to the problem. It's either that or disable squelch for items that can be mimicked, IMO...

Which would then leak information about which items can be mimicked.

You could make mimic mimic item that isn't previously known by giving them always random flavor, and only make mimics for things that have a flavor. That would prevent them to be squelched.

It would also make mimic "interesting", because unknown is something you want to investigate.

[kandrc]

I stand by this! It still seems like the most elegant solution to the problem. It's either that or disable squelch for items that can be mimicked, IMO...

We have an inherent problem of too much junk. We put a patch on that in userspace by allowing the user to choose to squelch display of certain junk. This is not elegant; it's expedient (and there's nothing wrong with that).

The expedient solution creates a situation where mimics become less mimicy. Rationalization about @ becoming so godlike that these mimics are beneath his notice is similarly expedient and far from elegant and can lead to instadeath, not to mention that it flies into the face of 30+ years of UI research.

To make matters worse, @ still picks up squelched coins that he walks over. You can't in one breath claim that they're beneath his notice and in the next make him pick them up.

An elegant solution would be one that doesn't violate the UI abstraction and also doesn't expose mimics.

Which would then leak information about which items can be mimicked.

You could make mimic mimic item that isn't previously known by giving them always random flavor, and only make mimics for things that have a flavor. That would prevent them to be squelched.

It would also make mimic "interesting", because unknown is something you want to investigate.

This is elegant. Players will crack vaults they may otherwise avoid for a new ring type. They'll at least cross the dungeon for a new scroll.

And if we love coin mimics, replace creeping coins with another type of mimic when players squelch coins; ideally with a more powerful, unsquelched coin type, and failing that, with a different type of mimic entirely. Admittedly, this is not elegant, but it's certainly better than the status quo.

I believe this behavior is appropriate. Dropping items from the pack should require a turn.

I've also confirmed that dropping and squelching (auto-dropping) use turns, and I agree that it's appropriate. What's bad is that it happens non-deterministicly. A UI streamlining that can kill @ is bad; I don't think there's anybody here who would argue against that. If players want to lose turns in melee to drop stuff, all well and good, but I think that should not be the default behavior. Add a command to drop all squelched items and an option to toggle auto-drop.

[yyt16384]

Sometimes the number of enemies in messages gets more than the actual number when you hit multiple targets. In my particular case, it shows "5 Dracoliches shrug off the attack" when there are only 2 of them.

I was using meteors but I think I have probably seen this before for other ball attacks. I'm not sure about beam attacks, though.

I haven't figured out when it will happen, but here is the savefile I was playing. Just hit the Ds with meteors and you will see this happening.

[Rowan]

Just now I got a message with no subject, that said:

makes a soft 'pop'.

I'm used to it saying "Something makes a soft 'pop'," when it's about an unseen monster. I don't know much about programming- is this just a case of the message not having an assigned value because the monster is offscreen?

DLvl 39; it could have been any number of things teleporting/phasedooring as I approached a big, dark room. Seems minor, but thought I'd report it since I don't see anyone mentioning it yet.