Allow kwargs or player variable events, default "source" kwarg in variable_player #1620
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.
Player Var-Event Kwargs
This PR proposes the addition of kwargs to player variable changes, and implements them by default on changes triggered by
variable_player:
events.Adding Kwargs and New Methods
This proposal adds two new methods to the Player class:
add_with_kwargs(name, value, **kwargs)
will add thevalue
to the player'sname
property and include kwargsset_with_kwargs(name, value **kwargs)
will set the player'sname
property to thevalue
and include kwargsThe Player class
__setattr__()
method modified to include kwargs, and those are passed to_send_variable_event()
and included on the posted variable change event.Variable Player Includes Context
This proposal extends the Variable Player to automatically include the
context
value of its triggering events as the"source"
kwarg in posted events.Use Cases
This proposal is targeted towards multipliers and jackpots that accrue value based on other modes' scoring.
For example, a playfield multiplier may want to increase all scoring by a given multiple, but the multiplier adding to the score would itself increase the score, triggering the multiplier again, for infinite scores. By checking the
"source"
, the multiplier mode could listen to player_score events and ignore those whosesource
is itself.For another example, a jackpot may grow proportional to all points scored in a given mode. By checking the
"source"
kwarg, the jackpot could listen to player_score events and catch those triggered by the mode it uses to grow—while ignoring scoring from all other modes.Each of these use cases is possible already, but requires additional player variables and workarounds. This proposal just makes it easy to do score (and other player_var) filtering with conditional events and no custom code.