class_name HitComponent
extends Area2D
@export var current_tool : DataTypes.Tools = DataTypes.Tools.none
@export var hit_damage : int = 1
Line 4:Could not find type “DataTypes” in the current scope.
Line 4:Identifier “DataTypes” not declared in the current scope.
Line 4:Cannot use simple “@export” annotation because the type of the initialized value can’t be inferred.
Ok, well I don’t see it in the code you posted. In the code you posted, the answer to my question is you are not defining DataTypes anywhere.
What it loos like is you should have a data_types.gd script somewhere that contains an Enum called Tools. That script should either have no class name and be added as an Autoload with the name DataTypes, or it should have a first line of class_name DataTypes
Hmmm, actually I am new to programming so I didn’t understand what you mena at first also it’s strange why in the video there was data types if there was no explanation how to use them or just to show how to use.
Ensure they only have one instance: An autoload assures this because of the way it is intended to be used. Specifically the way it is implemented you cannot give it a class_name which prevents you from using it anywhere than as an Autoload.
Provide easy access to that instance: As an autoload you give it a global name that is always accessible and always brings up the same single instance of the script. If you have variables in that instance they are used across all accesses of the the autoload.
Control their instantiation (for example, hiding the constructors of a class): While there are certain ways that most languages allow you to create singletons by making every method static and making the constructor private - these are not a requirement of the design pattern itself.
Having constructed singletons this way when I first started GDScript, I can also tell you that while Godot allows this implementation, it also requires you to jump through some crazy hoops if you want to make signals static. (You have to create a non-static signal for the static signal to call.) And so it is easier to use an autoload to make a singleton with GDScript.
When the Gang of Four wrote Design Patterns it was a book that talked about definions - not implementation. Despite the fact it was written mainly to be used with C++. They were looking towards the future, and 30 years later, people are still referencing their work because they didn’t put implementation details in their patterns.
But in Godot you can instantiate another copy so therefore you cant ensure there is only one instance, ever. So Godot’s autoload fail on that first (and most important) requirement.
Autoloads in Godot are simply scripts that get loaded automatically nothing more, and all global access (in GD Script, in C# its a little more complicated). Therefore technically they don’t follow the Singleton pattern.
You’re argument is essentially, “If you use this feature incorrectly it won’t work as intended.”
That’s true.
Yes, I read that in the docs and avoided Autoloads for a long time because of it. But practically, as long as you use autoloads correctly they are in fact singletons.
In fact, I believe that the docs are wrong in their warning, because I think we are all biased by how we learned to create singletons. There’s nothing in the definition that says code must enforce one instance. Also, having the singleton not enforce it means that it doesn’t violate the Single Responsibility Principle.
Regardless, I think we’re going to have to agree to disagree on this one.
I don’t disagree that they are in effect singletons, but purely technically (which is why I said ‘even more pedantic’) they don’t follow the design pattern.
I’m not making this a serious discussion btw, and not trying to wind up, just including my level of pedantry.