C2 SDK Documentation incomplete!

I was wondering if the documentation for Construct 2 SDK is incomplete, because I was looking at the Function plugin code and saw `cf_fast_trigger` flag which is not documented.

Is that flag the only thing missing from the SDK documentation or are there more? I'm writing a plugin and would like to know about all the tools I can use.

Some things are deliberately not documented. The fast trigger flag was designed specifically for the Function object, and has a bunch of fairly obscure caveats and usage requirements that are fine for the Function object but make it unsuitable for other usage. So yeah, the engine has a bunch of undocumented capabilities but generally if they're not documented it's because there's not much reason for any third party developers to use them, or we don't want to have to support them if people ran in to the various caveats.

ramtinsoltani

You can learn how obscure things work by looking at all the runtime code etc. but it's a lot of work and generally you dont need much of the functionality except in very fringe cases.

Ashley Fair enough. I'm creating a plugin which would trigger functions and has some similar conditions compared to Functions. It would work as an addon to the Functions plugin. Do you recommend me to avoid `cf_fast_trigger | cf_trigger` or would it be ok to use it due to the similarity between Functions and my plugin?

QuaziGNRLnose Thanks for the reply.

I have no idea what your plugin does, so I can't comment at all.

ramtinsoltani

The behavior of "cf_fast_trigger" and "cf_trigger" is totally incompatible.

Ashley The plugin brings the concept of Delegates and allows functions to be grouped with a delegate and be all invoked by that delegate. I have conditions such as: On delegate invoked, on delegate removed, etc. and I want them to be triggered without any delays. Can I use the 'cf_trigger_fast'? If so, what would be the benefit of it? What tweaks are done on that unique trigger against the normal triggers? Can I benefit from them?

rexrainbow Why would the already documented 'cf_trigger' flag be incompatible?

ramtinsoltani

You could place a break point ( instruction "debugger" ) in function "Cnds.prototype.OnFunction" ( line 143 , in runttime.js , official function plugin ), then trace the execution.

I'm not sure what your particular implementation of "delegates" means or does. However the main point of fast triggers is to avoid iterating every trigger of that type. Normally firing a trigger runs every associated trigger in the event sheet, but fast triggers pre-filter by the first parameter. So running a function does not have to check every "on function" event in the project only to pass on most of them because they have a different function name - it only iterates the "on function" events it knows have the right name to begin with. This prevents there being a performance overhead to the "call function" action proportional to the number of "on function" events in the project (which would make functions slower the more you used them). However it had a laundry list of caveats that I can't exactly remember, like it only looked at the first parameter, it had to be a string, it had to be constant (no expressions that cannot be calculated at edit-time), etc... basically all specifically geared towards the "on function" trigger. I don't know if it will work for any other plugin, or if the performance impact would be important.

rexrainbow I'm not sure if that's relevant to my question. What would doing that accomplish?

Ashley Thanks for the details. There will be tons of triggering conditions in my plugin such as "on delegate invoked", "on function associated to delegate", etc. that are all recognized by one or two string names (function name and delegate name). I'll keep testing the flags to see what happens.

Just for clarification, a delegate would hold multiple function references (names) and on action "invoke delegate", the specified delegate (by name) would call all its containing functions through "c2_callFunction".

If used right, it could solve a lot of headaches with creating a customizable key mapping system.

I'm not sure what your particular implementation of "delegates" means or does. However the main point of fast triggers is to avoid iterating every trigger of that type. Normally firing a trigger runs every associated trigger in the event sheet, but fast triggers pre-filter by the first parameter. So running a function does not have to check every "on function" event in the project only to pass on most of them because they have a different function name - it only iterates the "on function" events it knows have the right name to begin with. This prevents there being a performance overhead to the "call function" action proportional to the number of "on function" events in the project (which would make functions slower the more you used them).

I recall reading some forum post or article from years ago that claimed that the official function plugin suffered from this exact performance issue you talked about. I'm glad to see that you came up with a solution for it, though I think you should have it documented somewhere, to clear up misinformation about it.