View Issue Details

IDProjectCategoryView StatusLast Update
0003509The Dark ModAIpublic12.04.2014 18:51
ReporterSpringheel Assigned Tograyman  
PrioritynormalSeverityminorReproducibilityhave not tried
Status resolvedResolutionfixed 
Product VersionTDM 2.00 
Target VersionTDM 2.02Fixed in VersionTDM 2.02 
Summary0003509: AI can give too many relighting barks in a row
DescriptionDuring 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).

TagsNo tags attached.

Activities

grayman

grayman

04.08.2013 04:48

administrator   ~0005956

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?
Springheel

Springheel

04.08.2013 11:47

administrator   ~0005957

It happened in the room with the crown. I put out the two hanging chandeliers, and a couple other lights besides.
grayman

grayman

04.08.2013 14:08

administrator   ~0005958

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?
Springheel

Springheel

04.08.2013 20:39

administrator   ~0005966

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).
grayman

grayman

04.08.2013 20:48

administrator   ~0005967

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.
grayman

grayman

15.08.2013 11:45

administrator   ~0006025

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.
Springheel

Springheel

15.08.2013 13:26

administrator   ~0006026

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.
grayman

grayman

16.02.2014 05:35

administrator   ~0006402

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.
grayman

grayman

23.02.2014 15:00

administrator   ~0006404

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.

Rev. 5936:

Light.cpp
Light.h
State.cpp
State.h
SwitchOnLightState.cpp
Stim.cpp
Stim.h

Rev. 13770:

tdm_lights.script
tdm_light_holders.script
grayman

grayman

04.03.2014 00:10

administrator   ~0006409

Is this still a problem, or can I close this?
Springheel

Springheel

07.03.2014 01:30

administrator   ~0006418

Last edited: 07.03.2014 01:31

View 2 revisions

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?

grayman

grayman

06.04.2014 18:30

administrator   ~0006505

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.
grayman

grayman

12.04.2014 18:51

administrator   ~0006521

Randomize delay times for relight barks.

Rev 5954

State.cpp
SwitchOnLightState.cpp

Issue History

Date Modified Username Field Change
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