AI committing suicide

[grayman]

I've seen a few comments about AI being discovered dead in missions.

 

This happened to me for the first time while beta-testing Biker's new mission this morning. I came upon a Builder guard lying dead in a doorway, and I know he was alive and patrolling earlier. In previous tests of this mission, I had to dispose of this guard myself.

 

I'm inclined to write an issue up for this, but wanted to start a discussion before I did.

 

Anyone know what's causing this?

[nbohr1more]

There have been accusations against "Interleaved Thinking Optimizations" but Biker's settings don't seem too aggressive. Was this event after a Quick-Save?

[grayman]

There have been accusations against "Interleaved Thinking Optimizations" but Biker's settings don't seem too aggressive. Was this event after a Quick-Save?

 

Not in my case. I had probably done a regular save perhaps 5 mins before finding the body.

[Serpentine]

Anyone know what's causing this?

 

For a while I was playing with an extended version of "Thieves", one of my guards used to be dead and the ragdoll all mutilated at spawn, it didn't happen when I moved my spawnpoint nearby so that I could try watch to see the initial state. I 'fixed' it by jiggling him around a bit and putting his feet closer to the floor, tho he was only like 2-3 units above to start with.

 

I wonder if it's not something to do with the initial gravity where all items are 'dropped' before the map is playable? perhaps some situation causes the falldamage to become stupidly high or something, it was a problem we quite often had working on a UT2k4 mod a while back, some setting was incorrect and would cause npcs to instagib walking between statics... admittedly funny to watch

[nbohr1more]

This behavior affected "The Alchemist" as well, so there is a little ground covered on the topic in the thread for that mission...

[Fidcal]

That is an interesting possibility. Maybe if they lose a tiny amount of health when they fall and it increments that might be a reason. But how? Walking down steps I suppose they just walk off a step and drop an inch or two. But in Heart most of them did not go down steps. But sometimes I've noticed AI get temporarily stuck and step up on some trim or other obstacle then drop down again. Gravity is certainly a theory worth keeping in mind depending on how the code works.

 

My own thinking changes are well within the recommended values on the wiki but still might be a cause. In an early Heart the cook always used to die. I removed all his thinking changes to default and he still died. He always died near the keg in the servant's dining room. So I changed his path to stop that.

 

I've reduced my thinking changes in my current map even more to see if this helps but it will take time to be sure.

 

Any other theories? How about clipping into weapons? Do they have damage stims or is that only during a melee?

[nbohr1more]

I wonder if you could use the Cut-Scene tools to record a timeDemo of the AI goofing around in the map then pinpoint what they are doing? (link a camera to an AI)...

Edited November 1, 2010 by nbohr1more

[grayman]

the ai should only get hurt if there's a certain amt of momentum, so it would be odd if walking down steps was hurting them. perhaps instrumented code that reports health and location every second might show what's happening. just start up alchemist (say) with it and see what happens.

[nbohr1more]

