nicked on 13/8/2019 at 08:14
I'm looking for some kind of tutorial for getting AI to turn lights on and off.
I already have a bunch of switchable lights, and I'd rather not have to manually link every AI to every light if it can be helped.
Ideal scenario: AI knows if a light is off in a room; if it is, they turn it on when they enter. If it's already on, they ignore it. If all AI has left the room, the last one out turns the light off.
Maybe adding and removing some sort of generic AIWatchObj link triggered by the roombrush?
Not sure where to even start with this to be honest.
DirkBogan on 13/8/2019 at 08:31
I believe marbleman is working on an FM that has that functionality, although maybe not 'last to leave the room' levels of detail. You might want to ask him.
I spent days trying to figure out a good way to do it for
Compulsory Egress -- it's a pain in the neck. I ended up using a marker with NVSuspiciousTrap ~CD linked to one lightswitch. This solution is efficient, but has massive limitations (as far as I could figure out). As I understand it, any AI with custom 'Suspicious Response' that has Line-of-Sight on the marker when turned on will carry out the Suspicious Response instructions, irrespective of priority settings. With more than one AI, this often leads to a feedback loop, where AI can be triggered to frob the light before it gets turned off by another one, and ends up turning the light back on, triggering it and the other AI to frob it again.
For rooms with a single AI, I believe this is the optimal solution. If you want more functionality, I recommend dissecting Yandros' (
https://www.ttlg.com/forums/showthread.php?t=124573) Off The Record, but that's a way more complicated solution.
Sorry I don't have a perfect answer!
Unna Oertdottir on 13/8/2019 at 08:48
In Cosas MissionX, the guards are switching lights on/off in a conversation.
Load it and jump to obj 2494, it's watching up/down switches (1129) in this room which will also work for the other switch there.
marbleman on 13/8/2019 at 10:27
Quote Posted by DirkBogan
I believe marbleman is working on an FM that has that functionality, although maybe not 'last to leave the room' levels of detail. You might want to ask him.
Since scripting is not my forte, I'm doing it the "hard" way, with manually linking every AI to every light. It takes time, but it's consistent. AFAIK Off The Record is using a similar approach, but it's more optimized with custom scripts.
nicked on 13/8/2019 at 12:24
I looked at Off the Record but I couldn't figure it out at all. It doesn't even work in Dromed.
I'll have a look at NVSuspiciousTrap. To prevent the lights being flip-flopped, you could probably just have the AI frob a blue room button rather than the lever itself.
DirkBogan on 13/8/2019 at 12:40
If you can solve the feedback loop issue, the only real problem is controlling AI line-of-sight, since you can't set Suspicious Responses to only trigger from unique/individual instantiations of the Suspicious property on a given object* -- if something is suspicious, it's suspicious for everyone. So long as you don't put any NVSuspiciousTrap markers in wide areas with intersecting guard patrols, this shouldn't be a big problem. For those circumstances, Unna's solution/marbleman's solution/individual AIWatchObj links are likely to work better.
*As far as I know vis-à-vis NVSuspiciousTrap. I'd love to be wrong about this; it would make Suspicious Responses so much more versatile
Yandros on 13/8/2019 at 15:13
Off The Record may be broken in newer NewDark, I'll have to look some time. The basic setup as I recall (which may be wrong... it's been a decade) is mostly all in the archetypes. I think there are markers near each switch and if the AI notices the light is off they go to the nearest switch (using NVScript's abaility to locate the nearest instance of an archetype) and frob it. It worked fine for a very small mission with 4 guards, but not sure how well it would scale. I did it that way instead of just manually linking the 4 guards to the switches mainly to see if I could figure out how to do it. You know, how an engineer will spend 3 days figuring out how to automate something to save 5 minutes of manual work.
nicked on 15/8/2019 at 18:22
OK I got this sort of working using NVSuspiciousTrap and borrowing a couple of bits from Off The Record, but hit a dead end. Here's my setup:
* Light Switches linked via ControlDevice to AnimLights.
* A new archetype under Button called GuardLightButton - no special properties, just the unique name - one of these next to every light switch linked to the switch via ControlDevice.
* A new archetype under Marker called LightSwitchPoint - no special properties, just a unique name - one of these placed just in front of every light switch.
* For every light switch, a very low brightness AnimLight and an Inverter - Switch --CD--> Inverter --CD--> AnimLight. These AnimLights have script NVSuspiciousTrap.
* On the guard - AI>Responses>Suspicious response - existing entries left as they are, then additional entries as follows:
- Goto Object / Argument 1: @LightSwitchPoint
- Play sound/motion / Argument 3: Discover, Pointout
- Frob Object / Argument 1: ^GuardLightButton
Everything works like a charm apart from the very last bit, the frobbing of GuardLightButton. If I target a specific named button rather than ^GuardLightButton, it works fine. If I use ^ (which according to NVScript docs should make the guard frob "The closest object (relative to the object running the script) that descends from the Marker archetype.") he still goes to the point and does the animation, but he doesn't frob anything, and the light remains off.
nicked on 15/8/2019 at 18:42
Hah, I fudged it with Act/React.
Guard has a GuardProximityStim firing off at a short radius with a repeating 5000 lifecycle.
GuardLightButtons have a Receptron to frob themselves.
It's stupid but it works! :laff:
Yandros on 15/8/2019 at 18:52
The ^GuardLightButton will only work as a param to a trap like NVRelayTrap, it won't work as a target in a response or any other standard Dark pseudoscript.