Script connection object trigger method

[Be-ing]

Previously, engine.trigger(group, key) had to be called by scripts, which would trigger all callbacks connected to that ConfigKey. This new method allows more fine-grained control by scripts.

[daschuer]

LGTM. Though I cannot test this. I sure you did ;-)

[Pegasus-RPG]

Wait, can you please add a test for this new function?

[Be-ing]

Yeah, I'll open a new PR with a test. I consider this a quick hack for 2.1. For 2.2 I'd like to rethink this functionality and provide a nicer, more JavaScriptish syntax (something like var conn = new ControlConnection('[Channel1]', 'play_indicator', function () { do stuff; })) along with creating a way to register input callbacks from JS.

[Pegasus-RPG]

Still, anything we're exposing to the users will a) need to be supported and b) unit tested to ensure it works as expected in the future. (If you want to do quick hacks, do them in script, not user-facing APIs.)

[rryan]

I think this still triggers all the callbacks since it does the same thing ControllerEngine::trigger does (causing the ControlObjectScript to emit a valueChanged signal). To just trigger the connection itself I think you would need to call the logic in the loop in ControlObjectScript::slotValueChanged for just the ControllerEngineConnection in question.

[Be-ing]

I think this still triggers all the callbacks since it does the same thing ControllerEngine::trigger does (causing the ControlObjectScript to emit a valueChanged signal).

No, it does not, because it is up to the script to keep track of the connection objects and specifically trigger the appropriate connections.

engine.connectControl() returning a connection object has never been documented. I discovered it accidentally by reading the C++ source (refer to #656). For the most part, this should be abstracted away by Components. Script authors should only have to use that functionality directly when implementing a custom connect method for a Component that registers multiple connections. Before c317735, a Component would have to also implement its own trigger method in that case because the prototype trigger method relies on engine.trigger with a single outKey. Refer to here for an example.

[Be-ing]

Example use of the fixed functionality

[rryan]

No, it does not, because it is up to the script to keep track of the connection objects and specifically trigger the appropriate connections.

Hm, are you sure? ControllerEngine::triggerControl looks up the ControlObjectScript using the string group/item and tells it to emitValueChanged. This should be equivalent to ControllerEngine::trigger(connection.key.group, connection.key.item).

engine.connectControl() returning a connection object has never been documented

👍 this isn't a big deal since it was never documented in the first place. It's still nice to have tests though :).

[rryan]

Example use of the fixed functionality

Was this meant for #1196?

[Be-ing]

Hm, are you sure? ControllerEngine::triggerControl looks up the ControlObjectScript using the string group/item and tells it to emitValueChanged. This should be equivalent to ControllerEngine::trigger(connection.key.group, connection.key.item).

Oh, you're right. I'll try modifying ControllerEngine::triggerControl to specifically call the connection's callback instead of calling the COScript's emitValueChanged method.

[Be-ing]

Was this meant for #1196?

Yeah, sorry. It can get confusing keeping track of a bunch of PRs and git branches :S Here is where I meant to link.