Angband 4.0 beta release

[Nick]

Not sure if the battle crash reported here was fixed in the latest iteration. It wasn't one of the listed conditions.

http://angband.oook.cz/forum/showpost.php?p=100276&postcount=306

EDIT: I'll let you know if I find another one in the current version.

No need - I have just confirmed that it does fix that crash (if you're wondering how the story ends, the vampire dies and drops stuff )

[Ingwe Ingweron]

Angband 4.0 dev ac26dbd

Are enemy Mana Bolts now super-powered?

Just ran into Baphomet and the monster description shows he can cast a mana bolt for 1566 damage! Checking out some of the other monsters:

Sauron and Morgoth: Mana Storm (1600) same as Mana Bolt (1600)

That's messed up.

[Ingwe Ingweron]

Not sure if the battle crash reported here was fixed in the latest iteration. It wasn't one of the listed conditions.

http://angband.oook.cz/forum/showpost.php?p=100276&postcount=306

EDIT: I'll let you know if I find another one in the current version.

[PowerWyrm]

See http://angband.oook.cz/forum/showthread.php?t=7196: ice attacks don't check vs cold resistance anymore.

[Nick]

I am going to make some big claims. Please shoot them down if they need it.

Update ac26dbd fixes

• Some more randart power discrepancies found by myshkin after lots of careful work
• Crashes from opening chests
• Crashes from shooting lots of arrows
• Crashes from wielding stuff off the floor

So it turns out that there were two things going wrong.

1. If something was wielded off the floor, and the player was carrying something similar, the floor item would be absorbed into the carried item, and the game couldn't find it to wield - my fix to this has demonstrably fixed Ingwe's =Digging crash
2. As myshkin diagnosed, something could be dropped (or fired, or spewed out of a chest) and absorbed into a similar item on the ground, and the game then couldn't find it to check for ignoring.

Both these are now (I believe) fixed. In fact, I don't know of any reported crashes which can't be explained by these, so please report any time the game crashes from here on.

Thanks to everyone for their patience, and especially to myshkin for doing most of the work

[Nomad]

Light radius does not show up on the Inspect screen for an equipped but not yet fully identified randart. When I put it on I get the message "You feel healthier! It glows!" and I can see from the C screen that it's marked as having Light, but the Inspect screen only shows the +1 constitution, no mention of the +1 light.

[myshkin]

Angband 4.0 dev 9f6ea01

I think I have another replicable battle crash. Fighting Medusa, use the arrows of Slay Evil, inscribed @f1=g, and target her with the "*" key and "n" thereafter. Usually, within the first few shots, if not the first shot, there's a crash. This is on MacOSX. [ATTACH]1214[/ATTACH] "f1*t (1st shot successful) n (CRASH)"

I was able to reproduce this crash on OS X, but not on Linux. Again the kind struct is garbled. I think the OS-specific issues are simply that the memory allocators behave somewhat differently. Near as I can tell, what happens on OS X:

• The first arrow fires and lands at the feet of the player.
• The second arrow fires and tries to land at the feet of the player. ranged_helper() calls drop_near(), which calls floor_carry(), to carry this out.
• floor_carry() notices that the grid contains an object with which it can combine its drop argument (the second arrow), and calls object_absorb() to make them a single stack.
• Unfortunately, object_absorb() calls object_delete() on the second arrow after creating the stack of two arrows.
• Back in drop_near(), we check to see whether the item is ignored, in order to determine whether to say, "You feel something roll beneath your feet." ignore_item_ok() on the second arrow fails, as it eventually tries to access the flavor of the object, cleared away by object_delete().

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x000000010006d2d7 in object_flavor_is_aware (obj=0x108931a98) at obj-identify.c:170
170		return obj->kind->aware;
(gdb) bt
#0  0x000000010006d2d7 in object_flavor_is_aware (obj=0x108931a98) at obj-identify.c:170
#1  0x0000000100071910 in object_is_ignored (obj=0x108931a98) at obj-ignore.c:545
#2  0x0000000100071a82 in ignore_item_ok (obj=0x108931a98) at obj-ignore.c:579
#3  0x000000010007cf5e in drop_near (c=0x10895e6d8, j_ptr=0x108931a98, chance=35, y=31, x=101, verbose=true) at obj-pile.c:871
#4  0x0000000100091ba1 in ranged_helper (obj=0x10895e5a8, dir=5, range=12, shots=2, attack=0x1000910c0 <make_ranged_shot>) at player-attack.c:641
#5  0x00000001000910ba in do_cmd_fire (cmd=0x100167fb0) at player-attack.c:759

[myshkin]

Angband 4.0 dev aa62c4d

Was able to find another almost identical situation with a ring of digging which causes a replicable crash bug. Wielding a ring of digging from off the floor (not to be confused with the one in @'s pack). "[w]ield" "-"floor "a" item "d" right ring slot "CRASH". If instead @ simply picks up the ring, it is auto-id as a Ring of Digging <+5> and added to the one in @'s pack. [ATTACH]1216[/ATTACH]

This is using OSX, so like the previous crash bugs I've submitted, it might not crash on other platforms.

How did this ring get on the floor? Was it created at level creation time? I get a crash on both OS X and Linux.

OS X stack trace: (obj->kind is an inaccessible pointer; the rest of the struct looks okay)

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x000000010006d2d7 in object_flavor_is_aware (obj=0x109f62b68) at obj-identify.c:170
170		return obj->kind->aware;
(gdb) bt
#0  0x000000010006d2d7 in object_flavor_is_aware (obj=0x109f62b68) at obj-identify.c:170
#1  0x000000010006eab9 in object_notice_on_wield (obj=0x109f62b68) at obj-identify.c:716
#2  0x000000010000dfd0 in wield_item (obj=0x109f62b68, slot=3) at cmd-obj.c:389
#3  0x000000010000e373 in do_cmd_wield (cmd=0x100167fb0) at cmd-obj.c:491

Linux stack trace (the entire kind struct is garbled):

Program received signal SIGSEGV, Segmentation fault.
0x00000000004b9053 in object_kind_char (kind=0x7fd93ce368d8 <main_arena+376>)
    at ui-object.c:109
109             return use_flavor_glyph(kind) ? flavor_x_char[kind->flavor->fidx] :
(gdb) bt
#0  0x00000000004b9053 in object_kind_char (
    kind=0x7fd93ce368d8 <main_arena+376>) at ui-object.c:109
#1  0x00000000004b90aa in object_char (obj=0x311b1a8) at ui-object.c:130
#2  0x00000000004a3e46 in prt_equippy (row=7, col=0) at ui-display.c:269
#3  0x00000000004a478d in update_sidebar (type=EVENT_EQUIPMENT, data=0x0,
    user=0x0) at ui-display.c:569

