Recall that the motivation for doing the overlays in the first place is a result of the differing windows for latching trigger data as opposed to event data, and we need to be sure to provide a mechanism for not only overlaying the PT data, but also including the trigger information.
Note that the Onboard Filter is a consumer of both the trigger data as well as the event data, so the above impacts it as well. For example the Gamma Filter checks the status of the trigger word before it begins its processing, requiring that one of the trigger primitives be set. If the trigger is not properly simulated then you could imagine a generated event that missed the LAT, with a ghost track that resulted in a trigger and might pass the Onboard Filter - when it shouldn't.
Before overlays, the trigger data was simulated differently per system, but in all cases based on the same hits that ultimately appeared in the Digis. To handle the overlays a scheme needs to be developed which calculates the raw trigger information from the simulated data only and then "or"'s these trigger primitives with those from the input Periodic Trigger events. Then, after the trigger information has been simulated, the overlay mechanism can merge the simulated event data with that from the Periodic Trigger.
To accomplish this it was necessary to split TriggerAlg into two pieces: TriggerInfoAlg and TriggerAlg. TriggerInfoAlg is responsible for forming the trigger primitives from just the simulated data, TriggerAlg then takes these primitives and simulates the trigger decision. This new scheme then allows for the inclusion of a new algorithm which reads in the raw trigger data from the Periodic Trigger event and "or"'s it onto the results of TriggerInfoAlg. In principle, the ghost tracks are now "invisible" to the trigger but are a part of the data (including being seen by the Onboard Filter).