5 May 2011 development release(s)

[takkaria]

I got it, I finally found the offending part of the code, but I still don't have an idea on how to fix it yet. This took me a while to sort out where all the commands are coming from / being sent in the code. Wow.

Well done for getting that far! Following the code there isn't that easy...

In cmd-obj.c:

https://github.com/angband/angband/blob/master/src/cmd-obj.c#L513

513 bool was_aware = object_flavor_is_aware(o_ptr);

This bool value calls object_flavor_is_aware() irregardless if o_ptr contains a NULL value, which is what it does when repeating to a command to Read a scroll that no longer exists on the floor.

Now, I have tried to work around this, but either way, I run into a segmentation fault if I purposely set was_aware to TRUE / FALSE. I might have screwed up the code elsewhere; in all my attempts to track down the command-train, I put in a bunch of msg commands.

-SBux-

OK, I've filed a bug using this information but it's going to take a while to fix. The correct fix is in game-cmd.c, you were right before, it needs a safety check to make sure all the relevant bits of the command are still valid when repeating it.

[Spacebux]

I got it, I finally found the offending part of the code, but I still don't have an idea on how to fix it yet. This took me a while to sort out where all the commands are coming from / being sent in the code. Wow.


In cmd-obj.c:

https://github.com/angband/angband/blob/master/src/cmd-obj.c#L513

513 bool was_aware = object_flavor_is_aware(o_ptr);

This bool value calls object_flavor_is_aware() irregardless if o_ptr contains a NULL value, which is what it does when repeating to a command to Read a scroll that no longer exists on the floor.

Now, I have tried to work around this, but either way, I run into a segmentation fault if I purposely set was_aware to TRUE / FALSE. I might have screwed up the code elsewhere; in all my attempts to track down the command-train, I put in a bunch of msg commands.

-SBux-

[bulian]

Sorry if these are silly questions but...

Have ?recharge been removed from stores?
More than 50% of levels i'm getting are "superb" - is this just to make sure that we completely ignore level feelings?
I've seen at least one staff with known flavors where the charges were displayed before picking it up, possibly after drinking ?enlightenment
All items are displayed in a "maze?" level upon creation

Other feedback -
The game does seem harder in general that it did the last time i played. good job?
The new level design changes the feel of the game but are pretty cool - caverns have seemed very frequent.
Not a single randart yet by DL 39

[Spacebux]

I'm trying to compile, but failing horribly at the moment:

game-cmd.c:

