bug in head

[fizzix]

I've noticed a bug with lighting, where, if I'm using a radius 2 light (like a torch or a lantern) and am standing in a room where there are walls on 3 sides of me, I cannot see the corners next to me. This is extremely obvious in checkerboard rooms, where I can't see anything on any other square.

In trying to debug it, I created a mage and used created doors and there's a second bug where create doors does not create doors diagonally next to you, only on the 4 squares adjacent. What's going on?

[PowerDiver]

I haven't tried head, but there was a trac ticket saying that the distance function was changed. That's dangerous on balls. It used to be that distance((0,0),(1,2)) <= 2 but with a better distance function it is not. I'd guess that is the problem. I think I once thought the fix was to compare distance to r + 0,5 for a radius r ball but I don't remember for sure. There will also be questions about damage reduction. Before this change, that damage was divided by 3. Should that behavior remain or should it divide by 1 + \sqrt{5} ?

These things aren't helpful with integer arithmetic, unless you do things properly and compare squared distances rather than computed distances. You can compare dist^2 <= r^2 + r using integers.

[d_m]

I've noticed a bug with lighting, where, if I'm using a radius 2 light (like a torch or a lantern) and am standing in a room where there are walls on 3 sides of me, I cannot see the corners next to me. This is extremely obvious in checkerboard rooms, where I can't see anything on any other square.

Yeah, that was me

I've had a more accurate distance algorithm for awhile, and I committed it this weekend. I noticed that bug and spent about 3-4 hours yesterday trying to fix it before deciding that:

1. I don't understand all the crazy details of update_view() et al.
2. I hate update_view() et al.

So I think I'm just going to roll this back to fix HEAD.

The one silver lining (for me anyway) was that this motivated me to actually write a permissive FOV algorithm in C along with a tester harness for other FOV implementations.

[d_m]

This bug should be fixed as of r1995.

[nppangband]

1. I don't understand all the crazy details of update_view() et. al.
2. I hate update_view() et. al.

That and the supporting functions can be pretty painful. When I did the 4gai upgrade in NPP I got a decent understanding of it. Feel free to fire any questions my way if you all have to play around with it any more.

[d_m]

That and the supporting functions can be pretty painful. When I did the 4gai upgrade in NPP I got a decent understanding of it. Feel free to fire any questions my way if you all have to play around with it any more.

I will definitely do that. At this point I think I am not going to touch it again until it's really important (e.g. there is a new FOV/LOS strategy). Hopefully at that point there will be a new implementation

Do you ever stop by #angband-dev on IRC?

[d_m]

That and the supporting functions can be pretty painful. When I did the 4gai upgrade in NPP I got a decent understanding of it. Feel free to fire any questions my way if you all have to play around with it any more.

Actually I should ask you... where do your monsters determine LOS to the player? Do they actively move to spaces where they can target the player without being targeted? Do they realize when they are going to be targetable by the player? It seems like you'd want to add reverse LOS information in update_view() or something.

I have been reading about FOV and am curious how to try to make asymmetric LOS play better. I still like symmetric LOS more, but that may be for reasons of implementation. It seems like with a FOV and reverse FOV calculated the monster AI could (in principle) play a lot smarter, and the symmetric/asymmetric distinction becomes less important.

[nppangband]

Actually I should ask you... where do your monsters determine LOS to the player?

The monster movement in 4gai is quite different than the Angband movement code. Angband AI essentially has the monster attack (by either moving toward the player, or casting a spell), or running away if afraid.

With 4gai, each monster has a desired distance they want to be from the player. Spellcasters want to be further back. Group monsters prefer to stay in hiding until the player is out in the open or otherwise vulnerable to attack.

LOS only affects the monsters decision to move forward or attack.

Do they actively move to spaces where they can target the player without being targeted?

No, it isn't quite that sophisticated. When a monster tries to hide or flee it selects a spot it thinks is safe, and each turn where the monster moves it calculates a path to that spot. If the monster is at the desired range from the player it is more likely to cast rather than advance.

The monsters don't remember what they did in previous rounds or have a recorded plan of attack. They re-evaluate every turn as the player moves or gets wounded and/or heals.

Actually I should ask you... where do your monsters determine LOS to the player?

The monster movement in 4gai is quite different than the Angband movement code. Angband AI essentially has the monster attack (by either moving toward the player, or casting a spell), or running away if afraid.

With 4gai, each monster has a desired distance they want to be from the player. Spellcasters want to be further back. Group monsters prefer to stay in hiding until the player is out in the open or otherwise vulnerable to attack.

LOS only affects the monsters decision to move forward or attack.

Do they actively move to spaces where they can target the player without being targeted?

No, it isn't quite that sophisticated. When a monster tries to hide or flee it selects a spot it thinks is safe, and each turn where the monster moves it calculates a path to that spot. If the monster is at the desired range from the player it is more likely to cast rather than advance.

