 |
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. |
|
|
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. |
 |
"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. |
|
|
"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. |
|
|
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. |
|
|
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. |
|
|
Yes, that covers everything I can think of. |
|
|
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: State.cpp entity.cpp entity.h light.cpp light.h revs. 12487,12488: tdm_events.script tdm_light_holders.script tdm_lights.script |
|
|
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. |
|
|
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. |
|
|
I'll create a small testmap. |
|
|
Odd. I tried making a testmap and couldn't get it to work. I'll close this until I see it happen reliably. |
|
|
rev 5326: Light.cpp |
- Anonymous
