Autoattack wont attack things nearby in the lab start.

[Dacendeth]

Describe the bug

Pressing auto attack while next to zombies in the lab start wont attack them it just waits.

Steps To Reproduce

Steps to reproduce the behavior:

1. Start in a lab as security guard
2. Find some zombies, not the brute you start next to auto attack works on him.
3. Try to auto attack

Expected behavior

Autoattack to swing at clearly hostile zombies next to me

Screenshots

Versions and configuration

• OS: Windows
  • OS Version: 10.0 1903
• Game Version: 0.D-12170-g2073ce1 [64-bit]
• Graphics Version: Tiles
• Mods loaded: [
  Dark Days Ahead [dda],
  Disable NPC Needs [no_npc_food]
  ]

-->

Additional context

Autoattack works for the first swing after loading, or if you open up the debug menu and close it right away it'll work for a single attack.
This hasnt happened to me yet starting on another scenario type, only in the lab.

[ZhilkinSerg]

Looks like autoattack won't work on z-levels below 0 when there is certain disposition between target monster and character.

Reproduce steps (savegame is attached):

1. Stay at blue highlighted square 1 tile southeast of debug monster and try autoattacking it - autoattack works.
2. Move west to red highlighted square 1 tile south of debug monster and try autoattacking from there - autoattack won't work (you will receive "No hostile creature in reach." message).

37904.zip

[Funguss]

Yeah, this is deeper than it appears. It also affects cycling targets via tab in the 'f'ire menu, no target is selected. Turrets are frequently detecting creatures on different Z levels and unloading their entire clips into the ceiling or floor. You frequently hear them as you're roaming about aboveground, which is also an issue, albeit separate (in most cases at least).

I've been pondering the cause and I'm pretty sure it's due to the autoaim searching Z level 0 (possibly higher) first. I'm not sure exactly in which order Z levels are checked, but I'm pretty certain that any out of sight enemy that would be a valid target if visible on any Z level higher than yourself is the cause of this bug. I'm guessing the aim code cycles from the top and there isn't a check on visibility through floor tiles before returning the target and closing the loop. That or there's a Z level visibility check that was left outside the loop when auto aim across Z levels was introduced.

[ghost]

The problem is in player::get_targetable_creatures()
It uses map::sees() for this reason :

bool can_see = ( ( sees( critter ) && g->m.sees( pos(), critter.pos(), 100 ) ) //the call to map.sees is to make sure that even if we can see it through walls || sees_with_infrared( critter ) ); //via a mutation or cbm we only attack targets with a line of sight

map::sees() dosnt seem to be behaving properly, also theres no actual check for barriers between.
What the aiming code does is instead uses g->m.find_clear_path()

replacing map::sees() with !find_clear_path.empty() fixes this problem, but seems to still allow the player to attempt to bash through walls with a spear when they press autoattack with a clairvoyance artifact.

Ramza13 said they would take it from here later.

[Funguss]

Ah, this might be the reason monsters are "seeing" enemies across Z levels, too.

[ghost]

Ah, this might be the reason monsters are "seeing" enemies across Z levels, too.

Quite possibly, I looked at map::sees() and it had lots of stuff about transparency caches and z-levels in there, it was a bit over my head, but it seems like theres perhaps something misbehaving in there.

Ideally I suppose somebody should fix that, but replacing it with another method fixes this bug for now it seems.