The best practice of Snapshots management

It’s a topic about the best practice to manage a lot of snapshots.

A very straightforward way is to create snapshots manually by createInstance / start / stop / release. Which leading to another problem is how to manage all those snapshots path strings.

Another way is, wrapping snapshots as nested events in an event. Just like p.1. We first create a label param to indicate which snapshots to be activated. Then during the game, we instantiate this wrapper event and call .start() (its a persistent event). By setting parameter, we could then be able to start snapshots easily. Which pretty much avoid the chaos of managing so many path strings.


p.1

So, my question is :

  1. Is there any other way to manage and play snapshots?
  2. Is it good to create a persistent event to manage snapshots? Or shall we start it everytime we change the parameter?
  3. How our method work in behind? I mean, usually a snapshot instance will be created → start() → stop() → release(). So when snapshots are nested in an event, will this sequence be the same? Would there be a chance that snapshots instances are created duplicatedly and not being release?

Thankyou

If you want to avoid handling event paths/GUIDs for all of your snapshots in code, then using a parameter to drive snapshot instruments is how I would recommend going about it.

Functionally there isn’t too much difference, so a persistent event will save on additional code.

Snapshot instruments will automatically handle starting and stopping their snapshot instances based on whether they are triggered or untriggered. I wouldn’t expect a snapshot instrument to create multiple snapshot instances and/or not release them - if it did, it would be a bug, so please let us know if that occurs.

1 Like