5 May 2011 development release(s)

[Magnate]

Originally Posted by myshkin

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]

Originally Posted by 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?

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]

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]

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]

Originally Posted by Spacebux

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/b...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]

Originally Posted by 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.

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

In cmd-obj.c:

https://github.com/angband/angband/b...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.