Evaluate PluginPlayer Templates prior to BCP #1824
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR extends the behavior of PluginPlayer to find and evaluate placeholder templates prior to sending player events over BCP. The following PluginPlayers will be affected: BusPlayer, SlidePlayer, SoundPlayer, WidgetPlayer
Examples
This new behavior works with both path-based templates like player variables, as well as event kwarg templates.
Player Variable Example
Event Kwarg Example
Nested Logic
PluginPlayer events are nested dictionaries because a triggering event may have multiple items to play (e.g. a mode_started event triggering both music and voice callouts via
sound_player
). Therefore this code must nest one level deep to look for placeholder templates on each played item.For efficiency (?) a separate dictionary is made to hold the evaluated values and only item dicts that have templates will be copied and their values overridden. The
settings
argument comes from the raw parsed config itself, so it should not be modified in place. Instead, the temporary evaluated dictionary is passed as additional args into the settings dict, preserving the original values with (hopefully) minimum overhead.This feels a bit clunky but in the past MPF has been bottlenecked by huge numbers of
dict.copy()
anddict.deepcopy()
calls, which were the primary function call during profiling. My hope is that the implementation here will be low-profile enough to have negligible impact in almost all cases, and the occasional dict copy for template evaluations is an acceptable price.