Activator Logic Tutorial

Overview

This tutorial will demonstrate how to use Activators to mimic this incredibly simple code:

   bool x = true;
   
   A() {
       if (x) { B();}
   }
   
   C() {
       x = false;
   }
   
   B() {
       // Do arbitrary Activator things here
   }

In other words, it allows you to use an activator (C) to turn off another an activator (B) such that it potentially won't execute its changes when called by third activator (A). From this, more advanced logic could be built, allowing for NAND gates etc.

Caveats

(for there are many).

• This has been tested on IntruderMM 2.08, but this behaviour may all be subject to change in future versions. YMMV.
• This was tested on an old map which may not have upgraded the to the latest IntruderMM package correctly (as will be seen later with weirdness to do with legacy-style animations). YMMV.
• This has not been tested in a published map, and it's possible that it will behave differently outside of editor testing map instances. YMMV.

Core Problem And Solution

It's often useful to chain activators one-into-another as shown below. This can be handy for many reasons, such as timing events to trigger after an interval using the Activator -> Options -> Triggerable After Time setting.

One might expect that turning off the GameObject the Activator is on might prevent its code from running when called this way. Unfortunately, it does not. This makes it very difficult to disable Activators and break chains of Activator-into-Activator logic in a convenient way, and prevents any sort of more complex logic based on stored state.

What is shown below is a tedious and somewhat finnicky workaround to this issue, relying on the fact that the Animation component does not run animations when disabled. This allows us to trigger an Activator as an Animation Event on the first frame of an animation, play the animation instead of directly calling Activator.Activate(), and then enable/disable the object to block the Animator (and thus the Activator).