View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003509||The Dark Mod||AI||public||02.08.2013 00:26||12.04.2014 18:51|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Product Version||TDM 2.00|
|Target Version||TDM 2.02||Fixed in Version||TDM 2.02|
|Summary||0003509: AI can give too many relighting barks in a row|
|Description||During testing, I was playing Chalice of Kings, and I was in a room with a standing AI. I put out three different lights in that room, and over the next 30 seconds or so, I heard him comment 4 or 5 times about those lights. "I can't light it. What put that out? Someone else can do it. Why is it so dark in here? Must have been the wind that put it out."|
It got a bit excessive and didn't sound terribly believable. I would like to suggest some kind of counter that disallows AI from making a comment about lights out until at least 5 or 10 seconds passes since the last time they commented about it (unless they are commenting that they are going to relight it...the player needs to know that if so).
|Tags||No tags attached.|
If an AI barks negatively about a doused light, he won't bark negatively again about any doused light for at least 15s.
If he barks positively about relighting, that doesn't reset the negative bark delay. A positive bark is always allowed.
I tested with a City Watch guard in a room with 5 shouldBeOn/1 lights. While I continuously doused the lights over a span of 3.5 minutes, he barked positively and relit 8 times, barked negatively 6 times, and wasn't allowed to negatively bark 6 times.
In the first 30 seconds following me dousing the 5 lights, he relit 2 and barked negatively only once.
So he appeared to behave correctly.
Wrt negative barking, the code doesn't care what the light's shouldBeOn setting is. 0, 1, and 2 create the same behavior.
In your case, which room of the house did this problem occur in?
|It happened in the room with the crown. I put out the two hanging chandeliers, and a couple other lights besides.|
That room has two standing AI and two AI that patrol through it. Two AI have the same voice set, and the other two AI have the same voice set, so there are only two unique voice sets in that room.
There are 10 flames in that room.
I tested w/o knocking anyone out, doused all the flames, and captured the barks.
No individual AI did anything wrong.
The effect, however, was a lot of chatter about the lights from two different voice sets talking about 10 doused flames that weren't being relit, so they were stimming every second. We might have to think about special situations like that so the player doesn't have to listen to so many comments about lights being out.
How did you get it down to a single standing AI, and which AI was it?
Hmm, you know, I didn't consider the other AI that patrols from the kitchen. I couldn't see him from where I was positioned, so it's possible half of the barks were coming from him, and they just sounded like one person because they didn't happen to overlap.
No need to worry about this for 2.0, but I wonder if it's possible to have that timer affect _all_ AI within a certain radius, so if one AI comments about the light, other AI right beside him won't do it immediately afterwards (unless they plan to relight it, of course).
I'm already doing that. If an AI barks about a light, no other AI is allowed to bark about that light for 15-20s.
Unless, of course, he plans to relight it.
I think the situation in that room is that there are 10 flames and if you douse them all, the opportunities for negative barking are numerous.
The only improvement that immediately comes to mind is to not let each of the three candles on a chandelier act like an independent light. They're all part of the same family group (the chandelier), so the group should behave as if it were a single light. I don't have a chandelier in my relight test map, so maybe I should go see what happens when an AI relights any of the candles.
Is this still a problem?
I added a chandelier to my test map, and when they relight it, all the candles come back at the same moment.
I tried dousing a single candle, to test that situation. But when one goes out, they all go out.
We might consider toning down the 3 stims to 1.
|I haven't really noticed, but haven't been around many chandeliers lately. It sounds like it was a rare case so I'm comfortable leaving this until 2.01.|
While testing the the 3-candle chandelier, I encountered a moment when two AI wanted to relight two different candles on a doused chandelier at the same time. All the probability checks lined up perfectly to allow this to happen.
Unfortunately, both AI ended up occupying the same spot as they went through their relight animations.
When a light is being relit, it's marked as such, which keeps other AI from also trying to relight it. But the 3 flames on a chandelier are separate objects.
This bug needs to be fixed by marking all lights as being relit regardless of which one sent the stim that caught the attention of an AI.
This fix is restricted to multi-light lights, such as chandeliers.
Added code to treat such lights as a single light.
Added code to prevent several AI from relighting each of the several lights. Lighting one lights them all, so there’s no need for more than one AI.
|Is this still a problem, or can I close this?|
Yes, this seems to be fixed now, although while testing this I noticed a different problem...AI all give their first "relight" bark at the same time. Sounds odd when there are many AI in the area. Would it be hard to add some kind of random factor so that doesn't happen?
SingleBarkTask() can include a delay. Currently, the relighting barks all use a 2s delay. This should be made to vary randomly between 0.1s and 2s.
That should be enough variability to solve the problem.
Randomize delay times for relight barks.
|02.08.2013 00:26||Springheel||New Issue|
|04.08.2013 04:48||grayman||Note Added: 0005956|
|04.08.2013 11:47||Springheel||Note Added: 0005957|
|04.08.2013 14:08||grayman||Note Added: 0005958|
|04.08.2013 17:30||grayman||Assigned To||=> grayman|
|04.08.2013 17:30||grayman||Status||new => assigned|
|04.08.2013 20:39||Springheel||Note Added: 0005966|
|04.08.2013 20:48||grayman||Note Added: 0005967|
|15.08.2013 11:45||grayman||Note Added: 0006025|
|15.08.2013 12:05||grayman||Status||assigned => feedback|
|15.08.2013 13:26||Springheel||Note Added: 0006026|
|15.08.2013 13:26||Springheel||Status||feedback => assigned|
|15.08.2013 13:33||grayman||Target Version||=> TDM 2.01|
|23.11.2013 16:31||grayman||Target Version||TDM 2.01 => TDM 2.02|
|16.02.2014 05:35||grayman||Note Added: 0006402|
|23.02.2014 15:00||grayman||Note Added: 0006404|
|04.03.2014 00:10||grayman||Note Added: 0006409|
|04.03.2014 20:28||grayman||Status||assigned => feedback|
|07.03.2014 01:30||Springheel||Note Added: 0006418|
|07.03.2014 01:30||Springheel||Status||feedback => assigned|
|07.03.2014 01:31||Springheel||Note Edited: 0006418||View Revisions|
|06.04.2014 18:30||grayman||Note Added: 0006505|
|12.04.2014 18:51||grayman||Note Added: 0006521|
|12.04.2014 18:51||grayman||Status||assigned => resolved|
|12.04.2014 18:51||grayman||Resolution||open => fixed|
|12.04.2014 18:51||grayman||Fixed in Version||=> TDM 2.02|