Bugs and issues in 4.1.1

[PowerWyrm]

Bah I can't reproduce this, simply because it never happens, due to the fact that there are always enough "dead ends" to generate the stairs on a level. square_suits_stairs_ok() is never called, not mentioning all the following code that tries to place stairs manually...

Most of the stairs are placed outside of rooms now, because closed doors are assimilated to "walls", so this is considered as a dead end:

###
+>
###

Worst I managed to get while generating levels is this:

### #
  # # ###
  # # #Ws
  ### #sL
   <+ +Lz 
  ### #zW
  # # #Ws
  # # ###
### #

Also old stair placement in room of pillars and such cannot occur anymore, and I think this should still occur.

[PowerWyrm]

New builds fix the object info crashes, and change the stair allocation algorithm to attempt to put stairs in safer places. I've pushed this straight away before fixing any other bugs, because any changes to dungeon generation are apt to cause crashes, and I'd rather find that out as soon as possible.

Well I can't confirm this yet, but looking at the code, there's a flaw here: stairs are first placed in dead ends, which is fine, but then they're placed in corridors, using a count of 2 for cardinal walls and 4 for diagonal walls. Unfortunately, this also works and it's not a corridor:

###
#>
# #

Which means that stairs can now be placed in the corner of the outer area of... pits! I'm sure stairing right next to a graveyard deep in the dungeon is not really a safe place...

[Nick]

New builds up, fixing the Mr Att issue and the blows info issue. So according to my calculations we're good except for PowerWyrm's latest

[PowerWyrm]

New builds are up om the nightlies page, with the following fixes:

• Extra space removed from description of non-lights with a light radius;
• Debug object tweaking function uses names of artifacts and egos instead of indices;
• Descriptions of items with multiple breath activations are streamlined.

My report of the big description was for the MHDSM, which now works fine with the new code. However, this now breaks the description for wands of Dragon's Breath, which act just like a MHDSM, but with different damage values. Now the description just tells that the wand may breathe the five elements for 120 damage, which is only true for poison.

I found also that you can leave your character's name blank, which doesn't feel right.

[Nick]

In PWMAngband, instead of looking for extra blows explicitely and then call calc_blows(), I simply call calc_bonuses()[/CODE]

OK, this has given me a clue.

The original report was for a weapon that was too heavy to wield. In this case, calc_bonuses() ignores calc_blows, and just returns one blow. So I suspect the solution is just to act like calc_bonuses(), test for heavy_wield, and if so set num_blows = 1.

EDIT: actually, that is no good, because heavy_wield was calculated on th eoriginal stats. The correct answer is just to call calc_bonuses()...

[PowerWyrm]

I believe the only outstanding issues are the Mr Att in the windows html manual (which I don't feel very strongly about), and the "With 0 more STR and 0 more DEX you get 2.3 blows" issue (which I haven't got my head around yet - any simple solutions gratefully accepted). This should mean 4.1.2 before too long.

The code uses the current stats to calculate combat info, but uses the normal stats for the message.

From combat info: "With 18 STR and 18/111 DEX you would get 2.3bpr." (uses STR 16)

In the message, it's translated to "+0 STR" because it uses STR 18.

Looking at obj_known_blows(), the method to get the possible blows depending on str and dex seems to be overcomplicated, which could easily explain the problem.

In PWMAngband, instead of looking for extra blows explicitely and then call calc_blows(), I simply call calc_bonuses():

calc_bonuses(p, &state, true, false);
...
for (dex_plus = 0; dex_plus < dex_plus_bound; dex_plus++)
for (str_plus = 0; str_plus < str_plus_bound; str_plus++)
...
calc_bonuses(p, &tmpstate, true, false);
old_blows = state.num_blows;
new_blows = tmpstate.num_blows;

The V code gets extra blows from the "known" part of the OBJ_MOD_BLOWS modifier, which could explain why it doesn't call calc_bonuses() explicitely (PWMAngband uses a simplified version of object knowledge). However, I've noted a difference with my code that could explain the bug. V code does:

state.[B]stat_ind[/B][STAT_STR] += str_plus;
state.[B]stat_ind[/B][STAT_DEX] += dex_plus;
new_blows = calc_blows(player, obj, &state, extra_blows);
state.stat_ind[STAT_STR] -= str_plus;
state.stat_ind[STAT_DEX] -= dex_plus;

My code does:

tmpstate.[B]stat_add[/B][STAT_STR] = str_plus;
tmpstate.[B]stat_add[/B][STAT_DEX] = dex_plus;
calc_bonuses(p, &tmpstate, true, false);

[Nick]

More new builds on the nightlies page, this time the change list is:

• Teleport distances have been randomised a bit to avoid going back and forth between the same places;
• New measures are in place to stop pointless curses being added to objects;
• Blessed items can no longer be cursed;
• Randart gloves should be more likely to get + to hit and + to dam;
• Randart launchers no longer get supercharged AC bonuses;
• ART_TAG_VERB and ART_TAG_VERB_IS are fixed for plurals.

I believe the only outstanding issues are the Mr Att in the windows html manual (which I don't feel very strongly about), and the "With 0 more STR and 0 more DEX you get 2.3 blows" issue (which I haven't got my head around yet - any simple solutions gratefully accepted). This should mean 4.1.2 before too long.

[Nick]

New builds fix the object info crashes, and change the stair allocation algorithm to attempt to put stairs in safer places. I've pushed this straight away before fixing any other bugs, because any changes to dungeon generation are apt to cause crashes, and I'd rather find that out as soon as possible.

[Sky]

# Random ring of power 68
name:'Eanduia'
base-object:ring:Band
graphics:=ark
info:60:2:25000
alloc:59:20 to 40
power:0:0d0:0:0:0
flags:NO_TELEPORT
values:INFRA[-2] | LIGHT[1]
curse:cowardice:66
curse:teleportation:34
desc:Random ring of power 68

[luneya]

in angband-win-4.1.1-10-g092421f2, the ring of open wounds does not identify correctly. you can learn the impaired hitpoint recovery rune, but then you just get a Rhodonite Ring (or whatever) , no {??} symbol, and you cannot use identify on it.

Activation is the way to formally id this one. Or do as I do, hit "k" and select to squelch all rhodonite rings. You'll never ever want to actually use rings of open wounds, so there's no reason to wait for official identification before squelching. (Contrast something like the disarming/door destruction pair, which you might want to actually identify because they have some legitimate niche uses.)

[Sky]

that's silly, and it wasn't like this before; once the last rune is known, the item is fully identified. what if i want to wear an artifact that activates for stat change? or tele level ?

[Derakon]

Try activating it.

[Sky]

in angband-win-4.1.1-10-g092421f2, the ring of open wounds does not identify correctly. you can learn the impaired hitpoint recovery rune, but then you just get a Rhodonite Ring (or whatever) , no {??} symbol, and you cannot use identify on it.

[Nick]

Trying to create an artifact spoiler file crashes the game.

Confirmed - I've introduced a bug in object info.

[Estie]

Trying to create an artifact spoiler file crashes the game.

Edit Also had a random crash when attempting to destroy (squelch) an average cap, however it didnt happen again the second time around.