EventPlayer: Bugfix multiple conditionals #1642
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 fixes a regression where an EventPlayer configuration meant to post the same event under different conditions would only successfully post when the last condition was true.
DETAILS
Performance optimizations in aa725f2 restructured the parsing of EventPlayer configs to initialization, and uses a dictionary to store the configs for each event to be posted. By moving from an iteration to a dict lookup, runtime performance is improved—however the same event appearing multiple times (with different conditions) would be overwritten because the dictionary key is only the event itself, not the conditions attached.
This PR tweaks the behavior to store the dict value as a list of configs, rather than a single config. When an event is to be posted, the list of configs is iterated and evaluated.
Performance Implications
I did a
timeit
comparison between (1) always making the dict value a list and iterating, even when there's only one entry, and (2) checking whether the dict value is a list and only iterating if it is. The results were not significantly different, but the all-lists approach performed slightly better.I chose the all-list approach not really because of the performance difference, but because it's easier and more predictable code when all values are the same shape.
TESTING
I wrote some tests to cover the scenario, and verified that they failed in the current dev and passed on this branch. I also ran Mass Effect 2 against this branch and verified that the regressions no longer reproed.