538 {
539 bool get_target = FALSE;
540 object_type *o_ptr = object_from_item_idx(cmd->arg[0].choice);
541
542 /* check for a null pointer list before proceeding. */
543 if (!o_ptr) break;
544
545 /* If we couldn't resolve the item, then abort this */
546 if (!o_ptr->kind) break;

-SBux-

[Spacebux]

I think I found it in game-cmd.c...

Not sure where to throw this, but in the May 7th nightly (r82a3cef40a), I still had a program crash using 'n' to repeat an action with a stack of items on the floor.

Looks like the bug is in game-cmd.c, line 540:

538 {
539 bool get_target = FALSE;
540 object_type *o_ptr = object_from_item_idx(cmd->arg[0].choice);
541
542 /* If we couldn't resolve the item, then abort this */
543 if (!o_ptr->kind) break;

I believe this is incorrect, as the code does not take into account that cmd->arg[0].choice could be NULL. It simply assumes the command references something that exists. The old 3.2.0 code is below, for comparison:

bool get_target = FALSE;

if (obj_needs_aim(object_from_item_idx(cmd->arg[0].choice)))
{

The old code correctly catches the condition. I don't know what if (!o_ptr->kind) break; catches, yet, but I bet it does not catch the case where cmd->arg[0].choice is NULL.

Apologies in advance if this is completely incorrect, as my C skills are quite feeble...

-SBux-

[Spacebux]

Stack-bug / Null Pointer dereferenced / Crash.

Not sure where to throw this, but in the May 7th nightly (r82a3cef40a), I still had a program crash using 'n' to repeat an action with a stack of items on the floor.

Looks the code is tripping up with Line 132 in object/identify.c with the expression o_ptr -> kind

I have not tried to debug this any further. I think the code is getting snagged there because if nothing is left on the floor, the object_type pointer ought to be referencing something akin to NULL at that point. Not sure where the code is calling that bool from, but the problem is probably stemming from an incorrect command processing sequence, ... somewhere in cmd0.c, but I haven't found it yet....

I think there was a ticket open for this, if so, I haven't double-checked to see if it was closed or not.

[Max Stats]

Branded ammo doesn't show extra damage

I have branded a few stacks of ammo with the spell from Tensers, but when I examine them, they do not say that they are "branded" nor does the damage rating show that they do extra damage to monsters susceptible to their element. They do, however, get named according to their branding, and they can't be re-branded with another element. Ammo that is created already branded seems to function normally.

Version string is v3.2.0-820-g49911e7-dirtybash-4.1. Savefile attached (affected ammo is in quiver slots n, p, and r).

[d_m]

Just a quick thank you to the developers. Amazing work on a great game.

Do you recommend porting a Level 48 to the developmental version (from the April 23rd nightly) or just finishing the game on the old one?

I would definitely recommend finishing with that character.

If you *do* decide to port, I'd also make a backup copy... not for cheating but for recovering from in case of an emergency.

[gudjkrist]

Just a quick thank you to the developers. Amazing work on a great game.

Do you recommend porting a Level 48 to the developmental version (from the April 23rd nightly) or just finishing the game on the old one?

[Magnate]

No need to spend effort here. I believe I've found and fixed the bug. But yes, your workaround should work between now and the next development release.

Thank you, that's excellent. I will merge the fix in a new nightly today. Apologies to all concerned. The one piece of good news is that I'm not going mad - there is indeed nothing wrong with the code in rd_item_2 that sets the flags, but myshkin found a stray return earlier on, which meant it wasn't getting there for non-wearable items. Doh!

[will_asher]

Why would STUPID and WEIRD_MIND make a monster immune to sleep? doesn't make sense. What's the point of the NO_SLEEP flag if you use a bunch of different flags to decide what is immune to sleep? If something should be immune to sleep, it should have that flag, otherwise it should be able to be put to sleep.

[myshkin]

I don't know, a paladin probably CL around 20 to 25. I could have been unlucky 4 times in a row before giving up. It might even have been just 3 tries, though I think it was 4 -- the only reason I tried multiple times was that I thought it might be wonder.

There didn't use to be much of a base resist. You were pretty much certain up to ML 11, and it was pointless beyond that. My original post was asking if there had been a change, rather than reporting it as a bug.

How long has a cutpurse had a save over 20%? It would surprise me that I did not notice.

Good question, and I didn't know the answer until I looked it up. The change in behavior appears to have entered the codebase at the end of January, with the merge of Jeff's monster pain messages patch (with some fixes from CunningGabe). Previously, immunity to sleep was governed only by the NO_SLEEP or UNIQUE flags; saving throw was 0 until level 11, and then was (mlvl - 10) in (clvl - 10). Now, immunity to sleep comes from NO_SLEEP, STUPID, EMPTY_MIND, WEIRD_MIND, and UNDEAD. Uniques get three saving throws (I think this is supposed to be two saving throws, but some code is duplicated). The saving throw is (25 + mlvl - clvl/5) in 100. The upshot is that it is easier to sleep high-level monsters than before, but much harder to sleep low-level monsters.

Jeff, if this is not what you intended, please comment.

[PowerDiver]

I'm having trouble reproducing this; I was able to ID-by-use a wand of confuse monster with a level 1 dwarf priest versus a small kobold at 50' on the first try. With what level character were you aiming the wand? The base resist chance for sleep monster wands versus cutpurses is 27%, minus 1% for every five player levels.

I don't know, a paladin probably CL around 20 to 25. I could have been unlucky 4 times in a row before giving up. It might even have been just 3 tries, though I think it was 4 -- the only reason I tried multiple times was that I thought it might be wonder.

There didn't use to be much of a base resist. You were pretty much certain up to ML 11, and it was pointless beyond that. My original post was asking if there had been a change, rather than reporting it as a bug.

How long has a cutpurse had a save over 20%? It would surprise me that I did not notice.

[Derakon]

If a monster can be asleep, then it should be sleepable. Therefore either mindless monsters should be sleepable or they should always start out awake. Given how marginal sleep-monster is already I'd lean towards the former.

[will_asher]

(White icky things, being STUPID, cannot be slept.)

So sleep monster was made even more useless than it already was?