Angband 4.2.1

[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...

[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?

[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]

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]

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]

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().

[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...

[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.

[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.

[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?

[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.