New Function Error

Completed

Comments

6 comments

  • Julian Adams

    This is an order of execution problem, which is non-obvious due to GM's internal behaviour being opaque.

    whenDeclaringStructThenOk doesn't exist as a defined function until the script is executed on boot. _MainCaller_Structs (the script) is being executed before whenDeclaringStructThenOk (the script) so whenDeclaringStructThenOk() (the function) doesn't exist for _MainCaller_Structs.

    It's possible to check if a function has been defined by using variable_global_exists(). This'll mitigate the crash, but it doesn't help solve the core issue - that script execution order being undefined will lead to obscure, confusing situations when trying to handle dependencies.

    Reordering the scripts in the IDE doesn't help here because the execution order is undefined and entirely unrelated to how scripts are laid out in the IDE. In principle, it's possible to write yourself an initialisation handler to help untangle this sort of problem but that is a lot of work.

    0
    Comment actions Permalink
  • Cesar Ottani

    Well, I am using a manual example as I would use any other programming language. Usually the compilers handles the precedence. To do something here, on the user side, I thinks it's a mistake and this kind of issue should be handled by the engine.

    1
    Comment actions Permalink
  • Julian Adams

    This is a problem that'll come up again and again, I think, because what Cesar's doing the obvious things that people will do. This boils down to two issues, I feel:

    1) Execute-on-boot already exists in the form of gml_pragma("global", "..."). Some of my peers have investigated using it with GMS2.2.5, but ultimately it doesn't get used much explicitly because script execution order is undefined. This rather implies execute-on-boot as a feature needs more consideration. Presumably YYG have spent some time thinking about why global pragma execution isn't popular, but I don't recall seeing anything said about the topic.

    2) The behaviour we're seeing in this test project is unintiuitive, both considering how GameMaker has historically worked (esp. room order) and how other languages work. Whilst we as programmers can roll our eyes at this because *of course* this is how things work, the fact remains that the vast majority of GM users are not programmers and aren't familiar with untangling OoE bugs in GM's closed source runtime.

     

    0
    Comment actions Permalink
  • Core Tech

    This was a simple bug and nothing to do with Order of Execution problems - it has been fixed internally and will be in the next Closed Beta release (which we are preparing now).

    Russell

    1
    Comment actions Permalink
  • Cesar Ottani

    Glad to know that it's simple and has already been fixed. Thanks, Russel. =]

    0
    Comment actions Permalink
  • YoYo QA Dept

    Thanks everyone for the replies and the discussion.

    As the issue has been addressed, I'll set this thread as "Answered".

    Thank you again,

    Alice 

    0
    Comment actions Permalink

Please sign in to leave a comment.