Revamped AI -- share your experiences

[Minimentalpatient]

I started TDM with 1.07 and after few missions it has been an awesome experience so far. However I had a quite weird situation in Outpost or Parcel mission. I was hanging on a rope and a hammer guard sees me, calls for his 2 buddies but they can't reach me still hanging on the rope. It was pretty hilarious so I went up and down trying to get them to leave. They didn't, instead two of them decided to fight each other and one of the hammer guards died. Maybe they had some unfinished business? It is like they are living their own lives too and not being mindless clone guards like in every other game. I love it.

[Springheel]

Welcome to the forums!

[SiyahParsomen]

I started TDM with 1.07 and after few missions it has been an awesome experience so far. However I had a quite weird situation in Outpost or Parcel mission. I was hanging on a rope and a hammer guard sees me, calls for his 2 buddies but they can't reach me still hanging on the rope. It was pretty hilarious so I went up and down trying to get them to leave. They didn't, instead two of them decided to fight each other and one of the hammer guards died. Maybe they had some unfinished business? It is like they are living their own lives too and not being mindless clone guards like in every other game. I love it.

 

yes, if you wait long time, they start to fight each other until last man stand.

 

Nah, it must be some kind bug but funny one. Try to reproduce it if you can.

[grayman]

If they had their weapons out and were jostling around, perhaps one guard's weapon bumped another guard, inflicting damage. The hurt guard would (I suspect) then turn on his "attacker". Just a guess.

 

Welcome to TDM and the forums!

[New Horizon]

That's one bug I wouldn't bother fixing. lol

[Minimentalpatient]

Bug or like Relic would call it feature bug, leave it in. Many games had bugs that worked in their favor, Tribes skiing bug which became a defining feature of the series. Or Starcraft mutalisk stacking and some other stuff I can't remember.

[i30817]

"crate elevator"

 

SHAS

 

rope rocketeering

 

Bunny jump.

 

 

BTW, the dark mod has it's own bug like this: couch and move by jumping makes no sound. Fastest way to move in the game (also; makes it too easy).

Edited January 21, 2012 by i30817

[Springheel]

yes, if you wait long time, they start to fight each other until last man stand.

 

If you were on a rope it's likely they were starting to throw things at you. If one AI hits another with a missile, the first considers him an enemy and attacks.

[demagogue]

I've seen AI hitting each other with their swords when they get clumped up together. It's understandable when they start slashing their swords around. It's funny & fun to exploit when you can.

[DeTeEff]

BTW, the dark mod has it's own bug like this: couch and move by jumping makes no sound. Fastest way to move in the game (also; makes it too easy).

 

I thought about posting a "bug" the other day about no landing sound when crouching and dropping from a height. So there is a more elaborate way to exploit this you mean...

 

Hope it'll be fixed in a future update...

Edited January 22, 2012 by Fieldmedic

[GameDevGoro]

I have also noted the AI to display better acuity and is generally more persistent.

For example, a few times I have been watching an alerted AI from the shadows, knowing that there's no real chance the AI would see me. But to my surprise it suddenly does, and I get my arse handed to me on a plate, or I get nailed between the eyes with a rock.

 

I guess it's possible that maps with an ambient value above some threshold never produce shadows that are dark enough to completely conceal you? Is this another issue with physical darkness and virtual darkness?

[Springheel]

AI that are alert will be able to see you slightly better than when unalert, so a shadow that hides you from a casual AI may not hide you from an alert one.

 

Ambient value can also play a part.

[GameDevGoro]

AI that are alert will be able to see you slightly better than when unalert, so a shadow that hides you from a casual AI may not hide you from an alert one.

 

Oooooh right right right. I didn't think of that.

 

*wind between ears*

[Sotha]

I've been noticing curious AI behavior. Sometimes, when a alert spot is generated near a door the AI engages in a weird behavior:

Walk to door. Open door. Walk to the other side. Close the door. Immediately open door. Walk to the other side. Close door. Repeat until alert over.

 

The AI usually goes into this door abusing routine when you make commotion just next to the door. Or if the door is "suspicious if open" and the AI sees it open. Or if the AI sees you in the doorway long enough to have a low search alert. All is well if the AI sees you long enough that he engages in pursuit.

 

Other than this, everything seems to work really smoothly. The AI has gone a long way in the last few years. AI coders, give yourselves a pat on the back.

[RPGista]

Odd, havent seen that myself, in fact I was playing Lockdown (really nice mission so far) and the opposite happened, got into a chapel recklessly, the priest saw me getting in there, went to the door (while I hid), opened it, stayed at the door looking around a bit and then decided it was probably nothing, closed it and went back to his routine. A pretty good reaction by the way.