The monsters don't remember what they did in previous rounds or have a recorded plan of attack. They re-evaluate every turn as the player moves or gets wounded and/or heals. It is tricky, because if the decision making is too complicated, the monsters tend to start wandering around in circles rather than fighting if they cnage their minds too often about what they want to do.

I did add some code for monsters to fight back against some of the standard Angband tactics, such as the pillar dance or the hack-n-back. Monsters who get hit and then find the player out of line of sight during thier attack will try to fire back ball spells near the player in hopes of causing splash damage. Monsters who don't have ball spells are much more likely to do something else indtead of direct combat with the player, like summon, heal, phase door away.

Do they realize when they are going to be targetable by the player? It seems like you'd want to add reverse LOS information in update_view() or something.

Nice idea. I think it was left out of the original 4gai for speed and efficiency purposes. But the 4gai code was written about 10 years ago, and I don't think it would be a problem today.

I don't go to Angband IRC at the moment, because right now I am playing catchup and trying to get NPP current with the latest version of Angband. I will probably start going on there soon, once I get everything working in NPP again.

[nppangband]

Do you ever stop by #angband-dev on IRC?

I meant to add, although I probably won't be on there much until I get NPP caught up, I am happy to go on there sometime & chat if there is something I can help out with.

[PowerDiver]

Yeah, that was me

I've had a more accurate distance algorithm for awhile, and I committed it this weekend. I noticed that bug and spent about 3-4 hours yesterday trying to fix it before deciding that:

1. I don't understand all the crazy details of update_view() et al.
2. I hate update_view() et al.

So I think I'm just going to roll this back to fix HEAD.

Instead of reworking update_view, it might be better to just change the distance function to round. So instead of returning above, return the closer of above and below to the distance. At the end when below+1 == above, compare dist^2 > below^2 + below. I think that will give the current behavior on ball effects.

[d_m]

Instead of reworking update_view, it might be better to just change the distance function to round. So instead of returning above, return the closer of above and below to the distance. At the end when below+1 == above, compare dist^2 > below^2 + below. I think that will give the current behavior on ball effects.

Ball effects aren't the bug I'm worried about it. It's actually worse than that... even with light radius 3, if you go into a room filled with pillars (in the diamond configuration, where you can only move diagonally) your light won't light up diagonally adjacent squares. And for the life of me I can't figure out why.

It's also a problem when digging diagonally. I actually first hit this bug while digging an ASC, in order to work on Morgoth-related bugs.

[PowerDiver]

Ball effects aren't the bug I'm worried about it. It's actually worse than that... even with light radius 3, if you go into a room filled with pillars (in the diamond configuration, where you can only move diagonally) your light won't light up diagonally adjacent squares. And for the life of me I can't figure out why.

That is so strange.

[nppangband]

Ball effects aren't the bug I'm worried about it. It's actually worse than that... even with light radius 3, if you go into a room filled with pillars (in the diamond configuration, where you can only move diagonally) your light won't light up diagonally adjacent squares. And for the life of me I can't figure out why.

It's also a problem when digging diagonally. I actually first hit this bug while digging an ASC, in order to work on Morgoth-related bugs.

I took a look at update_view, and I remember it fairly well. If you send me the distance function you were experimenting with, I might be able to figure out what is wrong. I can't guarantee anything, but I will give it a shot.

[d_m]

I took a look at update_view, and I remember it fairly well. If you send me the distance function you were experimenting with, I might be able to figure out what is wrong. I can't guarantee anything, but I will give it a shot.

OK here's the distance function. It might not be ideal for reasons that Eddie pointed out but it should at least work enough.

/*
 * Calculate distance between two points.
 */
int distance(int y1, int x1, int y2, int x2)
{
        int dy = abs(y2 - y1);
        int dx = abs(x2 - x1);
        int dsq = dx * dx + dy * dy;

        /* Create an interval upper and lower bounds */
        int below = (dx + dy) / 2 - 1;
        int above = dx + dy;

        /* Maintain below < distance <= above */
        while (below < above - 1)
        {
                /* Cut the interval in half */
                int mid = (below + above) / 2;
                if (mid * mid < dsq)
                        below = mid;
                else
                        above = mid;
        }
        return above;
}

You'll need to modify VINFO_MAX_GRIDS and VINFO_MAX_SLOPES by setting them to a high value and then reading the error messages (but you probably know this already).

Once you've done that, the bug is easy to see... get a lantern, radius 2 torch, phial, etc (something that definitely illuminates all adjacent squares) and then dig diagonally a few times. After the first one works and you move into the square you'll notice that the new diagonal doesn't light up, and you can't tunnel (or do anything) there until you try to move, hit the wall, and have it show up on the map.

[Nick]

This algorithm returns 2 as the distance to the immediate diagonal, whereas the old one returns 1. I think this must be related to the problem, although working out how would take more time than I have ATM.