View Issue Details

IDProjectCategoryView StatusLast Update
0002905The Dark ModCodingpublic09.03.2012 20:51
ReporterSpringheel Assigned Tograyman  
Status resolvedResolutionfixed 
Product VersionTDM 1.07 
Target VersionTDM 1.08Fixed in VersionTDM 1.08 
Summary0002905: AI comment about lights out on map start
DescriptionIf we allow AI to comment at all about lights that are out, then we need to let them do so at map start. A light will allow a max of 5 negative barks before everyone shuts up about it. An AI won't negatively bark about the same light more than twice. A lot of AI passing through an area with several doused lights will cause a lot of negative barks until it all settles down.

If that's unacceptable, then we have to disallow negative barks on lights that are out at map start. The variables that control negative barking would have to be set at spawn time to prevent barking. We can't kill the visual stim. But I would only do that on shouldBeOn/0 lights, otherwise AI will never relight lights that were extinguished at map start, even if they're shouldBeOn/{1,2}.

Not something for 1.07, but it's worth looking at. Sometimes lights are intentionally off, especially if it's later at night when most people are in bed. If AI treat every light as if it should be on, that's overkill IMO. I'll make a tracker entry and we can discuss it later.
TagsNo tags attached.




13.11.2011 18:46

administrator   ~0004142

Thinking this might be a simple fix, I took a look at it for 1.07.

It isn't simple. I tried a few obvious fixes, none of which worked.

The light on/off code is very "belt and suspenders", which means a light can be turned off multiple times in the same frame, or turned on multiple times in the same frame. This mainly comes from the use of light holders. A candle flame in a candle in a holder can generate a lot of offs or ons for the light entity as parents tell children what to do.

This is harmless until you try to disable a visual stim at map start, at which point it becomes a PITA. Turn it off in one place only to find it turned back on elsewhere.

I need time to map out all the code paths back and forth between the scripts and the SDK, which means this won't happen for 1.07.


07.12.2011 17:10

administrator   ~0004196

I have fixed and tested this with flames, candles, and electric lights.

If AI patrol past a light that's off at map start, they (now) don't bark about it and don't try to relight it, regardless of its shouldBeOn setting.

If I turn the light on and douse it again, I start ignoring the fact that it was off at map start, thus returning passing AI to their normal behavior. They'll bark about the light being off, and they'll try to relight it, depending on the shouldBeOn setting.

It brings up another problem, though.

Given a light that's set to shouldBeOn/2, that's off at map start.

Bob walks past it, doesn't comment, and leaves the area.

I relight it.

I douse it.

Bob returns, barks about the light being off, relights it, and starts searching if his alert level is high enough.

From the player's POV, if Bob didn't care about the light being off the first time he walked past it, why should he care that it's out the next time he sees it?

I'm leaning toward this: if a light is off at map start, AI will never bark about it being off, and will never try to relight it.

If this isn't acceptable, then we have to start tracking light state changes per AI per light, which is a big deal.

And this leads to something Tels brought up, which is marking lights that should be OFF and having the AI react to them being ON. A light that's OFF at map start is a candidate for this type of behavior.


08.12.2011 14:10

administrator   ~0004200

Last edited: 08.12.2011 14:11

View 2 revisions

"I'm leaning toward this: if a light is off at map start, AI will never bark about it being off, and will never try to relight it."

I think that would be appropriate in the vast majority of cases.

"If AI patrol past a light that's off at map start, they (now) don't bark about it and don't try to relight it, _regardless of its shouldBeOn setting_."

Was that an intentional design choice or just a consequence of the way the code works? I can imagine cases where mappers might want a light off on map start but want AI to turn it on when they find it, and setting it to "shouldBeOn" would seem like the logical way to do it. It's probably a rare case though, so not something to worry about if the code makes it difficult to do.



09.12.2011 17:58

administrator   ~0004201

"Was that an intentional design choice or just a consequence of the way the code works?"

Intentional. I don't see the point in having the map author turn a light off at map start and having the first AI who comes along relight it. It could very well occur outside the player's POV, and then that begs the question of why the map author bothered to start the light off. And the original complaint was that AI are barking about these lights when they shouldn't be. Was the complaint about the barking, or about the potential of relighting?

If the barking is the issue, we could turn barking off entirely by introducing a new shouldBeOn setting of -1, which is a shouldBeOn/0 light that AI don't bark about.

But that won't help existing maps, which aren't using -1.


11.12.2011 22:50

administrator   ~0004203

