Why I am getting this error?

Godot Version

Godot 4.4

Question

I am geting this errors but idk why

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.

Where are you defining DataTypes?

1 Like

In my hit component script, i was watching tutorial how to create tree chopping code so that i coded from there

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

4 Likes

If you want to use variables from other scripts, those variables must be static, or you need to set the script as a global autoload singleton.

2 Likes

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.

1 Like

Thanks I didn’t know about this.

1 Like

To be pedantic, you don’t have to in GDScript, but you should.

2 Likes

To be even more pedantic an autoload isnt technically a singleton.

1 Like

Agree to disagree. According to the definition of a singleton it must:

  • 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.

1 Like

I have no clue what are you talking about, but it seems interesting :sweat_smile:

1 Like

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.

Its in the docs:

Why would you do that though?

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.

1 Like

You wouldn’t , that would be bloody stupid! :rofl:

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. :smiling_face_with_sunglasses:

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.