Like World Groupings, Active Grid Groupings allow you to configure different settings for different Asset Chunk Groups.
This is incredibly useful, as different Asset Chunk groups generally have different requirements for what needs to be loaded. For example, an Asset Chunk group made up of grass will typically have a smaller viewing range than one made of trees, and thus should require fewer Cells to be loaded.
For each Active Grid Grouping, the number of that grouping will always match the same number Grouping on the synced World. For example, Active Grid Grouping 1 always corresponds to World Grouping 1, 2 with 2, and so on.
In the majority of cases, the Active Grid and World will have an equal number of Groupings. It is possible, however, for the Active Grid to have more or less Groupings than the World it is synced to.
When it has more, any Groupings greater than the number of Groupings on the World are simply disabled. When it has less, only data from the Groupings it does have are sent to the World.
Rather than adding and/or removing Groupings at runtime (which is not allowed), this functionality allows you to configure a single Active Grid to work with multiple Worlds, even when those Worlds use different numbers of Groupings. The Active Grid Groupings are simply enabled and disabled as needed when the Active Grid changes the World it is synced to.
Loading Blueprints define both the shape of the pattern of Active Cells that is used by each Active Grid Grouping as well as which LOD assets are needed for those Active Cells.
The Blueprint selected must come from the Loading Blueprint Repository assigned to the Active Grid, however you can change the Blueprint used at runtime via scripting and the changes will be saved with the persistent data.
--Special Note--
Loading Blueprints work a bit differently than other Default Settings. Whereas other settings are automatically not used when persistent data exists for the Active Grid, the Default Loading Blueprint will be used so long as the Loading Blueprint in use was not different than the Default Loading Blueprint at the time of saving.
This let's you change the Default Loading Blueprint and that change will be applied to all save files so long as the Player was using the Default Loading Blueprint when the save files were created.
Learn More About Loading Blueprints & Repositories
You can choose to enable or disable whether Active Grid Groupings update the World. When disabled, the Grouping will clear any Cells it has registered as a user for the World and will not register itself as a user of new Cells. You can enable/disable this setting (Update World) before entering Play mode, or while the game is running using scripting.
Note, the Grouping still updates the Cells internally and is able to still trigger Cell Player Is In Changed and Grid Moved events.
Also note that if the Active Grid Grouping is the only user registered with the World Grouping, disabling updates will likely result in the equivalent World Cells being unloaded.
Auto Tracking is the system by which the Grouping tracks the Player and updates its internal collection of Active Cells based on the Player position. If disabled in the inspector, the Grouping will still register itself as a user of the initial Active Cells that are needed based on the Player's initial position, however those Cells will never be changed (new Cells added, old Cells removed).
If Auto Tracking is enabled at runtime but you disable it using scripting, whatever Active Cells are currently registered with the World will remain registered, which means the equivalent World Cells will not be unloaded. This is useful if you want to temporarily freeze the World Grouping so its layout of World Cells does not change (this assumes the Active Grid Grouping is the only user of the World Grouping. If it has other users, this may not be the case).
Each Active Grid Grouping is capable of firing two events, the Cell Player Is In Changed Event and Grid Moved Event. If you know that these events are never used for anything, you are free to disable them, however it should be noted that the Distance Pooling Chunk Manager requires the Cell Player Is In Changed Event to be enabled.
Also note that while you can enable/disable these events on a per Grouping basis, the events themselves are actually fired outside of the Groupings. This means that any subscriber to the events will receive the events triggered by all Groupings that have the event enabled. The event args include the grouping that triggered the event, which you can use for filtering purposes.
--Cell Player Is In Changed Event Special Considerations--
In addition to being fired whenever the Player moves between Cells, this event is also fired whenever the Active Grid desyncs from or syncs to a World (including when the Active Grid is initialized and has a World to sync to).
This is done because when the Active Grid desyncs or syncs to a World, the Cell the Player is in technically changes, even if the Player has not moved.
Each desync or sync will fire a separate event, however for desync events, the data about what Cell the Player is in will either be null or invalid, since when there is no World the Player cannot be in a Cell. To account for this, you should check the CausedByDesync property on the CellPlayerIsInChangedEventArgs event args object before accessing the data related to the Cell the Player is in, making sure it returns false.
--Subscribing To Events--
While you can subscribe to these events directly using an Active Grid reference, doing so can be inefficient. For example, if you have multiple Active Grids, you would need to subscribe to each Active Grid's events separately.
The Component Manager provides a convenient event handling system (but only for these two events) that offers a number of benefits:
1) You can subscribe to the events of every Active Grid in the scene, rather than just a single one, using a single method (SubscribeToCellPlayerIsInChangedEvents or SubscribeToActiveGridMovedEvents).
2) You can filter events to only receive event notifications when an Active Grid synced to a particular World fires the event.
3) You can filter events to only receive event notifications when a particular Grouping fires the event.
4) You can combine options 2 & 3 for more fine-tuned filtering.
More information can be found in the Event Subscription Section within the Component Managers Chapter.
Component Manager Event Subscriptions
There are two additional events which are not related to particular Active Grid Groupings. These include the Player Moved By Grid Event and World Synced To Changed Event. Both events cannot be disabled, and to subscribe to them you will need to use an Active Grid reference (no event handling is performed by the Component Manager for these events).
The World Synced To Changed Event is fired whenever the World changes, which includes when the Active Grid is initialized, when syncing to a new World, and when Desyncing from a World without syncing to a new one.
Whenever subscribing to an event (either via the Active Grid or Component Manager), never forget to unsubscribe! Usually, subscribing is best done in OnEnable and unsubscribing in OnDisable.