I do it the same way, except that I use UPPER_SNAKE_CASE for enum keys:

enum EnemyType {
    UNKNOWN,
    BAITER,

That's the convention used by the API enums and the style guide.
https://docs.godotengine.org/en/4.1/classes/class_control.html#enumerations

  • Toxe replied to this.

    Erich_L Yeah that works but it's a bit too much redundancy for my taste. But I also need to use these enums in more than one other place.

      DaveTheCoder Right, but I don't like that style too much. At least for my own code, I don't mind it in the Godot API or code from other people.

      I come from C++ and ALL_CAPS to me always means that it's a preprocessor declaration or macro and I usually tend to go with Enum::SomeValue or Enum::some_value. I can never really agree with myself which style I prefer haha. 😉

      But thanks, good to know that this seems to be a plausible way of using global enums.

        I had to declare some global enums today and I did it as you did (autoload script), but with a slightly different approach: Instead of creating an "Enums" script, I used an "EnemyUtilities" script. In it I've placed some general purpose functions related to the enemies, that may be used by the enemies themselves or other entities. For example, I have a function that defines how the enemies should move, which I also need to call from a separate node that draws a preview of the movement, or a function that returns a different color depending on the enemy type and that is widely used from many places for FX, UI, materials...Hope you find this useful 🙂

        • Toxe replied to this.

          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.