4.0.2 Bugs

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

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

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

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

[PowerWyrm]

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

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

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

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

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

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

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.

[redlumf]

My variant just crashed while processing objects. Found out the following loop is faulty:

	while (obj) {
		struct object *next = obj->next; [B][I]<-- crashes here[/I][/B]

		/* do something */

		/* Delete the object */
		object_delete(&obj);
		obj = next;
	}

When leaving the loop, "next" being local to the loop is freed, "obj" points to nowhere...

Found the following occurences in 4.0.2 code:
- delete_monster_idx()
- monster_death()
- process_monster_grab_objects()
- push_object()
- project_o()
- store_maint()
- monster_death_stats()

Loop looks solid to me. The "next" is local, but is used as temporary store for the object pointer. It gets assigned back at obj prior to "next" going out-of-scope and thus deallocated from stack.

[Ingwe Ingweron]

When squelching coins, Creeping * coins are completely undetectable until @ tries to move into their cell.

This is true for all mimics, regardless of type. If you have "ignored" the item, its mimic will not show. This is, I believe, the desired behavior, although I do understand the frustration.

The reason it IS the desired behavior is that if the mimic were still visible even though the item is "ignored", the fact the mimic shows would be an information leak. E.g., one could, theoretically, approach a suspicious scroll and use the menu to ignore all scrolls. If the scroll were still there - it is a mimic.

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.

[Carnivean]

When squelching coins, Creeping * coins are completely undetectable until @ tries to move into their cell.

Potion mimics have the same problem I believe. I'd still propose that detect monsters shows that it is a monster. If it can find invisible monsters it should also be able to mimic monsters, as both are otherwise unseen. Squelching would only be a slight advantage, as non-squelchers would have the monster on their monster list.

[kandrc]

When squelching coins, Creeping * coins are completely undetectable until @ tries to move into their cell. A low-level mage who inadvertently melees a Creeping Adamantite coins is in trouble. Ordinarily, if I see a pile of coins that could be a monster that could kill me in a round or two (Creaping adamantite coins for a low-level mage), I attack it from range so that I can safely identify it, and have enough turns to kill it.

It's not clear what the solution to this should be. Perhaps detect monster discerns monster from real coins? But that would actually give a small advantage those who squelch coins, as all visible coins will be monsters, while for most, the game would revert to the old (as in a few years ago) behavior. Perhaps the solution is simply to restrict generation of coin monsters when coins are squelched. I can't see as that would actually change the game in any meaningful way.

EDIT: To be clear, this is most prominently an issue for low-level ironman games, because nobody else is squelcing coins, especially adamantite, in the early game; however, I expect that many, perhaps most, squelch coins in the endgame. There, you'll set up a battlefield, plan an escape route, and inadvertently lose a turn in a dangerous situation because you attack an undetectable monster.