Well, as I said, it's probably not a very commonplace occurance. In the vast majority of cases, mappers aren't going to want AI to comment or relight lights that are off at map start.

However, I could imagine cases where that might not be the case. Imagine a map where the player is following another thief into a mansion. The mapper might set lights off at map start (the other thief put them out), but want AI to comment and relight them. Or, a mapper creating a servant who is going around lighting torches when the player first sees him (triggered or set dormant until then) because night is falling or something. These are rare cases, of course, and I don't generally like to suggest doing extra work for rare cases. But if it were easy enough to do, setting AI to ignore lights that are off at map start UNLESS they are set to shouldbeon would solve the issue with all existing maps (which wouldn't have shouldbeon set on off lights) while still giving mappers the flexibility to be creative.


12.12.2011 00:10

administrator   ~0004204

shouldBeOn 0 causes barking
shouldBeOn 1 causes barking and relighting
shouldBeOn 2 causes barking and relighting and raising the alert level

For sbo/0 lights that are off at map start, if we have AI ignore them, then AI will always ignore them, even if they come on, then go off again.

For sbo/1 & 2 lights that are off at map start, AI should not ignore them. If it takes the player a long time to get to them, they'll probably be on by then, which makes their being initially off meaningless. But as you said, those should be rare, and not found in existing maps.

If that sounds okay, I'll make a small change to the fix and check it in.


12.12.2011 22:21

administrator   ~0004205

Yes, that covers everything I can think of.


19.12.2011 23:22

administrator   ~0004207

Keep track of which shouldBeOn/0 lights are doused at map start, and if they’re off, don’t let AI comment or try to relight them, even if they go on and off again.

Any shouldBeOn/{1,2} lights that are off at map start are treated normally: AI will comment on them and try to relight them.

revs. 5128,5129:


revs. 12487,12488:



13.01.2012 01:37

administrator   ~0004236

Last edited: 13.01.2012 01:38

View 2 revisions

Hmm, I'm still having AI comment about lights that are off at map start, that I haven't specifically set to shouldbeOn. It's just a regular atdm:moveable_candle_wide2_short_unlit entity.



13.01.2012 02:37

administrator   ~0004239

Last edited: 13.01.2012 02:40

View 2 revisions

If it has the spawnarg extinguished/1 (and that one does), and it's marked shouldBeOn/0, then AI shouldn't say anything.

You're using a darkmod SVN at or later than 12488?

Are you on Windows or Linux?

Edit: I just checked the latest source and the latest darkmod script files and my changes are there.



16.01.2012 22:19

administrator   ~0004247

I'll create a small testmap.


24.01.2012 22:36

administrator   ~0004275

Odd. I tried making a testmap and couldn't get it to work. I'll close this until I see it happen reliably.


09.03.2012 20:51

administrator   ~0004382

rev 5326:


Issue History

Date Modified Username Field Change
06.11.2011 12:32 Springheel New Issue
06.11.2011 12:32 Springheel Status new => assigned
06.11.2011 12:32 Springheel Assigned To => grayman
13.11.2011 18:46 grayman Note Added: 0004142
07.12.2011 17:10 grayman Note Added: 0004196
07.12.2011 17:10 grayman Status assigned => feedback
08.12.2011 14:10 Springheel Note Added: 0004200
08.12.2011 14:10 Springheel Status feedback => assigned
08.12.2011 14:11 Springheel Note Edited: 0004200 View Revisions
09.12.2011 17:58 grayman Note Added: 0004201
11.12.2011 22:50 Springheel Note Added: 0004203
12.12.2011 00:10 grayman Note Added: 0004204
12.12.2011 22:21 Springheel Note Added: 0004205
19.12.2011 23:22 grayman Note Added: 0004207
19.12.2011 23:22 grayman Status assigned => resolved
19.12.2011 23:22 grayman Resolution open => fixed
19.12.2011 23:22 grayman Fixed in Version => TDM 1.08
19.12.2011 23:22 grayman Target Version => TDM 1.08
13.01.2012 01:37 Springheel Note Added: 0004236
13.01.2012 01:38 Springheel Note Edited: 0004236 View Revisions
13.01.2012 02:37 grayman Note Added: 0004239
13.01.2012 02:40 grayman Note Edited: 0004239 View Revisions
16.01.2012 22:19 Springheel Note Added: 0004247
24.01.2012 22:36 Springheel Note Added: 0004275
09.03.2012 20:51 grayman Note Added: 0004382