4.0.2 Bugs

[Derakon]

Information leak bug. If @ quaffs an unidentified potion you can get the message something like, "Choose a direction..." Ah, that's !Dragon's Breath, but I shouldn't know that until after it's identified. And since I didn't choose a direction, it is just a "Light Brown Potion". Not sure of what the solution should be. I don't remember the problem existing in 3.5.1.

Pretty sure it existed in 3.5. Ditto with Identify scrolls/staves, which prompt for the item to ID.

[Ingwe Ingweron]

OK, I believe all outstanding bugs for 4.0.2 are either fixed (latest build will be up soon), or filed here. Note that I've confirmed the "too many Dracoliches" bug.

Information leak bug. If @ quaffs an unidentified potion you can get the message something like, "Choose a direction..." Ah, that's !Dragon's Breath, but I shouldn't know that until after it's identified. And since I didn't choose a direction, it is just a "Light Brown Potion". Not sure of what the solution should be. I don't remember the problem existing in 3.5.1.

[Nick]

OK, I believe all outstanding bugs for 4.0.2 are either fixed (latest build will be up soon), or filed here. Note that I've confirmed the "too many Dracoliches" bug.

[Nick]

ARROW_4: "thwang" (no idea if it's correct, it's spelled "twang" everywhere else)

I think a thwang is louder than a twang

CAUSE_4: idem (2x "DIE!".)

This looks OK to me - 'DIE!' is what the monster is saying, and it's in quotes because it's being referred to by the message.

[PowerWyrm]

The typo is in monster_spell.txt. There are other typos I'm currently reviewing, I'll note them all in a post.

And here we go:

- ARROW_4: "thwang" (no idea if it's correct, it's spelled "twang" everywhere else)
- BA_POIS: it was "creates a cloud of poison" in 3.5
- BA_WATE: it was "creates a whirlpool of water" in 3.5 (and "Something gurgles")
- CAUSE_2: missing punctuation (--> "points at you and curses horribly!")
- CAUSE_4: idem (2x "DIE!".)
- HASTE: "{name} mutters." (not when blind --> "Something mutters.")
- TPORT: missing "Something" ("Something makes a soft 'pop'.")
- S_KIN: "You hear something appear nearby!" (S_KIN is not limited to 1 --> "some things")

[PowerWyrm]

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.

The typo is in monster_spell.txt. There are other typos I'm currently reviewing, I'll note them all in a post.

[PowerWyrm]

As redlumf points out upthread, there is nothing wrong with this loop as such. My first guess for what would have caused a crash is that something else corrupted the object structure, so that obj->next became an illegal access.

Yeah my bad. Didn't reproduce the crash either after having fixed two occurences of object_delete called on inventory objects without doing a gear_excise first.

[Timo Pietilä]

I can neither reproduce this, or see why the code here should be failing. Any clues, or a savefile if it happens again, would be welcome.

I'm guessing that light actually goes out while digging, and it doesn't disturb the digging repeat, so immediately after digging is successful lights go out.

[nevermind, I just read the referred post and it talks about crash, not odd message sequence]

[AnonymousHero]

As redlumf points out upthread, there is nothing wrong with this loop as such. My first guess for what would have caused a crash is that something else corrupted the object structure, so that obj->next became an illegal access.

Since the API is already such that it can, I think object_delete should actually set the pointed-to-pointer to NULL[1]. In my experience it's a much more reliable way of causing an immediate bad access to fail rather than relying on something like ASAN/UBSAN/&c. Obviously, I realize that either is undefined behavior, but in practice NULL access is pretty reliable at causing an immediate failure as long as the compiler doesn't optimize it away[2].

[1] AFAICT from current master, it doesn't.

[2] There are actually some interesting cases of this in the Linux kernel which have caused security issues, but I don't think it's particularly pertinent to Angband, though it can obviously still happen and obscure other errors when using optimizations. The compiler is quite unlikely to be able to "peer through" object_delete

[Nick]

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

As redlumf points out upthread, there is nothing wrong with this loop as such. My first guess for what would have caused a crash is that something else corrupted the object structure, so that obj->next became an illegal access.

[Nick]

Crash bug in 4.0.2 windows version.

Digging through rubble. Light goes out the moment the digging is done.
Edit to add: Light source was a torch. Auto-pickup is on.

Assertion failed!
Program: ...
File: obj-pile.c
Line: 134
Expression: pile_contains(*pile,obj)

Last messages:

Your light is growing faint.
You dig in the rubble. <17x>
You have removed the rubble.
Your light has gone out!

I can neither reproduce this, or see why the code here should be failing. Any clues, or a savefile if it happens again, would be welcome.

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

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

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

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