AI committing suicide

[Bikerdude]

auto-close isn't the problem. in the situation i'm looking at, the AI is being swept to one side by the door he's opening. it might be that as he approaches the door,

if thats the case, my fault again - building mapas that are too cramped for the Ai...

 

[grayman]

The AI that commit suicide are all moving and using Interleaved Thinking.

 

There are times when the code applies more downward velocity to these AI because of IT, and it's as if they're suddenly falling and hitting the ground hard enough to cause damage.

 

It could happen at any time, but it's most common around opening doors. Let the AI patrol long enough, and they just keel over.

 

Working on a fix.

[Fidcal]

Hard to understand where that vertical downward velocity comes from. Maybe Ishtvan might have some ideas.

 

I did some quick tests and they need quite a height before taking damage. Player limits on the wiki shows the player only takes damage from 186 units high upwards (don't know if that is up to date.) My guess is the AI are probably the same; I had to move them up fairly high. There is not enough height indoors in most of the situations I've seen deaths so it does not appear to be the AI being 'lifted' accidentally. So somehow a downward velocity is applied without dropping.

[grayman]

So somehow a downward velocity is applied without dropping.

 

And that's exactly what happens.

 

A small amount of downward velocity is applied to keep the AI on the ground. When an AI only thinks every 16 (say) frames, that velocity is multiplied by 16, sort of in the spirit of making up for lost time. Unfortunately, there are times when this leads to "crashing into the ground", causing damage.

 

We still want the greater velocity. What we don't want is the damage. That's probably where the fix will be.

 

 

 

[Springheel]

Wow, good find, Grayman! It's great to have you aboard!

[Tels]

And that's exactly what happens.

 

A small amount of downward velocity is applied to keep the AI on the ground. When an AI only thinks every 16 (say) frames, that velocity is multiplied by 16, sort of in the spirit of making up for lost time. Unfortunately, there are times when this leads to "crashing into the ground", causing damage.

 

We still want the greater velocity. What we don't want is the damage. That's probably where the fix will be.

 

Hm, good find! However, I am not sure we really want the greater velocity. Basically, a small velocity every frame keeps th AI on ground, but the same velocity every X frames would also keep it on ground, the worst that could happen is going for instance downstairs, would the AI the float a bit? Basically the difference between velocity and force - the force should always be the same, but the velocity shouldn't increase just because we missed X-1 I am frames in between.

 

Anyway, I am sure you find the correct fix and apply it Good work

[Melan]

And so will end the tale of the Prowling Killer of Darkmod (whose deeds actually made Heart of Lone Salvation a more tense and creepy experience, since I hadn't learned yet it was just a bug).

[Fidcal]

Yeah - nice to pretend it was a feature not a fault.

 

@Tels: You won't see any floating because the decreased thinking is always out of sight except when testing.

 

@Grayman: yes, good find and I'm hoping it might mean we can decrease thinking time even more for better performance. Default is 10. Max recommended on the wiki is 30 but I had about 16 in Heart which was well within. I checked NOHAT (which I think worked OK) and I think it was 12 so I've reduced my current one to 12. But if this is fixed it might mean we can push back up to 20 plus?

[Tels]

@Melan: Yeah, adding things that suddenly change (where the player knows "heh, it wasn't me! I am innocent!") adds a creepy factor - but it be better that the AI doesn't die when neither player nor mapper do want it

[nbohr1more]

I'm still waiting for grayman to fix this and still find dying AI ...then capture a screen-shot of the death event and see a ghost revnant putting it sword into the AI's back with a smile on it's face

Edited November 3, 2010 by nbohr1more

[grayman]

I'm still waiting for grayman to fix this and still find dying AI ...then capture a screen-shot of the death event and see a ghost revnant putting it sword into the AI's back with a smile on it's face

 

ROFL!

 

Yeah, wouldn't that be something. An episode for SyFy's Ghost Hunters.

 

IMHO, the root cause of this mayhem is patrolling AI overshooting their marks. Getting around is done by telling the AI to go to a location. Once they get there, they're told to go to a new location. If they only think every 16 frames, then they will make stopping or turning decisions at different spots than if they were thinking each frame.

 

If we just fixed it so the AI didn't receive unwanted damage, we'd still be left with this other problem.

 

"So what?" you might ask.

 

Well ...

 

I tried interleaved thinking frame intervals of 12, 16, 20, 24, and 28 with a few of the AI in Alchemist. At 12 and 16, the AI were able to negotiate doors, but sometimes ended up standing in front of the door when it opened, which imparted a "stored up" velocity to them and they shot halfway across the room. At 12 they received no damage. At 16 they were hurt.

 

From 20->28 they really had problems. At 28, I found one AI marching back and forth across a path_corner. Each time he thought, he was too far away from the pc and turned around and marched back toward it, trying to find it. He'd wake up on the other side, too far away, and march back. I haven't examined the proximity math, but I think that's what's happening.

 

He never did get "close enough" to his pc, so he was stuck marching back and forth in that corner.

 

At 20 and 24, the AI had problems with doors. They just couldn't find that sweet spot where they were supposed to be to frob the door, so they, too, would end up wandering around in the vicinity of the door, trying to open or close the darn thing. If they thought at just the right spot, then the frob would work and they'd move on.

 

So to squash these problem, I think thinking needs to speed up in the vicinity of doors and pcs.

 

So that's what I'm off thinking about now. Every 16 frames.

[Fidcal]

Is it possible for this velocity that gets stored up to be capped? Or would that affect other things. Is there a situation when we want to give an AI a high velocity? Are we talking vertical velocity still or being knocked across the room by a door? How important is the damageability anyway?

 

In Thief an AI could fall any height and not get harmed. I set up a Thief AI to actually commit suicide by jumping off a cliff. When I eventually got it to work he dropped and just stood there! So I had to put a big damage stim at the bottom of the cliff.

 

What I'm saying is that AFAIK it didn't matter except in such rare situations that AI didn't take any damage from their own velocity. So less important than performance and spontaneous deaths.

[Tels]

Is it possible for this velocity that gets stored up to be capped? Or would that affect other things. Is there a situation when we want to give an AI a high velocity? Are we talking vertical velocity still or being knocked across the room by a door? How important is the damageability anyway?

 

In Thief an AI could fall any height and not get harmed. I set up a Thief AI to actually commit suicide by jumping off a cliff. When I eventually got it to work he dropped and just stood there! So I had to put a big damage stim at the bottom of the cliff.

 

What I'm saying is that AFAIK it didn't matter except in such rare situations that AI didn't take any damage from their own velocity. So less important than performance and spontaneous deaths.

 

Hm, yeah, capping the velocity and/or damage can have bad sideeffects (in case the damage/velocity is actually wanted). Maybe the cap should only be active when interleaving is on? But then you still have the problem that an AI falling from a cliff is not dying just because the player happens to be not there.

 

So I think it might be more sensible to just cap the small ground-force, if the AI is in free-fall, the small force will not contribute much and the high velocity will be achieved regardless, but the AI won't die just because it never left the floor to begin with.

[grayman]

It appears that the ghostly unseen midnight ghost of TDM has been exorcised for 1.03.

 

By increasing the interleaved thinking rate when door-handling, the AI no longer get whacked by moving doors.

 

This lets them stay healthy, wealthy, and wise.

 

 

Well, maybe not so wealthy.

 

 

 

 

And maybe not so wise.

 

 

-------------------------------------

 

While researching this problem, I found that AI at long interleaved thinking intervals (>=20) can get confused around path_corners, leading to wandering around a PC instead of continuing to the next one.

 

A fix I'm working on looks promising, but I'm not done testing. If this works, we might be able to use higher frame intervals. It would certainly warrant authors trying higher numbers to see what happens.

[Springheel]

It appears that the ghostly unseen midnight ghost of TDM has been exorcised for 1.03.

By increasing the interleaved thinking rate when door-handling, the AI no longer get whacked by moving doors.

 

Sounds great! Does this also solve the cases like that AI you mentioned who died nowhere near a door?

[Ishtvan]

We've had problems like this before, and Angua fixed a lot of them. First, within the code where AI take damage from accelerating (or decelerating), we have to make sure the "time" denominator is set to the time since the last interleaved think-frame, not a hard coded 1/60 seconds value assuming they think every frame. This is already fixed though, AFAIK. I would think that would also apply to this "shove them down on the ground" velocity, since the damage code would know to put a larger time in the denominator, the time since they were last checked for interleaved thinking. But maybe something weird happens, like due to order of execution, the damage code thinks this extra downward velocity was applied all in one frame. I'm not sure. It sounds like Grayman has made some progress fixing the problem with doors, though, so that's good.

[grayman]

Sounds great! Does this also solve the cases like that AI you mentioned who died nowhere near a door?

 

Yes. In addition to getting hurt in a doorway, there were instances where an AI got hurt a bit aways from a door. When I was able to watch the action, I saw what was happening: the AI would overshoot his mark and end up in front of the door. When he opened it, he got knocked backward a large velocity all in one frame, taking falling damage both on the initial door hit and also at the point where he ended up, which could be far from the door. He'd stand there for a bit, going oweee-oweee, then straighten up and continue patrolling.

 

The key is keeping him out of the doorway and reducing any damage he takes in the rare case where the door hits him. When interleaved thinking is 1->8, he's more likely to hit his mark and there's no damage if he misses slightly and gets hit. What I'm doing during door handling is changing his frame interval to frameinterval/4 + 1. So 16 becomes 5, 12 becomes 4, etc. Even if we cranked it up to 28, door-handling will bring it down to 8. I didn't want to go all the way down to 1 because that just detracts from performance and isn't necessary when the player isn't watching.

 

I haven't capped damage, as was discussed above. I'm trying not to overfix things. The damage is a by-product of interleaved thinking near doors, so fixing the latter fixes the former.

 

Now, if anyone's worried about AI taking damage from other movers, I can go tone down the damage. Has anyone ever put an elevator on the path of an interleaved patrolling AI? Maybe I should go experiment with that.

[Fidcal]

Do we really need these movers to always do damage? As I recall when setting up things like rotators there is a spawnarg with a default damage amount which I normally set to 0. Can we not always set movers to 0 and let the mapper increase the value in rare cases? I see no reason for a door to ever harm an AI for instance.

 

On a side topic we discussed never dormant long ago and thinking management was the result. We did not like the general idea of AI being frozen in the same spot every time you open a door or indeed, they never turn up on patrol because they are dormant at the other end. But it occurs to me that perhaps we could develop dormant management so they can be set to be totally dormant at a distance. For example, in my FM it doesn't matter at all if the AI in the city watch are dormant while the player is far away in the mansion; and vice versa.

 

If the above is possible somehow then along with the improvement in thinking management we might get really good performance enhancement.

[Ishtvan]

Do we really need these movers to always do damage? As I recall when setting up things like rotators there is a spawnarg with a default damage amount which I normally set to 0. Can we not always set movers to 0 and let the mapper increase the value in rare cases? I see no reason for a door to ever harm an AI for instance.

They're not taking damage directly due to the mover spawnarg that deals damage (not active on doors), but rather acceleration damage from being knocked around by the door.

 

@grayman: I agree it's not a good idea to cap damage, if the problem lies in the interleaving and can be fixed there.

[grayman]

They're not taking damage directly due to the mover spawnarg that deals damage (not active on doors), but rather acceleration damage from being knocked around by the door.

 

True. The mover isn't causing the damage. It's imparting velocity to the AI and if the vertical velocity is large enough for the code to think the AI's falling from a height, damage will happen. Now, a door hitting an AI imparts all horizontal velocity, but there's some math in there that adds vertical velocity as well because the AI is moving.

 

 

@grayman: I agree it's not a good idea to cap damage, if the problem lies in the interleaving and can be fixed there.

 

Okay.

[Ishtvan]

Just FYI, AI can also be damaged by horizontal acceleration, but the threshold for damage is higher.

[Sotha]

Heh.. Just spotted this during my WIP map testing.

 

I had an objective which forbids killing, but I didn't have the player responsible box checked.

 

I was simply wandering around and suddenly the mission was failed due to the do not kill objective.

 

I guess the phantom killer stroke again. Poor AI's are dropping like flies.

[grayman]

The code changes I'll be committing soon will allow mappers to experiment with interleaved thinking frame intervals higher than 16. I've tested 1, 2, 4, 8, 12, 16, 20, 24, and 28 quite successfully.

 

The Alchemist patrolling AI (who are set to 16) experienced door problems (the mysterious deaths) and when set to 28, became confused and stuck at path_corners. The new code drops the frame interval to 4 (if > 4) when around doors or path_corners, so death and confusion are gone.

 

At 28, the AI can still become momentarily confused around more complex architecture (they're travelling long distances between checking their surroundings), but they work out of it pretty quickly.

 

On stairs, 28s clip into the steps when going up, and float when going down, but they soldier on. It won't matter visually because the player never sees this.

 

I suggest trying out different intervals depending on how tight or open your architecture is.

 

The default interval will remain at 12.

[nbohr1more]

This is terrific grayman!

 

Plus I see you've just about fixed drowning AI behavior!

 

Can't wait to see what you fix or enhance next.

[Springheel]

Anything that optimises AI further is great news!