Angband 4.0 beta release

[MattB]

Slightly more seriously, it might help prevent some of the less computer-savvy Angband players (if there are any)

Believe me, there are - and I should know!

[Ingwe Ingweron]

Angband 4.0 dev badf0b1

Leaking information. Perhaps the fix for learning obvious effects from aiming wands at walls went to far? Just had a !CSW identified by quaffing even though @ not wounded and had no status ailment.

[AnonymousHero]

You should be able to use the -d option, so ./angband -dsave=~/.angband/Angband-4.0

I can't remember anything, much less to supply an option every time I invoke angband . Slightly more seriously, it might help prevent some of the less computer-savvy Angband players (if there are any) to avoid nasty surprises.

In fact, I'd actually like to extend this to just bumping the "save directory" revision number every time a save incompatibility is introduced. (Perhaps even in the very commit that breaks compatibility, but perhaps that might be going too far -- though I don't think it occurs that often, even in "master"?)

EDIT: Oh, and I didn't make the connection to this option and I (supposedly, at least) maintain a variant of T2. There's something to be said for "do the right thing by default".

[Ingwe Ingweron]

Angband 4.0 dev badf0b1

When pack is full, attempting to wield sling on the floor into the launcher position in inventory resulted in the current launcher being dropped to the floor, but the new launcher not being picked up from the floor and wielded. Had to command wield a second time to pick up and wield the new launcher.

[Gorbad]

@Nick: Just a little feature request: Would it be possible to get Angband 4.x to use a "~/.angband/Angband-4.0" (or similar) version-numbered directory for savefiles &c? It would be nice to be able to run both v3 and v4 in parallel for a while without having to muck about with file systems .

You should be able to use the -d option, so ./angband -dsave=~/.angband/Angband-4.0

[MattB]

Yes. Light flickers on and off. Actually, might be just the graphic display of light that is flickering. E.g., when in battle, between each message the light displayed cycles on or off. But can still use the look command to "see" the treasures dropped, so @ doesn't appear blind. Since my current @ has infravision, I'm not absolutely sure since @ can see monsters by their heat signature.

I'm still getting the 'you have no light to read by' message when the lights go off. I should add that I'm transferring savefile to each new nightly, so that may be screwing things up?

[AnonymousHero]

@Nick: Just a little feature request: Would it be possible to get Angband 4.x to use a "~/.angband/Angband-4.0" (or similar) version-numbered directory for savefiles &c? It would be nice to be able to run both v3 and v4 in parallel for a while without having to muck about with file systems .

[Ingwe Ingweron]

... Is the flickering light still happening?

Yes. Light flickers on and off. Actually, might be just the graphic display of light that is flickering. E.g., when in battle, between each message the light displayed cycles on or off. But can still use the look command to "see" the treasures dropped, so @ doesn't appear blind. Since my current @ has infravision, I'm not absolutely sure since @ can see monsters by their heat signature.

[Ingwe Ingweron]

Angband 4.0 dev badf0b1

When changing armor or weapons, in 3.5.1 there was a message, “you were wearing …" followed by, "You are wearing….”

Now there is only the “You are wearing…” message. Is this change intended? I found it helpful to see the “You were…” message as I quickly compared the two armors or weapons.

[Ingwe Ingweron]

Angband 4.0 dev badf0b1

Ignore/drop messages are out of order. E.g., i) pseudo-id and get message, “You feel the Robe (e) in your pack is average…”, ii) @ ignores all average Robes, iii) get message, “You have no more Robes [2,+0] {ignore} (e)", iv) get message, “You drop a Robe [2,+0] {ignore} (e)”.

The order of the "You have no more..." message and the "You drop..." message should be swapped.

[Nick]

Update badf0b1 fixes

• Stone to Mud ID
• Stat potions restoring first before increasing the stat
• ID-by-use for effects, plus making effect messages work properly
• Restore messages from Mushrooms of Vigor

Anyone seeing reports of the "Trying to drop something not held" bug? Is the flickering light still happening?

[Nick]

Most likely not a newly introduced bug then, just the existing issues with auto-ID of visible wand effects.

Amusingly neither newly introduced nor related to the other one. The StM issue is an easily-fixed typo; the lack of auto-ID is a consequence of the complete rewrite of effects code, so I'm now going through and making sure every object is ID'd correctly by its effect.

[Nomad]

Try using it on a monster. Wands on walls don't work, based on previous posts.

Oh, good thinking! (And I even reported that bug myself, whoops.) I always test wands by zapping them at a monster first, so it may be that on all the other occasions the Stone to Mud wands ID'd because there was a wall close behind the monster I aimed at and this time there wasn't. Most likely not a newly introduced bug then, just the existing issues with auto-ID of visible wand effects. (Though sadly I can't double-check because I've already ID'd the wand with a scroll.)

[Carnivean]

ID by use doesn't seem to be working on wands of Stone to Mud any more: I've zapped one at several walls and can see it making holes, but it still stays "a Silver-Plated Wand {tried}". Possibly a new bug introduced in one of the last couple of versions? I'm currently playing the latest, and haven't had this problem with Stone to Mud before.

Try using it on a monster. Wands on walls don't work, based on previous posts.

[AnonymousHero]

ID by use doesn't seem to be working on wands of Stone to Mud any more: I've zapped one at several walls and can see it making holes, but it still stays "a Silver-Plated Wand {tried}". Possibly a new bug introduced in one of the last couple of versions? I'm currently playing the latest, and haven't had this problem with Stone to Mud before.

A very helpful way to try to narrow it down if you're set up for compiling is to use "git bisect" on a couple of commit IDs, one of which you know is good and the latest commit ID (which presumably is bad). That'll let you narrow it down and you can then tell Nick exactly which commit broke it -- it usually helps developers immensely when users can do this.