5 May 2011 development release(s)

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

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

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

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

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

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

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-

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

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

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.

Thank you for doing that.. but, all my attempts to perform a NULL pointer check in game-cmd.c failed---which is what threw me off so often. The repeat command sequence is quite elusive in the code. While most of the commands are well-defined in game-cmd.h/.c, how the code handles 'n' is not trivial, in my opinion (as a weak C-coder).

Somehow, even if you put in checks in game-cmd.c, the code still circumvents those checks and repeats the command. I still haven't mastered the flow of the code yet to comprehend how "assert()" is still being called even if a I insert a check for a NULL pointer in game-cmd.c or even into cmd-obj.c ahead of that line. Maybe checking o_ptr is not the answer...?

-SBux-

[Spacebux]

Quaff crash.

BTW, I confirmed it also follows that quaffing a stack of potions off the floor will also get your the crash, since quaffing is also handled by the same generic do_cmd_use() routine.

[Spacebux]

Fixed!

Fixed. This fixes crashes from eating a stack of food off the floor, quaffing potions off the floor, and reading scrolls off the floor when pressing 'n' or CTRL-V when the item count reaches 0.


In cmd-obj.c, insert:

void do_cmd_use(cmd_code code, cmd_arg args[])
{

int item = args[0].item;
object_type *o_ptr = object_from_item_idx(item);
int effect;

if (!item_is_available(item, NULL, (USE_INVEN | USE_FLOOR))) {

msg("That item is not within your reach.");
return;

}
bool ident = FALSE, used = FALSE;
bool was_aware = object_flavor_is_aware(o_ptr);
int dir = 5;

Maybe that is not the best place for it, but that check prevents the code from going further, generating segmentation faults and worse.

-SBux-

[Magnate]

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

Oooh, well spotted - I think this is an obscure result of the object flags changes, because IIRC the ammo branding spell sets the ego type directly. Will check this.

EDIT: Yes - got it - thanks again. Fix will be in the next autobuilt version (but that might not be for a week or so).

[Max Stats]

Very minor message formatting issue

Playing current nightly, after dropping artifact:

> You drop The Lucerne Hammer 'Turmil' (2d5) (+10,+11) [+8] <+4> (t).
> You no longer have the Lucerne Hammers 'Turmil' (2d5) (+10,+11) [+8] <+4> (t).