Angband 4.2.1

[whartung]

When you read a scroll of monster confusion, it gives you an "AttConf" status effect. If you're playing a ranged character (Mage, Ranger...) and you don't melee mobs, the status stays for a very long time and can be confusing for new players. Maybe the scroll should work on any attack and not only for melee?

I would argue it should work for physical attacks (melee and shooters), but not magic. And that in the "real world(tm)" it would have been applied to the weapon, rather than the player. But, mechanically that's a real pain in the neck, so it's a player buff.

Spell casters can use either an in-built spell (I don't know if some casters have a confuse spell or not), or a wand or rod. The scroll is for thick headed melee combatants who don't have a solid kinship with magic or their machines.

[PowerWyrm]

When you read a scroll of monster confusion, it gives you an "AttConf" status effect. If you're playing a ranged character (Mage, Ranger...) and you don't melee mobs, the status stays for a very long time and can be confusing for new players. Maybe the scroll should work on any attack and not only for melee?

[DavidMedley]

Cool shapechange knowledge menu, but it throws off what I thought were carefully chosen mnemonics:
boo*K* seller
a*L*chemist
*M*agic Shop
h*O*me

etc

Noticed the QoL upgrade to the knowledge menu made a few weeks ago and I just wanted to acknowledge it. Simple, intuitive, useful! Nice job.

For those that don't know: stores can be accessed by the number key associated with them from the knowledge menu now. 1=gen store, 8=home etc.

[Nick]

Edit: found the reason, it's because some mobs have "friends-base" flag which erases the type used in mon_restrict(). In the example above, the scout generated with the "archer" type will generate "person" friends and then the following calls will be made with NULL parameter.

To fix this, a call to mon_restrict() with the pit type has to be made after each call to pick_and_place_monster() in spread_monsters().

Thanks for all the stuff you have done/are doing on the special levels. I've worked on them in bursts over a few years, so the code is a bit uneven.

[Huqhox]

For lair levels, the generation of "pit" monsters in the lair doesn't work well, it picks pit monsters but stops in the middle and generates random mobs instead. This is probably due to calling mon_restrict(NULL) in the middle of monster generation which resets the type of mobs generated.

Edit: not a problem with calling mon_restrict(NULL), I've tracked those calls and it's not the case. Must be a call to get_mon_num_prep(NULL) then.

For example: choosing an "archer" pit starts to generate rangers, orc archers and co, then after generating a scout it goes time vortex/troll chieftain/shimmering mold...

Edit: found the reason, it's because some mobs have "friends-base" flag which erases the type used in mon_restrict(). In the example above, the scout generated with the "archer" type will generate "person" friends and then the following calls will be made with NULL parameter.

To fix this, a call to mon_restrict() with the pit type has to be made after each call to pick_and_place_monster() in spread_monsters().

Nice find

This kind of bug is why I both love and hate programming in equal measure...

[PowerWyrm]

For lair levels, the generation of "pit" monsters in the lair doesn't work well, it picks pit monsters but stops in the middle and generates random mobs instead. This is probably due to calling mon_restrict(NULL) in the middle of monster generation which resets the type of mobs generated.

Edit: not a problem with calling mon_restrict(NULL), I've tracked those calls and it's not the case. Must be a call to get_mon_num_prep(NULL) then.

For example: choosing an "archer" pit starts to generate rangers, orc archers and co, then after generating a scout it goes time vortex/troll chieftain/shimmering mold...

Edit: found the reason, it's because some mobs have "friends-base" flag which erases the type used in mon_restrict(). In the example above, the scout generated with the "archer" type will generate "person" friends and then the following calls will be made with NULL parameter.

To fix this, a call to mon_restrict() with the pit type has to be made after each call to pick_and_place_monster() in spread_monsters().

[Nick]

This gives an horizontal size of z_info->dungeon_wid * (21-39) / (62-80), which can go up to z_info->dungeon_wid * 39/62 = 62% of the dungeon width for each cavern part. Add the labyrinth and you get dungeon levels that often extend past the maximal width allowed and of course will crash if you go too far right...

That's embarrassing. I'll have to rethink my dimensions.

[PowerWyrm]

Big problem with gauntlet levels:

int gauntlet_hgt = 2 * randint1(5) + 3;
int y_size = z_info->dungeon_hgt * gauntlet_hgt / (15 + randint1(5));

Works fine since this will give a vertical size of z_info->dungeon_hgt * (5-13)/(16-20).
(although I think this gives too many "flat" levels)

int gauntlet_wid = 2 * randint1(10) + 19;
int x_size = z_info->dungeon_wid * gauntlet_wid / ((30 + randint1(10)) * 2);

This gives an horizontal size of z_info->dungeon_wid * (21-39) / (62-80), which can go up to z_info->dungeon_wid * 39/62 = 62% of the dungeon width for each cavern part. Add the labyrinth and you get dungeon levels that often extend past the maximal width allowed and of course will crash if you go too far right...

[Nick]

For gauntlet levels, you get up stairs to the left with no-teleport squares and down stairs to the right, which makes you cross the labyrinth to get to the next level. Except when you arrive from the level below, a down staircase is generated at the player's position, which breaks the purpose of the level, since you can immediately go down again. Maybe make the player enter from the right side in that case?

That's a good idea.

[PowerWyrm]

For gauntlet levels, you get up stairs to the left with no-teleport squares and down stairs to the right, which makes you cross the labyrinth to get to the next level. Except when you arrive from the level below, a down staircase is generated at the player's position, which breaks the purpose of the level, since you can immediately go down again. Maybe make the player enter from the right side in that case?

[PowerWyrm]

Commit a6f0b32 plugs some memory leaks, but "centre" (which is created first) is still not freed in two cases:
- persistent levels
- failure to create caverns

Edit: nevermind, there's a pull request already doing this...

[archolewa]

Annoyances in Paladin spells.
1. Heal 2000 is a waste. If you need more than 500HP (at 5he absolute outside) healed, you can't risk 5% fail. And 50MP is insanely expensive.

I make heavy use of this spell. I use it aggressively, like say when you've lost only third of your HP (so you have a buffer in case it fails). Its not an emergency heal, but it does help ensure you rarely need emergency heals. Sure you don't have many castings, but in my experience paladins hit hard enough they don't need many castings.

[Ingwe Ingweron]

I think that's acceptable. They don't occur until level 50, and there's always the option of going back upstairs or recalling. Not possible for ironman, of course, but that's meant to be a challenge mode

Umm, mine wasn't at level 50, it was at level 3. Edit: Nevermind. I thought thiswas talking about the disconnected room (two by one hall) bug. Clearly not the case.

[Nick]

For the hard centre levels, I'm seeing instances (3 out of 10000 levels of all kinds generated at 300' in one experiment) where the only down staircases are in the vault (since alloc_stairs() does not exclude vault squares). Should that be fixed?

I think that's acceptable. They don't occur until level 50, and there's always the option of going back upstairs or recalling. Not possible for ironman, of course, but that's meant to be a challenge mode

[backwardsEric]

For the hard centre levels, I'm seeing instances (3 out of 10000 levels of all kinds generated at 300' in one experiment) where the only down staircases are in the vault (since alloc_stairs() does not exclude vault squares). Should that be fixed?