[Serpentine]

Does the door have a 'shouldbeclosed' or whatever on it? I remember that happening in the past, but it was fixed?

[grayman]

Sometimes, when a alert spot is generated near a door the AI engages in a weird behavior:

Walk to door. Open door. Walk to the other side. Close the door. Immediately open door. Walk to the other side. Close door. Repeat until alert over.

 

The AI will close the door behind him if he's relaxed, observant, or suspicious. If he's investigating, actively searching, or in combat mode, he won't. I would suspect the search algorithm giving him spots first on one side of the door, then the other, but if that were so, he'd be actively searching, which means don't handle the door.

 

If he spots a suspicious door (should be closed and no clue who opened it), he'll actively search around the door, which doesn't involve closing the door behind him. Only when he's done searching will he close the door. He's smart enough to know which side to close it from, depending on where he was when he spotted it.

 

If you can tell me which door in which map, I'll run some tests. If this is a WIP, just give me all the spawnargs on the door.

[Sotha]

The AI will close the door behind him if he's relaxed, observant, or suspicious. If he's investigating, actively searching, or in combat mode, he won't. I would suspect the search algorithm giving him spots first on one side of the door, then the other, but if that were so, he'd be actively searching, which means don't handle the door.

 

If he spots a suspicious door (should be closed and no clue who opened it), he'll actively search around the door, which doesn't involve closing the door behind him. Only when he's done searching will he close the door. He's smart enough to know which side to close it from, depending on where he was when he spotted it.

 

If you can tell me which door in which map, I'll run some tests. If this is a WIP, just give me all the spawnargs on the door.

 

I have observed this behavior twice while testing my WIP. Once with a door with "shouldbeclosed 1" spawnarg and once with a door with no special spawnargs. Both of the doors were double doors. In both cases, the AI's getting messed up were RIT targetig ones (ie. they have the path_wait decision making node). The AI's got alerted and walked around the door. After relaxing a bit they started the door abusing behavior. Now when I think about it I am not sure if it was a low level search or if the AI was fully relaxed and returning to patrol.

 

I tried to reproduce it in a test map with a static guard, but everything worked perfectly after a few tests. I'm a bit confused now. Could it be RIT AI specific? I'll test...

[Sotha]

Nope. Despite active trying, I could not get it to happen in a test map. Must have been rats...

 

I'll try to be on a look out if I see it again.

[Sotha]

I was mapping the other day and experimented with suspicious doors. At present, if the door is seen open, the AI walks to the door and searches in the near door vicinity. This is often ineffective, since the player is hiding in the ROOM behind the door, not near the door (unless, of course the player opened the door so that the AI saw it open.)

 

Would it be possible to have a special path: a door suspicion path node. A suspicous door would target this node. When alerted by the suspicious door, the AI would not search the door vicinity, but move to the door suspicion path node and search around that instead. This would allow the mapper to make the AI seem to search the ROOM the door leads to, rather than have the AI search the immediate door surroundings.

 

It would feel important to search the room, rather than the door, since the door is effectively protecting the contents of the room, right? Does this make any sense?

[Springheel]

Sounds like an interesting idea.

[grayman]

Yes, this is possible, and easy to do. Pls file a bugtracker request.

 

My testing showed they predominantly searched near the door, but would also search away from it, both inside and outside the room. They look wherever the hiding spot code sends them.

 

With a new path node, they'll do the same thing, but at least the focus of the search will be inside the room.

 

We can't use the 'target' spawnarg for this, since doors use that for something else. I'll come up with something new.

[Sotha]

Done.

 

http://bugs.angua.at/view.php?id=3008

[grayman]

Anyone have any thoughts on whether this should be a new path_node, or whether it should be an entity not associated with path_nodes?

 

All path_nodes have something to do with moving the AI from place to place and/or giving him things to do. What we're talking about here could be construed as giving the AI something to do, but it's really more like an "alert spot".

 

We could even just place a target_null inside the room and target it from the door with a spawnarg (other than 'target'). Target_nulls are already used with cinematics and path_lookat, so there is some precedent for them to be the focus of some activity. No need for a new entity.

 

??

[Sotha]

First I was thinking about path_nodes but you have a really good point there. The behavior is more like the relighting point or door_handle point.

 

But then again, why couldn't it simply be any entity? Those who want could place a path node and use that. If there is an important table in a room, the mapper could just use the func_static table entity name as the search starting point. In that scenario, when the suspicious door is seen open, the AI would just go to the table and start look around. It's probably different matter whether the system would survive the fact that the table is surrounded by monster_clip....