Bugs and issues in 4.1.0

[Sky]

Oh and you learn the Drain Life (?) curse before an object has a chance to actually drain XP.
Also didnt The One Ring have Stuck On?

[Sky]

#PRAYFORARKENSTONE



still have not seen a single arkenstone being generated in any spoiler since 4.1 release, north of 30 games.

[spara]

Too much info, I think. After quaffing a potion on enlightenment, these gloves seem to reveal everything but stats.

[Nick]

When casting teleport other on Uvatha the game crashes, It looks like any time I try and cast from the second book it crashes as well, but only on that level. I've never reported a bug before from what I'm reading I believe the save is all that's needed? I can upload whatever else as well. Thanks for all the work that goes into such things.

You also need to post your randart file. It should be in the archive directory inside your user directory (lib/user on windows, Documents/Angband on macOS, ~/.angband on Linux); there will be files of the form randart_(stuff).txt, you want the one with the timestamp of when you last played.

[Malphense]

Teleport Other on Uvatha

When casting teleport other on Uvatha the game crashes, It looks like any time I try and cast from the second book it crashes as well, but only on that level. I've never reported a bug before from what I'm reading I believe the save is all that's needed? I can upload whatever else as well. Thanks for all the work that goes into such things.

Edit:
Here's the randart file because I was informed I also needed to provide that. https://drive.google.com/file/d/0B2q...ew?usp=sharing

[spara]

Too much info: @ sees 1 monster. Activating a staff of Slow Monsters tells me that 8 monsters look slowed.

[spara]

I'm playing as a HT warrior. @ has just entered one of those small labyrinth levels and seems to be aware of two unknown items on the other side of the labyrinth. A new feature? A bug?

Edit: Upthread suggests this is a feature, so carry on .

[PowerWyrm]

You solve the 'infinite loop' problem by ensuring a monster never uses a distance metric for pathfinding purposes that doesn't take into account things it considers obstacles. So if a monster refuses to step into lava, they should never use a pathfinding metric that considers lava a pathable tile. (If that's not applicable, the idea of looking 1-2 steps ahead sounds like it will work for common cases.)

That's what I implemented in PWMAngband. Squares with monsters or damaging tiles are rejected, path takes the square with the highest sound/scent, and breaks the ties by looking one step ahead. I'll playtest the result before posting it.

[Huqhox]

Re: Traffic jam: Depending on the type of enemy, shouldn't it in some cases be the intended behavior to have them hindering each other in narrow passageways? A small tactical advantage when there's a pack of bloodthirsty enemies trying to get to your location all at once, bumping into each other.

This seems reasonable, based on intelligence maybe? So creatures with enough intelligence keep pace behind the creature in front whereas the less intelligent ones get in each other's way trying to get to you and slow everyone down

[Mars]

Re: Traffic jam: Depending on the type of enemy, shouldn't it in some cases be the intended behavior to have them hindering each other in narrow passageways? A small tactical advantage when there's a pack of bloodthirsty enemies trying to get to your location all at once, bumping into each other.

[Patashu]

You solve the 'traffic jam' problem by letting monsters who are blocked get a second chance to move before the player can move again. (This is how Crypt of the Necrodancer solves the problem, for example.) A simple way to do this is to deduct a small amount of energy rather than a full move's worth of energy.

You solve the 'infinite loop' problem by ensuring a monster never uses a distance metric for pathfinding purposes that doesn't take into account things it considers obstacles. So if a monster refuses to step into lava, they should never use a pathfinding metric that considers lava a pathable tile. (If that's not applicable, the idea of looking 1-2 steps ahead sounds like it will work for common cases.)

[PowerWyrm]

There's also the "traffic jam" problem:

########
qqqqqq.@
########

Depending on which monster is processed first, the result can be quite different: if monster indices are ordered from right to left, all monsters will be able to move to the right in one turn; if monster indices are ordered from left to right, it will take six turns for all monsters to move to the right (every monster will "bump" into each other, except for the rightmost one).

[PowerWyrm]

Interesting one - note that if the damaged tile didn't allow sound, the ogre would just move south. So the current situation reflects the fact that the ogre knows the way it wants to move is south-east, but can't.

At some point I'm planning to do better short-range pathfinding; probably a combination of sight and sound, so a monster can pick its way around obstacles between it and a seen point of higher noise.

In fact, he could also move east, it's the same sound value. He would go south because the code processes south before east. If the pit was rotated 90 degrees clockwise, we would have an endless loop:

.#.#.
.#.#.
.#..O
.#.~.
##.#.
..@#.
#####

West and south are both equivalent, but south is processed first, so the ogre goes to a dead end, moves back north one square to his initial position, but moves south again because it's processed before northwest. I guess it will be tricky to solve all pathfinding problems... for equal grids, you would have to guess the best path recursively by looking at the "next" steps and see which one would give the best result. This would ensure in this example that the ogre goes west to the open path instead of going south in a dead end.

[PowerWyrm]

Oh and smell is never used...

int best_noise = base_hearing - cave->noise.grids[my][mx];

...

/* If no good sound yet, use scent */
if (!best_noise) ...

best_noise is always defined, scent code never triggers...

[Nick]

Still got one problem left:

..O...#
##.~###
.....@#
#####.#
....#.#

The ogre here has a damaging tile to his southeast and doesn't want to move, though the tile south is open and perfectly viable. I imagine that the "noise" value for that tile isn't high enough so it's discarded.

Interesting one - note that if the damaged tile didn't allow sound, the ogre would just move south. So the current situation reflects the fact that the ogre knows the way it wants to move is south-east, but can't.

At some point I'm planning to do better short-range pathfinding; probably a combination of sight and sound, so a monster can pick its way around obstacles between it and a seen point of higher noise.