In a plugin I made, that appears to work well in preview, I quickly parse included event sheets looking for certain events to set up the initial state of things before allowing the rest of the plugin logic to process.
Just by exploring and trial and error I am, in the construct 2 runtime, using the deep includes to perform this operation. It works well in preview, but when I export to android it doesn't appear to be working.
I was wondering are the deep includes the correct thing to look at to examine all event sheets referenced by the displayed layout ?
I don't know about the issues you've came across.
But, to be honest, on the performance side. I wouldn't recommend.
Some of us on the Construct Community, we were checking out your plugin on how it achieved it.
I didn't get to read it for long but as I recall, it loops through all the event sheets and events.
On Large Scale projects, it would take a very huge amount of resources just to look for a function.
When in fact, functions are supposed to be optimized to be quick referenced. And not search through the event sheets.
And the most heavy part of it is that it runs every tick. The performance overhead it provides is very hard and bad.
Good try though.
We can't really afford to support plugins which go round tinkering in the guts of the engine. It's all internal engine details and we can change any of that code from release to release so it could make your plugin broken at any time. Also the principle of scanning existing events to detect things is a bizarre design and literally nothing else in all of Construct works like that, so I would strongly recommend you find another way to design your addon.
FWIW there is nothing Android-specific at all in the event system.
I will think about another way to achieve the same results.
Develop games in your browser. Powerful, performant & highly capable.
I agree it's not optimal, I already have an idea on how to modify to improve it significantly.
Just as a side note, it is not looping through all event sheets in a project, just the ones relevant to the current layout showing on the screen. Also on every tick it's decided whether to issue a trigger command. It's on the message send command that it currently looks through the event sheets to determine how many events it needs behind the scenes to carry out the logic to determine and handle event being processed possibly multiple times.
But that is neither here nor there, it was my first stab at making this work since I prefer this type of event organization for my game that I am working on.
I am working on the improvements now to remove the need to know ahead of time how many triggers are listening for a particular event.
I hope to have the next version out soon.
Also note because of the way I did it, it does not work upon export because I am referencing properties that don't exist in the exported runtime vs the preview runtime.
Just as quick update and a thank you to Ashley and chadorireborn,
Based on your comments I looked at the problem a different way and I am no longer inspecting the events tied to a layout and my plugin is not tied to the tick event anymore. So far everything appears to be working but I have a bit more testing to do and then I want to make sure everything works upon export before I post the update.
Final update on this. I am getting ready to upload the new version.
All my testing looks good and export works correctly.
I don't tie into the tick event at all anymore and I don't inspect the event sheets anymore. I found looking at how triggers work in the code that it really takes care of triggering events on the included event sheets.
So the code is much simpler and cleaner and should hopefully suite peoples needs.