Multibutton Turbo/Rapidfire Script Issue?

[psnGoEx]

I've had a rapidfire script I wrote for T2 years ago, recently wanted to make it more robust by adding multiple button combinations instead of just doing one button at a time.

Oddly when adding a combination press with a new combo that reacts correctly to the buttons being put on turbo, after a short while the device stops activating the script. Looking at the logs it will sometimes suddenly look like it rebooted the script multiple times and then just no longer works.

The log attached shows when the script has been loaded from memory slot 9, then following the initial indicator of the button press wait and duration times.

2 minutes of testing later, it spams the logs as if it reloaded multiple times? with one log showing incorrect init values of 20 and 500, which doesn't make sense as the default is 50 and 50.

Looking for clues or solutions such as:
- The titan two cannot handle multiple buttons being held down and rapidly executing different buttons on turbo.
- Is the rate of input too intense that the system watchdog is catching something and resetting the device.
- Script needs to be fully rewritten so that it can handle multiple buttons elegantly instead of relying on different run_combo combinations.

Thanks

[Scachi]

T2 can handle lots of combos at the same time.
Perhaps you are flooding the output panel with too many text outputs in a very short time ? Make sure your T2 and gtuner IV software are updated.
I guess there is some problem/bug in how the code is written or extended.
Hard to tell without seeing the code.

[psnGoEx]

Thanks for the response Scachi, there is actually no text outputs. The output there is only shown when the script initializes.

Code: Select all

 
init {
    pmem_load();
    pmem_read(0, &input);
    printf("input: %d", input);
    pmem_read(1, &delay);
    printf("delay: %d", delay);
    pmem_read(2, &upEnabled);
    pmem_read(3, &downEnabled);
    pmem_read(4, &leftEnabled);
    pmem_read(5, &rightEnabled);
    pmem_read(6, &triangleEnabled);
    pmem_read(7, &circleEnabled);
    pmem_read(8, &crossEnabled);
    pmem_read(9, &squareEnabled);
}
 

Some samples from the script:

Code: Select all

 
main {
    if(is_active(PS4_L2) || is_active(PS4_R2)) {
        turboMode = TRUE;
    } else {
        turboMode = FALSE;
    }
 
    if(turboMode) {
        ColorLED(CW, 10);
        if((is_active(PS4_TRIANGLE) && triangleEnabled) && (is_active(PS4_CIRCLE) && circleEnabled)) {
            combo_run(turboTRIANGLECIRCLE);
        } else {
            if(is_active(PS4_TRIANGLE) && triangleEnabled) {
                combo_run(turboTRIANGLE);
            }
            if(is_active(PS4_CIRCLE) && circleEnabled) {
                combo_run(turboCIRCLE);
            }
        }
        if((is_active(PS4_CROSS) && crossEnabled) && (is_active(PS4_SQUARE) && squareEnabled)) {
            combo_run(turboSQUARECROSS);
        } else {
            if(is_active(PS4_CROSS) && crossEnabled) {
                combo_run(turboCROSS);
            }
            if(is_active(PS4_SQUARE) && squareEnabled) {
                combo_run(turboSQUARE);
            }
        }
    } else {
        ColorLED(CW, -1);
    }
}

The rest is just the combos being used and it's just simple val inputs with the delay and wait times.

[Scachi]

only use LED commands in combination with event_active, event_release or any other specific timing to not spam led commands all the time as you are doing at the moment. that can cause issues.
as a test you can try without the led commands.

ATTENTION: ! This function should NOT be called on every interaction of main !
Take a look at the documentation for more information:
viewtopic.php?f=23&t=10962&p=75648#p75648

[psnGoEx]

Ah, thanks Scachi. I had a feeling that could have been the oversight, I will modify the script and we shall see how it holds up.