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]

Originally Posted by 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.

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]

Originally Posted by d_m

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]

Originally Posted by nppangband

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]

Originally Posted by nppangband

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]

Originally Posted by d_m

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.

Originally Posted by d_m

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.

Originally Posted by d_m

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.

Originally Posted by d_m

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.

Originally Posted by d_m

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]

Originally Posted by d_m

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]

Originally Posted by d_m

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.