Q Light Controller+

Hi,
assuming the following On-Stage Quiz situation: We do have Buzzers/Buttons on the stage (with Lithium Battery + ESP32 integrated) that send OSC commands via WiFi to QLC+.
What works perfectly fine is to trigger One-Shot chasers that take some seconds to complete and are done then. They can then be re-triggered again.

The problem in the quiz situation is that would like to inter-lock two chasers while another one is running. That means if Team A hit the buzzer and their chaser is still running and Team B hits their buzzer while the chaser is still running, nothing should happen. Of course, when Team B hits first, their chaser runs and Team A's chaser cannot start.

The solution I could think of is to use Scripted Functions instead of Chasers. However, we don't currently have variables in scripts. What could also work is Solo frames (only one function can run at a time). However, the second function will stop the first one.

Does anyone have an idea how this could done in 4.12.2? Otherwise, I would start implementing Cross-function variables. Massimo, do you have an opinion on that?

Thanks!

Since I've just learned from the source code that scripts already support labels and jumps, here's an abstract proposal:
- We Introduce two new keywords "setflag FLAGNAME" and "clearflag FLAGNAME". The flags are stored in "Doc" or "Engine" so they can be used between scripts (one sets, one reads)
- We introduce a third keyword "jumpIfFlagSet FLAGNAME LABEL" that does what the name suggests: If the flag is set, a JUMP to LABEL is executed. If the flag is not set, the script continues (the conditional jump line behaves like an empty line).

Sounds reasonable?

Hi Jannis, before discussing about QLC+ 4.12, can you please check if you can do what you need to do with QLC+ 5?
V5 has a much more powerful Script function and you can handle much more complex situations
See this if you have missed it: viewtopic.php?f=17&t=12498

Method "isFunctionRunning" should do the trick for you

Hi Massimo,
Having a much more powerful scripting engine is something that I definitely support! I've read about the new scripting engine of QLC+5 and I'm really looking forward to using it. I haven't yet test the new scripting engine since the Alpha 3 doesn't work properly on Gentoo. Ubuntu is installing right now in a VM to try it

However, for the moment, we know that QLC+ 5 is not ready for production use. That's why we will stick with QLC+ 4 for some time being. Since I assumed it won't take much effort, I've started implementing my ideas in QLC+ 4 and it's working.
Code is at: https://github.com/mcallegari/qlcplus/c ... ForScripts

Short description:
The two new commands setFlag and clearFlag basically modify a QStringList stored in the Document. When switching from Design to Operate, all flags are cleared.
The jump command has been extended with an ifFlag parameter that can be used for conditional jumps.

As a small bonbon, I've fixed the jump/label function in the Script (in current master, the labels are not detected when loading a project) and documented the existing and new commands.

Would you please consider merging the PR if I opened one?

Attached is a QLC+ 4 project demonstrating the new scripting functionalities

I think labels and jumps were an idea of the original creator of QLC.
I never made them "official" for a simple reason: they can create infinite loops.
As a developer I appreciate their usefulness. As the "project manager" please let me explain one thing.
At some point, someone will come here and say: QLC+ hangs. They won't explain (or they will forget) they're using a script with an infinite loop.
Just QLC+ hangs.
That is what I wanted to avoid, since in years nobody really needed labels and jumps anyway.

I could merge your PR, sure, but to be honest I'd prefer a more structured Script language in QLC+ 5.

I do completely agree that the JavaScript-based, structured scripting language is the way to go for the future. As soon as QLC+ 5 is production-ready I will gladly go this way. Unfortunately, I would like to use the feature now (= near future ) and QLC+ 5 is just not ready. And I guess we both agree that porting QLC+ 5's JavaScript-based approach to QLC+ 4 is not worth the effort.

I also agree on the point that labels and jumps can be used to accidentally create loops and that every feature inside a program increases the effort to support it.

That said, here are some options I could think of:
1. We remove the documentation but merge the feature itself (flags and conditional jumps)
If the features are not documented, one has to be "advanced" already to know that they exist and we can assume that they are put to good use. That way, QLC+ fulfils my current need and I'm happy
I could also put a flag into the saved projects such as "ProjectUsesDangerousFeatures" so we can easily detect it and deny support right from the beginning.
It would also be possible to show a warning in the UI in a sense of "You are using features that might make QLC+ freeze. No support will be given in such cases".

2. We leave the feature in and document it as good as possible and try to catch as most dangerous scenarios as possible
The current code already has some "safety hooks" against endless loops (https://github.com/mcallegari/qlcplus/b ... t.cpp#L474, https://github.com/mcallegari/qlcplus/b ... t.cpp#L444). So I think it is not as bad. Even with a structured language, one can easily and accidentally create en endless loop. Of course I'm ready to investigate problems that sound like they could be caused by a mis-behaving scripted function. Just ping me

3. We remove labels, jumps and flags completely
Since in the current master, labels don't actually work, the code could be completely removed to have less dead and broken code inside the app. Would be pretty sad since in my eyes, the feature is pretty useful