Bugs and issues in 4.1.1

[PowerWyrm]

I tried to do some changes in PWMAngband while keeping the old system. Basically, I've kept the idea of using three walls in the cardinal directions to decide to place stairs or not, but with the following changes:

- replacing square_is_wall() by feat_is_wall() in square_num_walls_adjacent() to consider only "real" walls and not other features like doors
- coding square_suits_stairs() using the same code as _find_in_range(), which is more efficient than just a for (i=1 to 1000) loop (this loop was in fact the reason while some stairs were placed in the middle of rooms, since it didn't consider enough possible locations before lowering the number of walls)
- using square_suits_stairs() in alloc_stairs() with walls = 3, then decreasing the value if no suitable location is found (which I think should never happen)

Looking at the result, this works fine except for a few cases where stairs can be placed in dangerous locations:
- vaults
- starburst rooms
- huge rooms

Stairs should probably be placed in vaults only if the vault was designed to have stairs (aka in the vault.txt file). In this case, it's easy to fix this by not allowing SQUARE_VAULT squares to be chosen. For other rooms, it would be easy to add a similar flag (SQUARE_NO_STAIRS?) and do the same.

Implemented in PWMAngband and works very well. Apart from a few "fixed" staircases in vaults and rooms, stairs are now generated in convenient places. Here's my changes:

- SQUARE_NO_STAIRS flag added to floor tiles inside starburst and chamber rooms
- square_num_walls_adjacent() using feat_is_wall()
- square_suits_stairs() using similar code as _find_in_range() that accepts locations that are empty squares, not in a vault or flagged with SQUARE_NO_STAIRS, where square_num_walls_adjacent() is equal to the "walls" parameter (the old code was using "greater or equal", which allowed locations with 4 adjacent walls, leading to stairs placed in checkerboards -- too dangerous for stair placement IMO)
- alloc_stairs() strongly simplified by just calling square_suits_stairs() with walls = 3 and decreasing "walls" if no staircase could be generated

Since PWMAngband is based off MAngband, which has wide corridors to allow easier navigation for parties in real time mode, I also added little "holes" in long corridors to allow stair placement:

  ###
###.###
.......
.......
#######

This is not really needed in case of usual wide-1 corridors, as there are plenty of dead ends to place the stairs.

[Nick]

New builds up on the nightlies page, with the following changes:

• Crash on randart generation fixed
• Bug where brands got the wrong multiplier fixed
• Potential error in displaying number of blows fixed
• Incorporated some of PowerWyrm's ideas about stair placement
• Used some of those same ideas to improve player placement (which was the original problem)

I think that's everything now fixed except for the description of wands of Dragon's Breath.

EDIT:...which I'm going to "fix" by making all the breaths have the same damage

[Nick]

And more, with fixes to the wand of dragon breath info, and randarts not choosing the first sval for any tval as a base item.

Only remaining issue is the random crash from -CloneMonster.

[Sky]

just seen Beorn whose entourage of bears and werebears was in a different room, 15 squares away. they should spawn closer, IMHO.

[Estie]

Why would the blacksmith not want to buy an awl pike 1d8 (+7,+1) {??} ?
Wielded, used on a boil covered wretch, no other properties known on inspection.

[luneya]

Why would the blacksmith not want to buy an awl pike 1d8 (+7,+1) {??} ?
Wielded, used on a boil covered wretch, no other properties known on inspection.

Most likely, that {??} rune is an unknown curse. I generally like to stash these items at home until I have a surplus of identify rune scrolls around. In the early game, home space isn't worth anything anyway, and by the time it becomes an issue, you'll probably know all the useful runes that you might ever find on a non-artifact weapon.

[Estie]

Most likely, that {??} rune is an unknown curse. I generally like to stash these items at home until I have a surplus of identify rune scrolls around. In the early game, home space isn't worth anything anyway, and by the time it becomes an issue, you'll probably know all the useful runes that you might ever find on a non-artifact weapon.

Yes I was assuming a curse, but I thought shopkeepers gave pricing based on the known modifiers ? If that isnt the case, how exactly does shop evaluation work ?

[luneya]

Another bug in item identification: Found a cursed ring of digging, having not previously learned that flavor. I cast an identify rune on it at first, and learned that it had a paralysis curse. Wore it, and learned about the digging skill. So far, all as expected. But after activating it for the stone-to-mud, it's still showing as "marble ring" rather than "ring of digging." Presumably, the game is waiting for me to id all the runes. But that's not correct behavior, as the only runes left are curses, which have nothing to do with the object's identity as a ring of digging.

EDIT: This is on the latest nightly. I can provide a save if really needed, but it shouldn't be necessary for this bug.

[PowerWyrm]

Yes I was assuming a curse, but I thought shopkeepers gave pricing based on the known modifiers ? If that isnt the case, how exactly does shop evaluation work ?

Evalution is indeed based on known flags. Let's say you have an item with the "chilled to the bone" curse. It won't get identified until you learn both the "resist fire" and "resist cold" runes. If the first thing you meet is a fire hound, you will learn the "resist fire" rune and your item will be considered as having resist fire, so you can sell it for that value. If the first thing you meet is a cold hound, you will learn the "resist cold" rune, but then your item will be considered as having "vulnerability" to cold and won't sell. So if you want to sell items with curses, you need that the item's positive abilities weight more than the negative ones.

[Grotug]

Not as serene as I expected! Rock trap stunned me even though I'm wearing a Serenity crown.

Also, would be nice if bodaks were big Us instead of little u's. Tengus they are not. (I die again).

Umm, how come I am no longer getting reports on my weapon description for how much STR/DEX to increase blows?

[PowerWyrm]

Not as serene as I expected! Rock trap stunned me even though I'm wearing a Serenity crown.

Also, would be nice if bodaks were big Us instead of little u's. Tengus they are not. (I die again).

Umm, how come I am no longer getting reports on my weapon description for how much STR/DEX to increase blows?

Unfortunately, there were some letters erased from that crown. A "d", a "p" and a "i".

[Tibarius]

cool direction of development

Just wanted to mention that version 4.1.1 feels pretty good to play again and that i like the direction the game is moving!

Just very little findings in the first game, DL40 without even a lamp ...

Please keep on the good work.

[Nick]

I'm not ignoring this thread, but I am very short of time at the moment, so may not be doing much upkeep for the next week or two.

[Ingwe Ingweron]

In the latest nightly, weapon descriptions no longer inform player about the effect on number of blows from increasing Str or Dex. Was this change intentional?

[PowerWyrm]

In the latest nightly, weapon descriptions no longer inform player about the effect on number of blows from increasing Str or Dex. Was this change intentional?

It's a bug.

Since last update, obj_known_blows() has been simplified by using calc_bonuses(). However, calc_bonuses() does a memset() on the "state" structure, so this code doesn't work:

state.stat_ind[STAT_STR] += str_plus;
state.stat_ind[STAT_DEX] += dex_plus; [B]<-- "state" is wiped in calc_bonuses(), this never applies[/B]
calc_bonuses(player, &state, true, false);
new_blows = state.num_blows; [B]<-- always equal to old_blows[/B]
state.stat_ind[STAT_STR] -= str_plus;
state.stat_ind[STAT_DEX] -= dex_plus;

Fix: remove the memset() from calc_bonuses() and add a memset() before each call to calc_bonuses(), except for the above code.