correojon Yeah, I know what you mean. So basically not just some global enums but also global functions, but slightly grouped together thematically. Makes sense, indeed.

    Not sure if this was mentioned already but all enums are global, they are just guarded by class namespaces. There's no need for autoloads i.e. you don't need any objects to access them. If enum is declared in a named class, it will be accessible in all other classes.

      xyz this seems self-explanatory now that you mention it. I use FileAccess enums all the time without instancing it. unfortunately i wasnt listening to the little voices inside my computer telling me the obvious.
      thanks for making my hackjobs less hacky.

        xyz Can you give an example for this? Because when I have a file enemy.gd...

        # enemy.gd
class_name Enemy extends Node2D

enum Foo { red, green, blue }
# [...]

        ...and then try to use the enum Foo from another script I cannot access it.

        # another.gd
print(Foo.red)
print(Enemy.Foo.red)

        This would only result in errors. Am I missing something here?

        • xyz replied to this.

            Toxe Enemy.Foo.red should work. Assuming you're in 4.x

            • Toxe replied to this.

                xyz I am, but it doesn't.

                • xyz replied to this.

                    Toxe Don't forget to save *.gd files.

                    • Toxe replied to this.

                        xyz Looks like I never really tried actually running that code because at runtime it does indeed work. But the editor gives an error message and suggestions don't work either. So in a way it does work if you don't mind a lot of red lines and error message in your code. 😉

                          Okay I restarted the editor and now the red error is gone and suggestions do indeed work. But once I add another value to the enum and try to print that the error comes back.

                          You should submit a bug report on the github tracker.

                          • Toxe replied to this.

                            I haven't encountered any funky behaviors so far. It works as expected. Anyway, bugs aside, the point is - enums are global by design.

                            • Toxe replied to this.

                              xyz If they are global shouldn't print(Foo.red) then work?

                              • xyz replied to this.

                                  Toxe If they are global shouldn't print(Foo.red) then work?

                                  They are accessible globally but name-wise they are guarded by class namespaces. In other words, you need to use the class name when accessing, but you can do it from anywhere, hence the access is global. In your example Enemy.Foo is a global enum.

                                  Btw this is analogous with access to static class methods and properties. If you declare something static it becomes globally accessible via class namespace. In 3.x you can have static methods but no static properties. They neatly added this in v 4 so now we can have both, making the old autoload hack pretty much obsolete.

                                    7 months later

                                    I know this is an old topic but I made a benchmarker that can show you how much faster or slower using various types of variable references are: https://github.com/elvisish/ElvisishBenchmarker

                                    I usually keep enums in the same script for the reason that frequently (every frame) referencing singletons is much slower than a local script reference, but it might not be a big deal if you're only referencing them ocassionally.

                                    • xyz replied to this.

                                      elvisish What do you mean by "referencing singletons"?