MultiballLock blocking_facility

[avanwinkle]

This PR has a couple of updates for miscellaneous MPF behaviors.

Multiball Blocking Facility

After many hours struggling to conditionally prevent a multiball from capturing a ball in a lock (with no other devices available to take the unclaimed_ball), I stumbled across the blocking_facility code. It's totally undocumented but I was able to step through and figure out how to get it working, and it does exactly what I need!

This PR adds blocking_facility as a valid config option on multiball_locks: devices, so that they can catch blocking events and avoid locking balls when desired.

TO DO: I'll get a better understanding of it and write some documentation for blocking facility

[avanwinkle]

Mac tests passed, Linux tests failed.

Collecting setoptconf>=0.2.0
1115  Downloading setoptconf-0.2.0.tar.gz (13 kB)
1116    ERROR: Command errored out with exit status 1:
1117     command: /usr/bin/python3 -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/tmp/pip-install-smg_k15t/setoptconf_900171c3ad544ac68228c8e804b39ccb/setup.py'"'"'; __file__='"'"'/tmp/pip-install-smg_k15t/setoptconf_900171c3ad544ac68228c8e804b39ccb/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(__file__) if os.path.exists(__file__) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, __file__, '"'"'exec'"'"'))' egg_info --egg-base /tmp/pip-pip-egg-info-nrhgu7iw
1118         cwd: /tmp/pip-install-smg_k15t/setoptconf_900171c3ad544ac68228c8e804b39ccb/
1119    Complete output (1 lines):
1120    error in setoptconf setup command: use_2to3 is invalid.
1121    ----------------------------------------
1122WARNING: Discarding https://files.pythonhosted.org/packages/6b/5a/9186be8db0804d808a5a82a9b7e47e6260832a5e5b5ec531a1de9dd49076/setoptconf-0.2.0.tar.gz#sha256=5b0b5d8e0077713f5d5152d4f63be6f048d9a1bb66be15d089a11c898c3cf49c (from https://pypi.org/simple/setoptconf/). Command errored out with exit status 1: python setup.py egg_info Check the logs for full command output.
1123ERROR: Could not find a version that satisfies the requirement setoptconf>=0.2.0 (from prospector) (from versions: 0.1.0, 0.2.0)
1124ERROR: No matching distribution found for setoptconf>=0.2.0

[jabdoa2]

That does nothing on purpose? There should be a default implementation which actually validates this. Not sure if this is correct. I can check later.

[avanwinkle]

Ah yes, I see that now. I'm thinking that these changes may be my own workarounds for overlay platforms that you have since more-correctly fixed. I'll withdraw them from this PR and re-evaluate, thanks!

[jabdoa2]

Are those two connected somehow? Maybe two PR would would be better.

Do you have a test case for the multiball code? How should this be used? Would it make sense to enable/disable the mb? I guess an example which can be turned into a test would clarify.

Is there any client for your new BCP code? Mpf service or the monitor? Guess we should add a simple test to prevent regressions as well.

[avanwinkle]

They are not connected, let me separate them out and write some tests!

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[avanwinkle]

Separated and updated with tests!

The MB use case is a bit quirky, but it goes like this. If a machine has multiple ball devices that all contribute to a lock, enabling the lock will allow any ball device to capture balls for it. In the case where the player must lock a ball in a specific ball device first before locking in another ball device, the lock needs to be enabled but balls entering the second device should be blocked from triggering the lock.

Tested this locally and it works exactly as expected. The lock is enabled and a ball entering the first device is locked but entering the second device is unexpected and kicked out. The blocking_facility is conditional on the first device having no balls, so after it is full the second device successfully captures and locks.

[jabdoa2]

Separated and updated with tests!

The MB use case is a bit quirky, but it goes like this. If a machine has multiple ball devices that all contribute to a lock, enabling the lock will allow any ball device to capture balls for it. In the case where the player must lock a ball in a specific ball device first before locking in another ball device, the lock needs to be enabled but balls entering the second device should be blocked from triggering the lock.

Tested this locally and it works exactly as expected. The lock is enabled and a ball entering the first device is locked but entering the second device is unexpected and kicked out. The blocking_facility is conditional on the first device having no balls, so after it is full the second device successfully captures and locks.

Guess this could also be solved with multiple mode with different priorities right? But that is nothing wrong with having multiple ways.

[avanwinkle]

Yeah, I tried with multiple modes or multiple locks, but it got messy when I tried to have the separate lock devices aggregate to the same multiball. Not a lot of games have separate locks and not a lot of rulesets require locking in a specific order, but.... at least it's an option?

[jabdoa2]

The change is simple enough so I don't see why we should not merge it

[jabdoa2]

Also, generally, I like the idea. Guess we can leverage this in a few more places.