Hypnotic door found in police station offices

[zaimoni]

Fix for RS Revived, is for the import of RS Alpha 10(.1) BehaviorExplore.

Jacqueline Young, on her way out of the police station from persuading The Prisoner Who Should Not Be to squawk, found Julio Howard repeatedly traversing a door in the police station offices.


##########
#>.#..P#..
#=.#..1#..
#..'.@.'..
#=.#...#x.
#..#...#..
#=.#######

On interviewing, Jacqueline discerned that for some reason Julio had been in all locations adjacent to the line he was marching along, activating a compulsion to explore through the door even though he had just gone through it.

[MP]

Ah yes, that would explain at least some of the AI looping that goes on. Thanks for the heads up

[MP]

I've only had a very quick look at this, but the BaseAI.BehaviorWander method is a possible culprit. Alpha 10.1 added a preference to use doors and exits when there was nowhere left to explore, specifically to avoid looping. So I tweaked the section with a definitive penalty on backtracking.

[Code:]
// alpha10.1 prefer wandering to doorwindows and exits.
// helps civs ai getting stuck in semi-infinite loop when running out of new exploration to do.
DoorWindow doorWindow = next.Map.GetMapObjectAt(next.Position) as DoorWindow;
if (doorWindow != null)
{
   if (next.Position == m_prevLocation.Position) //@@MP - don't backtrack (Release 6-4)
       score -= 10000;
   else
       score += 100;
}
Exit exit = next.Map.GetExitAt(next.Position);
if (exit != null)
{
if (exit.ToMap == m_prevLocation.Map && exit.ToPosition == m_prevLocation.Position) //@@MP - don't backtrack (Release 6-4)
   score -= 10000;
else
   score += 50;
}

// alpha10.1 prefer inside when almost sleepy
if (game.Rules.IsAlmostSleepy(m_Actor) && next.Map.GetTileAt(next.Position).IsInside)
   score += 100;

At the start of a game it seems to have made a noticeable reduction in the count of looping instances per turn, but as the game went on it increases and becomes much harder to tell how much (if any) it's improved. There's an awful lot of ("possible") looping going on.

As I was on the lookout for this sort of thing, using bot mode I noticed that my character got into a cycle of stepping away from and moving back to a fence tile whilst an shambler was on the other side gradually breaking it down. My char didn't attack, even though the shambler was in an adjacent tile when I was on the fence. This went on and on until the shambler broke down the fence and chased me. My char would move one tile away, then move back to the shambler, then attack it once, then repeated this pattern for a while until the shambler moved away to attack another civilian.
So next game I turned on loop logging for the player character when in bot mode. I did spot a some looping instances whilst it appeared my bot was exploring the same two corners of a room for about 20 turns, but at least no repeated use of a door

None of this was enough to draw any conclusions, just sharing my preliminary poking around.

[zaimoni]

Yes...RS Revived had a revamp of melee tactics (several releases ago) that, among other things, requires a free run, melee attack sequence, with adequate stamina to not get tired, for this setup. (Stamina cost estimation is jump-aware and night-aware.)
@.S

BehaviorWander: adapted for RS Revived (there was a check for previous location almost immediately, but it didn't compensate for exits)

[MP]

I've had a bit more of a play. I changed the code to log when my character (and only mine) was looping, and changed the looping flag (DEBUG_AI_ACTOR_LOOP_COUNT_WARNING) to 5. I mean, unless you were literally the only actor in the map, even 2 should be fine in theory. I ran myself in bot mode and triggered the looping flag on pretty much every turn from the get-go. I was being chased by a number of undead at the time, and we were going step-for-step, so it didn't appear that my character was getting any excessive AP. (I was under the impression that looping was symptomatic of a threading issue causing an AP overflow?)

I then appended the turn number to the looping log line and found some odd results. Every second turn would report looping. Stranger though, the looping would start on the turn number that I had set the flag to. When I changed the flag down to 2, the looping would start at turn 2. When I set it to 20, it wasn't until turn 20. Always every second turn from then on. I was able to repeat it each time.

So, I went back to bot mode off. Even when I was just moving around, I was using two turns per move, and of course triggering the looping warning. Again, this would only start from the turn number that corresponded to the same value I used for DEBUG_AI_ACTOR_LOOP_COUNT_WARNING. I could see the turn counter skipping every odd-numbered turn. AI around me were keeping pace, so I'm quite confident they were likewise affected.

Finally, given the link between the flag value and the turn this bug starts on, I disabled the loop detection code. Immediately the bug was gone, and each turn I took was back to incrementing the turn counter by just 1. It seems to me that the loop detection code is somehow itself causing an issue. As to whether the the original AP issue still exists, I believe it does, as I still see odd occasions where an AI gets a burst of a whole bunch of moves between my turn and my next turn.
I think that's enough for me for tonight

[zaimoni]

Loop detection ... yes, I did not actually port that to RS Revived (it's parked in an #if PROTOTYPE block). It'd be more reliable if SelectAction never returned zero-TU actions because they were handled within SelectAction, but that is an invasive change that isn't always correct (e.g., turning on a flashlight is zero-TU but requires an explicit action to trigger FOV update cleanly). I did do that change for equipping/unequipping armor, weapons, etc. as a garbage collector mitigation.

The implementation as copy-pasted, needs thread-local static variables to be correct, and only addresses same-turn action stacks rather than more complex action loops.

Original AP issue ...have not been seeing that in RS Revived. Note that I had to adjust the loading code to explicitly de-duplicate Map::m_ActorList on load (there's an issue with the auto-generated C# serialization code and that was the fastest way to de-crash that integrity check when it went in). That said, a check for hyperactivity (ActionPoints exceeding the doll's speed at turn start) is obviously correct; next push for RS Revived will include that.

EDIT: Idea with the hyperactivity check is that if an actor gets duplicated in the actor list (multiple references to the same Actor object), then (s)he will get more than one dose of AP in next turn processing and get multiple turns from exceeding the intended energy limit.

[MP]

Jan 31, 2019 19:14:09 GMT zaimoni said:

It'd be more reliable if SelectAction never returned zero-TU actions because they were handled within SelectAction, but that is an invasive change that isn't always correct (e.g., turning on a flashlight is zero-TU but requires an explicit action to trigger FOV update cleanly).

Interesting point. If it gets to the Wander behaviour and even that leads to pointless backtracking, perhaps it should fall through to something else. Even just a DoWait. And I like your thoughts on zero AP actions like torches. Perhaps SelectAction should first process those, then return an actual behaviour. I'm out at the moment and can't check, but I'll look into it.

Note that I had to adjust the loading code to explicitly de-duplicate Map::m_ActorList on load (there's an issue with the auto-generated C# serialization code and that was the fastest way to de-crash that integrity check when it went in). That said, a check for hyperactivity (ActionPoints exceeding the doll's speed at turn start) is obviously correct; next push for RS Revived will include that.

You've clearly given this some thought already. I like this idea too. I'll be interested to see how you handle it. Something definitely needs to be done, given how out of control the looping may be.

[zaimoni]

So far, the hyperactivity check has triggered only once in RS Revived, for a situation that does not exist in RS Alpha. (Athletic undead like rats can get free walks; the heavily altered RogueGame::DoLeaveMap was not accounting for this.) I don't know what a release mode version of the check would be like.

[MP]

Interesting. I'll fire up Alpha 10.1 in debug and see how much looping it generates. I certainly wouldn't put it past Still Alive to be wreaking looping havoc, but we'll see.

EDIT: Alpha 10.1 had no looping during 1500 turns, so it's very likely a Still Alive thing. Yay :/
Tracking it here. On the backburner until all the features are done.