Bugs and issues in 4.1.0

[PowerWyrm]

http://trac.rephial.org/ticket/2028

I was trying to get sound to work based on the bug report above.

It appears that moving the MINGW=yes in front of the command did not resolve the GCC related error.

I'm probably a bit in over my head as I think there are multiple things I need to learn about and check. I won't have much time during the week so I may return to this at another time - thanks though.

You try to compile using MinGW directly under Windows. This will not work. You'll have to download MSYS tools and use the shell. Then using "./configure --prefix=/mingw" and "make" from the Angband folder should be enough to autocompile Angband.

[luneya]

In the attached 4.1.0 savefile the Black Market is selling a Ring of Strength which is not fully identified — pval is not shown, and 'x' tells me "You do not know the full extent of this item's powers". There appears to be no way of determining the pval of the ring without buying it.

Or is this a new feature of the Black Market?

The way it currently works is that if you know the rune corresponding to the property in question (in this case, strength bonus), you'll be able to recognize the value of the modifier on appearance. If you don't know the rune, you won't recognize the modifier. Shops are currently coded to tell you what item you're looking at even if you don't recognize it, but not to give that other data. Whether that design is intentional or a bug is a question for Nick to answer. But it's certainly not a behavior specific to the BM; you'll see the same thing happening when the magic shop has rings of searching for sale.

[Nick]

The way it currently works is that if you know the rune corresponding to the property in question (in this case, strength bonus), you'll be able to recognize the value of the modifier on appearance. If you don't know the rune, you won't recognize the modifier. Shops are currently coded to tell you what item you're looking at even if you don't recognize it, but not to give that other data. Whether that design is intentional or a bug is a question for Nick to answer. But it's certainly not a behavior specific to the BM; you'll see the same thing happening when the magic shop has rings of searching for sale.

Yes, thanks, that's it exactly. I wouldn't exactly say it's intentional, but it's the logical way for it to work in the new system.

[PowerWyrm]

New builds now available for Windows and macOS (nightlies page is currently having some issues). Changes are

• Fix to off-by-one error which was preventing the last object of a given type ever being a randart - most notably arkenstones, but also mattocks, ethereal cloaks, etc
• Improvements (I hope) to pathfinding. I have taken PowerWyrm's analysis into consideration, but my changes aren't precisely the suggested ones. Feedback from PowerWyrm or anyone else very welcome.

There's still one problem: often, two paths with the same noise are available and the one selected is always the one processed first (using the "ddd" arrays). If that path is a dead end and @ waits in the other path, the monster will walk to the dead end, turn back, walk back to the intersection and take the same path again. In PWMAngband, I've fixed that by using an array of available directions and choosing a random one if there are two or more.

[PowerWyrm]

Just to be nitpicky, there's a mix of uses of "c" parameter and "cave" global in get_move_advance().

[PowerWyrm]

In monster_turn_can_move(), the check for "monster hates grid" has been pushed after the test for passable terrain, and therefore does nothing since "hated" grids are also passable.

[passer_by]

Yes, thanks, that's it exactly. I wouldn't exactly say it's intentional, but it's the logical way for it to work in the new system.

Thanks for the explanations. But now I'm wondering what happens when the store has an artifact or one of the ego-items which has a random resist/sustain? It sounds like you wouldn't know what powers the item has when it's in the store, but when you buy the item you suddenly learn the relevant rune(s) anyway?

(apologies if this has been covered in another thread, I can't think of a reasonable way to search for previous discussions).

[skydyr]

This is a known problem; I don't think we have any idea of how to fix it though.

Regarding this compiling problem with -r and -pie can't be used together, it seems that Debian and derivatives ship gcc6 with -pie enabled by default as a security feature. The flag has to be explicitly disabled with the -no-pie switch in order for the build to function properly.

I've been able to get it to compile by adding -no-pie to the linking command in src/Makefile after configuration as follows:

$(PROGNAME).o: $(OBJECTS)
$(LD) -no-pie -nostdlib -Wl,-r -o $@ $(OBJECTS)
@printf "%10s %-20s\n" LINK $@


That said, I'm not exactly certain of the security implications of this, but I can't imagine it's any different from prior to this feature being enabled by default. It may be worth looking into how to use this feature with the linking correctly, but that is beyond me at the moment.

It may also be possible to remove the -r flag instead, but I think that's only doable for the final linking into the angband executable.

[wobbly]

Are morgul weapons meant to auto-id the sinv rune? Wormtongue dropped a warhammer & on wield I learnt sinv & drain xp (I already knew poison). There is nothing invisible in sight.

v4.1.0-20-g36595ad-dirty on angband.live

[skydyr]

running doesn't stop on edge of detected area

While I understand that not explicitly marking the edges of detected areas was a design choice, it seems a flaw that running doesn't stop at the edge of detected areas. There is still a notice at the bottom of the screen to determine if you are in a detected area or not, so removing this disturbance from running seems like it just makes running less safe with no other gameplay change.

I'd recommend either re-enabling this (my preferred option) or removing the notice of whether an area has been searched or not altogether. Removing the notice also seems like it would be problematic and not keeping in line with the play style of vanilla.

[Nick]

Regarding this compiling problem with -r and -pie can't be used together, it seems that Debian and derivatives ship gcc6 with -pie enabled by default as a security feature. The flag has to be explicitly disabled with the -no-pie switch in order for the build to function properly.

I've been able to get it to compile by adding -no-pie to the linking command in src/Makefile after configuration as follows:

$(PROGNAME).o: $(OBJECTS)
$(LD) -no-pie -nostdlib -Wl,-r -o $@ $(OBJECTS)
@printf "%10s %-20s\n" LINK $@

I've done a fix in development (recommended by someone who seemed plausible at the time) to

$(PROGNAME).o: $(OBJECTS)
$(LD) -nostdlib -r -o $@ $(OBJECTS)
@printf "%10s %-20s\n" LINK $@

which seems to do the trick.

[Nick]

Are morgul weapons meant to auto-id the sinv rune? Wormtongue dropped a warhammer & on wield I learnt sinv & drain xp (I already knew poison). There is nothing invisible in sight.

v4.1.0-20-g36595ad-dirty on angband.live

See invisible is learned on wield (since at least 3.5).

[PowerWyrm]

There is no such thing in V yet, because the activation code has not been factorized (object.txt still uses "effect" for rods instead of using "activation" from activation.txt), but in PWMAngband, when I activate a stack of rods, I get a typo: "The Rods of Mapping shines brightly..."

In activation_message(), the header claims "This code deals with plural and singular forms of verbs correctly...", but it's not the case. The ART_TAG_VERB and ART_TAG_VERB_IS don't handle plural properly (ART_TAG_VERB does nothing and ART_TAG_VERB_IS only checks that there's an "s" at the end, which is not the case for things like "rods of mapping" or "maces of disruption").

For PWMAngband, I'll simply fix the message by getting the singular description when looking for activation messages.

[Sideways]

I tried to TO Ungoliant in the nightly (4.1.0-23-gdfffaae-dirty), and got the message "Failed to find teleport destination! Ungoliant, the Unlight disappears!" (She didn't disappear, and as noted in another thread, Teleport Other and Teleport Self fail all too often on entirely normal levels now.)

[Nick]

Just to be nitpicky, there's a mix of uses of "c" parameter and "cave" global in get_move_advance().

...and elsewhere in that file, in fact.