Settings command is sent along with machine variables

[arthurkehrwald]

When machine variables are monitored via BCP, MPF will send a message with the command settings and a JSON string.

settings?json={"settings":[["brightness","Brightness",100,"brightness",1.0,{"0.25":"25%","0.5":"50%","0.75":"75%","1.0":"100% (default)"},"standard"],["flipper_power","Flipper power",1000,"flipper_power",1.0,{"0.8":"Weak","1.0":"Normal (default)","1.2":"Strong"},"standard"]]}

The settings command is not described in the BCP specification. I am not sure it this is intended, but undocumented behavior or a bug. Maybe it was meant to be a machine variable that is sent with settings as the message command instead of the name parameter? It definitely doesn't seem right to send a settings message, when machine_variable messages were requested by the server.

[avanwinkle]

If this is missing from the documentation that's an oversight, but settings are a subset of machine variables that can be adjusted by the operator so (1) they are stored and tracked with machine variables internally and (2) they should be exposed to the media controller for service menu purposes.

There's a case to be made for sending them separately, but the media controller will need to know them all regardless so this is just a shortcut.

[arthurkehrwald]

Why aren't the settings sent with the machine_variable command then?

[avanwinkle]

The data structure of settings is different than machine variables, so it's sent in a separate payload which includes the various settings options, default values, current values, et cetera. Machine variables are simple key/value pairs without the additional settings options.

When a BCP client connects to MPF and requests all of the machine variables, the settings are sent as well because functionally both settings and machine variables are necessary to properly configure the game's state. So when a BCP client asks for variables it gets both, but in separate responses due to the different data shapes.

Hope that helps! If you'd like to update the documentation to include information about the settings, all contributions are most welcome! :D

[arthurkehrwald]

Machine variables are not always simple key/value pairs. Two examples:

• machine_variable?json={"name":"audits_player_score","value":{"average":4520,"top":[8300,5900,5200,4500,4400,3800,3700,3500,2800],"total":9}}
• machine_variable?name=mpf_extended_version&value=Mission Pinball Framework v0.57.3, Config version:6, Show version: 6, BCP version:1.1

I think a message like this for settings would be more reasonable, especially if the settings are technically a machine variable, as you say: machine_variable?json={"name":"settings","value":[["brightness","Brightness",100,"brightness",1.0,{"0.25":"25%","0.5":"50%","0.75":"75%","1.0":"100% (default)"},"standard"],["flipper_power","Flipper power",1000,"flipper_power",1.0,{"0.8":"Weak","1.0":"Normal (default)","1.2":"Strong"},"standard"]]}

It's not really important though, so if you think it's just not worth making this change for the sake of backwards compatibility, that's fine by me.

[arthurkehrwald]

I created a separate issue (#1850 ) to talk about documenting the settings command.

[avanwinkle]

The updated fixes have been merged into dev, for parity between 0.57 and 0.80. Are you building your own custom BCP client? Is it going to be a media controller? If so, I'd recommend working off 0.80 rather than 0.57, the latter being the legacy version to support the old MC and the former being the new forward-looking version. There are a lot of entanglements between MPF and the MC baked into 0.57, and 0.80 attempts to clean up and separate the BCP logic (by necessity, because the Godot MC doesn't use python so must be wholly independent).