Deprecate old variable actions and conditions in extensions

[D8H]

• The extension variables must be used instead
• Old extensions can be maintained by copy-pasting existing actions and conditions from the extension events

It will avoid confusion when selecting external variable instructions by mistake (especially because there is a 8/9 chance to select them in the search).

These instructions were kept to help with the transition but they do more harm that good:

• You have to guess that you have to use Variable() and GlobalVariable() when it's not used anywhere else
• There is no autocompletion of variable names.
  • which is a pain
  • lead to think it won't work
• They break extension encapsulation
• The new system may require to pass some values by parameters instead of accessing external variable directly but you get:
  • parameter names autocompletion in variable conditions
  • you can use parameter names in expressions directly (with autocompletion too)
  • clearer functions and avoid spaghetti code
  • extensions easier to reuse in another project

[Silver-Streak]

So I agree this improves the search (and some sort of improvement is needed), but this breaks the concept of functions and global variables

Extensions are still the only way to realistically build your own functions, and functions need a way to access program-wide global variables (not just function variables).

I'm not saying this change shouldn't be made, but there still needs to be a way to access globals (and potentially even scene variables) from within project specific functions, especially as that's also a standard expectation in base Javascript and most languages.

This might also just be solvable by having the extension variable conditions/actions/etc be labeled as extension variables, or (probably preferably) having the project level variable conditions/actions/expression be renamed to specify External variables in their naming (rather than their path) within the extension editor.

This is also important because passing the variables back and forth via parameters and duplicating globals inside project specific extensions triples the source code weight of each variable, and that increases even more if you have to pass the values once off via an action or condition (and makes it worse spaghetti code than it would be today)

Again, to be clear: I still think a change is needed from current state, but it shouldn't be to remove needed functionality for project specific extensions.

[D8H]

I'm not saying this change shouldn't be made, but there still needs to be a way to access globals (and potentially even scene variables) from within project specific functions, especially as that's also a standard expectation in base Javascript and most languages.

Technically:

• accessing scene variables from extension variables is not possible because from an extension, the event editor can't know which scene to use to get scene variable declarations
• giving access to project global variable from the same action and condition than extension variable would be easy to implement, but I think it would do more harm than good

I haven't use many languages but I've rarely seen variable used in a global context. I wouldn't even be able to say if it's possible or not even though I used these languages for years.
I guess public static class members are somewhat similar to variables in a global scope, but in the code-bases or libraries I worked with, they were always in read-only and, most of the time, private so they weren't actually globally accessible.

For GDevelop, an expression is similar to a public read-only static class members.
When I wrote templates with dedicated extensions, I can't remember feeling the need to access the same variables in the scene and in the extension. I usually use expressions for accessing the state of the extension which is usually a very few values compared to the internal state that is hidden.

Modifying the same state from everywhere (scenes events and extensions events) is what is called spaghetti coding. It's very hard not to end-up in this situation even for trained coders. Languages usually give tools to avoid it. For GDevelop, I think that restricting variables to extensions is one of these tools.

Note that, in extensions, there is still action and condition to access object variable that are used by scene events. We can't enforce usage of behaviors and properties yet because properties can't be structures nor arrays at the moment.

[Silver-Streak]

I haven't use many languages but I've rarely seen variable used in a global context. I wouldn't even be able to say if it's possible or not even though I used these languages for years.

Global scope variables used in functions/elsewhere in an app is relatively common in Javascript, at least when used in business apps, for the need to declare things at the global application or project level that will be used across scopes or in functions built by other developers. This is true even in strict mode in browsers: https://www.w3schools.com/js/js_scope.asp

C++ has the same concept and usage as Javascript: https://www.geeksforgeeks.org/cpp-global-variables/

Lua has a similar concept, although it basically treats every variable as global unless explicitly set up as local:
https://www.codecademy.com/resources/docs/lua/variables

I agree with not accessing scene variables (the use cases for scene variables are very small), but the ability to access global variables from within project-specific extensions is pretty important.

While I have a few specific use cases, the most common one I run across is setting up input functions.

• To avoid repeating OR statements, keyboard conditions, and gamepad conditions on every single event that deals with control inputs, I set up a function that builds one condition per input type (e.g. Up/down/attack/etc input is pressed) which checks against all input types (keyboard, gamepad, maybe even mouse/touch).
• I have global variables set up with the current gamepad/keyboard configuration, and need to be able to access the global variables from the function to ensure it is testing against the currently set up keybinds (keybinds/gamepad binds are important from an accessibility standpoint), and those can't just be stored in the extension because I need to save/reload them whenever the game loads.
• I need to be able to access these variables regularly from a normal event sheet, for displaying the correct button prompts for an action based off those current bindings

Is it physically possible to accommodate this use case after your proposed change? Yes, but then you have to replicate the entire variable structure both in and outside of the extension, then set up events that pass the updated data back and forth, but that's an entire duplicated set of variables, and extra events to pass those variables back and forth on every scene, every time the key bindings are updated, or the game is loaded/saved, etc.