Maybe the AI are sad that there are no ladies (couldn't resist)

[Tels]

the ai should only get hurt if there's a certain amt of momentum, so it would be odd if walking down steps was hurting them. perhaps instrumented code that reports health and location every second might show what's happening. just start up alchemist (say) with it and see what happens.

 

There is already code that prints a console message whenever someone gets hurt, maybe it would be good to add the cause to this message so instead of "4 damage applied" you get "4 damage (fall) applied to atdm:guard_benny_1".

[LEGION]

Maybe the AI are sad that there are no ladies (couldn't resist)

 

THAT WAS MINE!!!!

[grayman]

I ran Alchemist for an hour or so with an instrumented TDM 1.03 and saw 10 instances where damage was inflicted on patrolling AI. The damage ranged from 4 to 10 per shot. I stayed away from them, so I never was the cause of the damage.

 

In 8 of these cases, the AI was next to a door, and their patrol route took them through the door. Is it possible that an opening door can inflict damage? Probably yes, since a door is a mover.

 

In the remaining 2 cases, the AI was simply walking across a floor, headed for a door, but nowhere near the door. He got whacked twice with 10 damage in the exact same spot, but there's nothing there. One more shot and he would've died. I'll have to look closer at him.

 

I'm printing out the inflictor (i.e. a sword) and the attacker (i.e. the wielder of the sword), and in all these cases, none are specified, so the code marks both as the world. Since doors are named, I would expect the doors would've showed up as the inflictors, but they never were.

 

I'm going to let Alchemist run overnight and see who's left in the morning.

 

Oh, and the one Builder guard who died mysteriously in Biker's new mission in this morning's testing did so in a doorway. Curiouser and curiouser.

[Aprilsister]

It is good that you are curious. This is certainly a good bug to hunt.

[Tels]

I'm going to let Alchemist run overnight and see who's left in the morning.

 

You Sir, are a sick person!

 

Anyway, please put the instrumentation code into SVN, it would be useful in other instances, too.

[Jesps]

I remember some mission where a guard would get stuck in a func_static chair, and then start shifting back and forth REALLY fast. And that would kill him.

[stumpy]

maybe they're walking through a closed visportal and taking damage from the closed visportal.

[nbohr1more]

Maybe modify the "Interleaved Thinking Optimizations" so that the think interval is increased near visportals?

[grayman]

The overnight test resulted in one AI dying near a door.

 

I think the other AIs getting hurt last night stopped getting hurt because I moved to a safe spot in the map where I wouldn't be found overnight, and I might have moved beyond their intermittent thinking radius.

 

More testing today.

[lost_soul]

Well I've yet to see this happen during normal gameplay. I have turned on g_dragentity though just to have some fun, moving things around. When I moved a guard over something he wasn't intended to walk on, like a bench or toarch, he died. The first time I saw this, it made me ROFL. Maybe this is the same thing that happens automatically.

[Serpentine]

The overnight test resulted in one AI dying near a door.

 

Throwing some out there ideas in :

Did the doorway have a func_static model arch/moulding over/around it, such that a vis-portal might intersect it?

 

This might cause a situation whereby the visportal's state is incorrect when the AI is "inside" the visportal?

 

Did the door have a property which would close it, either a trigger or "shouldbeclosed" spawnarg?

[grayman]

Throwing some out there ideas in :

Did the doorway have a func_static model arch/moulding over/around it, such that a vis-portal might intersect it?

 

This might cause a situation whereby the visportal's state is incorrect when the AI is "inside" the visportal?

 

Did the door have a property which would close it, either a trigger or "shouldbeclosed" spawnarg?

 

 

The AI is getting hit by a moving door, but that's not the problem. The code looks at whether any damage should be accrued by getting hit, which brings into play the area where I think the bug is.

 

My current theory is that the timing differences of interleaved thinking are a contributing factor. The code assumes the physics math is happening over a 1-frame timespan, but some of the data used is for a timespan of N frames, where N is the number of frames used by interleaved thinking (if the player is far enough away).

 

So the problem is that a force in the vertical direction is magnified by N, and the code thinks the AI is hitting the floor harder than he really is.

 

This causes damage.

 

Right now I'm trying to figure out what the fix is, and apply it in such a way that it doesn't screw up something else.

[Serpentine]

Ah ok, that's what my next guess was going to be with the spawnarg Good work tho!

[nbohr1more]

AI regenerative health when "ITO" is in effect? (that's probably a terrible hack )

[Bikerdude]

The AI is getting hit by a moving door, but that's not the problem. The code looks at whether any damage should be accrued by getting hit,

well one fix is for me to design betters maps where I dont have to have doors auto close...

[grayman]

well one fix is for me to design betters maps where I dont have to have doors auto close...

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, interleaved thinking makes him overshoot his normal stopping point, so he ends up next to the door when he opens it.

 

all theory at this point, though.