Angband 4.2.1

[PowerWyrm]

A lot of potential memory leaks in the new levels since they use multiple chunks that are not freed when something bad happens (code just returns NULL without freeing all allocated chunks before).

[Nick]

Effects with dice:x turns are actually lasting (x-1) turns, which means trying to set an effect with dice:1 actually does nothing. This is probably the reason why some temporary effects like stun disappear immediately since I think they are supposed to last one turn.

To fix this, I think decrease_timeouts() should be called before process_pending_commands() and not after so a duration of one turn actually lasts one turn.

Edit: this seems to work fine in PWMAngband after the change.

OK, after a lot of thinking and testing, I'm of the opinion that this is working as intended.

An effect with dice:1 lasts (approximately) until the player's next turn. There is some weirdness because a player turn (at normal speed) is 10 game turns, and the decrease happens randomly on one of those game turns. So it could be 1/10 of the way to the player's next turn, or 4/10, or 9/10 or whatever. So if you want an effect to last for the player's next turn, you do need to set the dice to 2 - and then it will run out after the player's next turn, but before the turn after that.

[Pete Mack]

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.
2. Clairvoyance kicks in ridiculously late. Why not add an ordinary mapping spell as well? Carrying around !rHeat, !rCold, -Detection, and a source of mapping is tedious, when compared to previous utility prayers. Losing a couple books makes up for some of it, but I never carried that many as a paladin anyway.

[Nick]

move_energy * (1 + abs(num_moves - 1) - (num_moves - 1)) / (1 + abs(num_moves - 1))

would reproduce the same values for positive values of num_moves and wouldn't blow up for num_moves <= 0. With more negative move speed modifiers, the energy per move would approach 2 * move_energy with that expression. Is that enough of a range to be interesting?

Dropping the "1 +" when calculating state->num_moves from the extra move speed in player-calcs.c would simplify the above expression to

move_energy * (1 + abs(num_moves) - num_moves) / (1 + abs(num_moves))

Thanks, I'm going with this; I looked for a capping of energy and couldn't find it.

[Huqhox]

I'm all for changing them if it's going to make the dungeon generation easier

[wobbly]

Some of those would take only minor modifications to be more tunnel friendly, how attached are people to those exact shapes, I see a bunch of them have (new) attached to them.

[backwardsEric]

OK, I have the savefile, and it is a generation bug due to an interesting room not playing nicely with the tunneling code. If you dig south, you'll be fine

To follow up on this some more, with the most recent nightly no disconnected levels were seen at depths of 50', 300', 550', and 800' in 80,000 attempts at each depth. At 1050', there's about 90 levels in 10,000 attempts that have some portion that's not in a vault and disconnected from the rest. Of those, around 10 (so one in a thousand) disconnect '@' from all of the staircases heading down. Is that too many or is that acceptable at that depth where '@' more likely has some method of digging, or in a pinch, a long range teleport that could get to the disconnected area?

At 1050', the causes for the disconnected areas are usually these vaults:

Cross; Lesser vault; 18 x 11; doesn't work well with the tunneling code unless it happens to hit one of the two doorway areas on the edges
Camouflaged; Lesser vault; 10 x 7; doesn't work well with the tunneling code; boundary is all permanent rock except for three granite grids
Maze; Lesser vault; 18 x 10; doesn't work well with the tunneling code; boundary is all permanent rock except for one door
Tower; Lesser vault; 18 x 10; doesn't work well with the tunneling code; boundary is all permanent rock except for one door
Treasure trove; Lesser Vault; 7 x 7 boundary; doesn't work well with the tunneling code; boundary is all permanent rock except for four granite corners
Castellated; Lesser vault; 18 x 10; works well with the tunneling code but the internals require digging through at least one wall to get through

[Ingwe Ingweron]

OK, I have the savefile, and it is a generation bug due to an interesting room not playing nicely with the tunneling code. If you dig south, you'll be fine

Thanks, Nick. Always nice to find the obscure bugs.

[Nick]

Nick, here's a bug for you. This is in the 4.2.1 nightlies on angband.live. @ ascended some stairs from DL3 to DL2 and finds himself in a 2 by 1 room, with the stairs and no doors. Either this is a bug, or it is the tiniest level I've ever seen.

OK, I have the savefile, and it is a generation bug due to an interesting room not playing nicely with the tunneling code. If you dig south, you'll be fine

[Nick]

Did you ever pull the savefile for this from angband.live? I've been avoiding playing so that the position is unchanged.

I have requested it, to no effect so far.

[Ingwe Ingweron]

If you have a savefile at that moment, that would be handy.

Did you ever pull the savefile for this from angband.live? I've been avoiding playing so that the position is unchanged.

[PowerWyrm]

Equipping dagger of slay animal with ring of mouse says "average damage: , and 0 vs others" (throwing message is correct).

[backwardsEric]

I don't know if this would work, I remember "energy" being capped at "move_energy" somewhere (if you set a value that is greater than the value, so a negative value would have no impact, but of course I could be wrong.

There are caps like that on the energy use in cmd-pickup.c. I don't understand the logic there. I had expected it would increment the energy use for the auto-pickups, but it overwrites what was calculated when making the move.

[PowerWyrm]

move_energy * (1 + abs(num_moves - 1) - (num_moves - 1)) / (1 + abs(num_moves - 1))

would reproduce the same values for positive values of num_moves and wouldn't blow up for num_moves <= 0. With more negative move speed modifiers, the energy per move would approach 2 * move_energy with that expression. Is that enough of a range to be interesting?

Dropping the "1 +" when calculating state->num_moves from the extra move speed in player-calcs.c would simplify the above expression to

move_energy * (1 + abs(num_moves) - num_moves) / (1 + abs(num_moves))

I don't know if this would work, I remember "energy" being capped at "move_energy" somewhere (if you set a value that is greater than the value, so a negative value would have no impact, but of course I could be wrong.

[backwardsEric]

OK, filed as a bug, I'll think about sensible ways of making it negative.

move_energy * (1 + abs(num_moves - 1) - (num_moves - 1)) / (1 + abs(num_moves - 1))

would reproduce the same values for positive values of num_moves and wouldn't blow up for num_moves <= 0. With more negative move speed modifiers, the energy per move would approach 2 * move_energy with that expression. Is that enough of a range to be interesting?

Dropping the "1 +" when calculating state->num_moves from the extra move speed in player-calcs.c would simplify the above expression to

move_energy * (1 + abs(num_moves) - num_moves) / (1 + abs(num_moves))