[Ingwe Ingweron]

Angband 4.0 dev 2c2bb6c

Crashed opening a chest. The OS crash has me so frustrated at this point. I think maybe it's time for me to take a break for a month from Angband.

[Nomad]

Both still seem to be working for me. What's happening for you?

All right, after some fiddling around I've figured out what happened, and it's not a newly introduced bug after all, just some mildly weird/inconsistent behaviour that pops up in specific circumstances.

* If you use the k command and select "this item only" to ignore something, you can use k again to unignore, no problem.
* On the other hand, if you use k and select the category option ("All average Blunt melee weapons" or whatever), you cannot unignore using k, but will just get the same ignore options again.
* If you foolishly think, "Hey, maybe the 'ignore' bit is just a typo and choosing 'this item only' will unignore it like I want", you will cause the item to enter a state of being "double-squelched", that is, ignored under the 'this item only' rule and the 'All average Blunt melee weapons' rule at the same time.
* Once it's double-squelched, if you try k again, the unignore option comes back, but selecting it will not cause the item to reappear, because you've only unignored the individual item - it's still squelched by the "All average Blunt melee weapons" rule. (Similarly, if you try to change the quality squelch settings to 'no ignore', that won't get your double-squelched item back because it's still squelched as an individual item.) So you have to do both before it's completely unsquelched and visible again.

(It appears that none of this is actually new - you get the same behaviour in 3.5, though I'm not sure about earlier versions.)

The !k problem is also slightly more complex than I first thought.

* If you inscribe a not-yet-ignored item !k and then try to squelch it with k, you'll be prompted to make sure you want to. If you squelch its category with the quality squelch settings, it will be spared. So far so good.
* If, however, you use K to temporarily reveal previously ignored items and inscribe one of them !k, that doesn't work. As soon as you hide ignored items again, the inscription will change to {!k, ignore} and it will just drop to the floor and be squelched.
* The same also applies if you choose (y)es at the "Really do that?" prompt to squelch a !k-inscribed item. Once you've okayed squelching it once, the !k inscription is 'broken' and it becomes a {!k, ignore} item, and you won't be able to keep hold of it until you've manually unsquelched it using k and/or quality squelch.

(Unlike the squelching behaviour above, this is new to 4.0. Items inscribed !k are never dropped/squelched in 3.5 regardless of circumstances.)

So, er, that's what's happening, basically. Clear as mud?

[Estie]

For example: I squelch average diggers (ksb, where s is the letter of my shovel, and b is for the "all average diggers" prompt). The shovel vanishes. I press K (to show squelched items), pick up my shovel {squelched}, press ks again (kill, select s - shovel), and now there used to be an usquelch option, but its only asking me again if i want to squelch a) this item or b) all average diggers.

Option b) used to be "Do you want to UNsquelch average diggers" (or similar, my emphasis).

http://expirebox.com/download/f2ff64cce41552abc66ec69ccc8cf704.html

^ that should hopefully be the savefile.

[Nick]

I don't see any silly randards any more but are randart shooters really supposed to be so powerful? I find +2 shooting speed AND +2 shooting power a lot, especially since these are not replacing the epic items.

This has been fixed by myshkin in update 2c2bb6c, which will be up shortly is up now.

[Nick]

Huh - this seems to have changed between the April 19th version and today's: unignore is still there as an option in 5a6bbf0. (Inscribing individual items with !k also seems to be broken, although it doesn't work in 5a6bbf0 either so I don't know if it was ever actually functional in 4.0.) As a temporary stopgap you could inscribe the item with !d and pick it up.

Both still seem to be working for me. What's happening for you?

[Nomad]

How do I unignore items ?
Old behaviour was that ignoring an ignored item offered to unignore it. Now there is only the same ignore routine again.

Huh - this seems to have changed between the April 19th version and today's: unignore is still there as an option in 5a6bbf0. (Inscribing individual items with !k also seems to be broken, although it doesn't work in 5a6bbf0 either so I don't know if it was ever actually functional in 4.0.) As a temporary stopgap you could inscribe the item with !d and pick it up.

[myshkin]

I don't see any silly randards any more but are randart shooters really supposed to be so powerful? I find +2 shooting speed AND +2 shooting power a lot, especially since these are not replacing the epic items.
Who would choose Paurmimmen before Bragor below? These examples are all from the same game.

These randarts resulted from another unintentional change, this one in the object power code. The valuation algorithm was adding the number of extra shots to the object's value instead of multiplying the value by the total number of shots, as in 3.5. I've submitted a fix.