SOLVED ScriptExecuteArray new errors?

DevilKap

Member
GML:
/// @function ScriptExecuteArray(_func, _args);

/// @returns any

/// @param {function}    _func    The function to run

/// @param {arguments}    _args[]    The arguments needed



function ScriptExecuteArray(_func, _args) {
    var _func = argument0;
    var _args = argument1;

    switch (array_length(_args)) {

        case 1:  return script_execute(_func, _args[0]);

        case 2:  return script_execute(_func, _args[0], _args[1]);

        case 3:  return script_execute(_func, _args[0], _args[1], _args[2]);

        case 4:  return script_execute(_func, _args[0], _args[1], _args[2], _args[3]);

        case 5:  return script_execute(_func, _args[0], _args[1], _args[2], _args[3], _args[4]);

        case 6:  return script_execute(_func, _args[0], _args[1], _args[2], _args[3], _args[4], _args[5]);

        case 7:  return script_execute(_func, _args[0], _args[1], _args[2], _args[3], _args[4], _args[5], _args[6]);

        case 8:  return script_execute(_func, _args[0], _args[1], _args[2], _args[3], _args[4], _args[5], _args[6], _args[7]);

        default: show_error("script_execute_array: argument not supported!", false);

    }

}
Apparently on line 12 of this script, there are 2 errors that never appeared before.
Script: ScriptExecuteArray at line 12: cannot use function/script name for a variable. using "_func"
Script: ScriptExecuteArrray at line 12: malformed assignment statement
These errors have never appeared before, did a new update cause more problems (agian)?
 

kburkhart84

Firehammer Games
I don't know if it will fix the problem...but why are you still using script_execute()? They haven't said they are deprecating it, but nobody has been able to come up with a use of it that can't be done by simply calling the function by name. This way of using functions came out with 2.3 and was a big part of the update, I see no reason why not use it properly.

Code:
//instead of
script_execute(_func);
//just put
_func();
****
EDIT

I see the problem. You can't really have a local variable with the same name as the variable in the function name. This is also part of the 2.3 upgrade. You can access the argument directly by name instead of setting a variable to "argument0"
 

DevilKap

Member
I don't know if it will fix the problem...but why are you still using script_execute()? They haven't said they are deprecating it, but nobody has been able to come up with a use of it that can't be done by simply calling the function by name. This way of using functions came out with 2.3 and was a big part of the update, I see no reason why not use it properly.

Code:
//instead of
script_execute(_func);
//just put
_func();
****
EDIT

I see the problem. You can't really have a local variable with the same name as the variable in the function name. This is also part of the 2.3 upgrade. You can access the argument directly by name instead of setting a variable to "argument0"
so get rid of the:
GML:
    var _func = argument0;
    var _args = argument1;
 

kburkhart84

Firehammer Games
so get rid of the:
GML:
    var _func = argument0;
    var _args = argument1;
That seems like it would fix the problem, but if I were you I would still get rid of the script_execute functions as well and just call the function directly using the variable name.
 

FrostyCat

Member
I don't know if it will fix the problem...but why are you still using script_execute()? They haven't said they are deprecating it, but nobody has been able to come up with a use of it that can't be done by simply calling the function by name. This way of using functions came out with 2.3 and was a big part of the update, I see no reason why not use it properly.
script_execute is still required for GMS 2.3+ in contexts where you store a script ID for execution later, such as in a job queue or finite state machine pattern.

And for the information, it's definitely not on its way out. Hell, in GMS 2.3.1 they even added script_execute_ext to do what the script hack is trying to do.
 

kburkhart84

Firehammer Games
is still required for GMS 2.3+ in contexts where you store a script ID for execution later, such as in a job queue or finite state machine pattern.

By script ID, are you referring to script resources, or functions? If you mean functions, you can still just use the variable. If you mean executing the script resource(like they get executed right at the beginning anyway), then that's a different story, although I personally would just use functions instead of script resources for it.
 

FrostyCat

Member
I mean this kind of setup:

Script:
GML:
function standing() {
    ...
}
function walking() {
    ...
}
Create:
GML:
state = standing;
Step:
GML:
script_execute(state);
Script IDs are NOT compatible with the direct-variable call syntax that methods can be used with (i.e. state(); would be illegal in the setup above). This is an issue that I raised during the closed beta, but YoYo finally decided against allowing it due to runtime speed concerns.
 

kburkhart84

Firehammer Games
I mean this kind of setup:

Script:
GML:
function standing() {
    ...
}
function walking() {
    ...
}
Create:
GML:
state = standing;
Step:
GML:
script_execute(state);
Script IDs are NOT compatible with the direct-variable call syntax that methods can be used with (i.e. state(); would be illegal in the setup above). This is an issue that I raised during the closed beta, but YoYo finally decided against allowing it due to runtime speed concerns.
Makes sense....but you could still just use a global variable instead of a function like that, would easily fix the problem. That way seems less tedious than using script_execute() to me anyway, though it does require adding a global prefix to use it.

Finally, someone showed me an actual reason to use script_execute(), even if you can still go around it easily enough. At the least it is something...
 

Roldy

Member
Script IDs are NOT compatible with the direct-variable call syntax that methods can be used with (i.e. state(); would be illegal in the setup above). This is an issue that I raised during the closed beta, but YoYo finally decided against allowing it due to runtime speed concerns.
Unsure what you mean. In your example; state(); would work in place of script_execute(state).
 

FrostyCat

Member
I'll admit some fault here: Something HAS changed since I was denied the direct-variable call syntax for script IDs during the closed beta. But I'm not sure what, or if it's even permanent.

Script:
GML:
function foo() {
    show_debug_message("foo");
}
function bar() {
    show_debug_message("bar");
}
Create:
GML:
state = foo;
Step:
GML:
state = choose(foo, bar);
state();
During the closed beta, Russell did answer to my suggestion and implemented a fix, but then told me that he's reverting it because it added too much time checking types during function calls. I'm not certain if this is an accidental leftover from when he experimented with the fix following my report, or if YoYo decided to reconsider my report or another similar one in the meantime. But both the current stable and beta runtimes (2.3.0.401 and 23.1.1.212) demonstrate a perfect run of the above.

Despite this, I still stand by my statement that script_execute_ext exists starting GMS 2.3.1 (verifiable by downloading the beta), and that is indirect evidence that YoYo does not plan to phase out script_execute.
 
Top