You need to export them from your script.
Godot
Welcome to the programming.dev Godot community!
This is a place where you can discuss about anything relating to the Godot game engine. Feel free to ask questions, post tutorials, show off your godot game, etc.
Make sure to follow the Godot CoC while chatting
We have a matrix room that can be used for chatting with other members of the community here
Links
Other Communities
- !inat@programming.dev
- !play_my_game@programming.dev
- !destroy_my_game@programming.dev
- !voxel_dev@programming.dev
- !roguelikedev@programming.dev
- !game_design@programming.dev
- !gamedev@programming.dev
Rules
- Posts need to be in english
- Posts with explicit content must be tagged with nsfw
- We do not condone harassment inside the community as well as trolling or equivalent behaviour
- Do not post illegal materials or post things encouraging actions such as pirating games
We have a four strike system in this community where you get warned the first time you break a rule, then given a week ban, then given a year ban, then a permanent ban. Certain actions may bypass this and go straight to permanent ban if severe enough and done with malicious intent
Wormhole
Credits
- The icon is a modified version of the official godot engine logo (changing the colors to a gradient and black background)
- The banner is from Godot Design
Tried that already:
@export var anchors: Array[Anchor]
Line 15:Export type can only be built-in, a resource, a node, or an enum.
Is there a way to get around this?
Tried your code on a ready entity of my project, and indeed, @var anchors: Array[Anchor]
can't be exported if it's in the same script.
What you could do, however, is initialize anchors as an empty array, @export var anchors = []
- This solves half of the problem, as you still won't be able to add Anchor objects within the editor, because they "don't exist".
The likely solution in this case is making that Anchor class a standalone .gd file and add it to the Autoload list (Project Menu -> Project Settings -> Autoload tab). With this done, your original @export var anchors: Array[Anchor]
will now work, because now that Godot autoloads it (makes it globally accessible), it "exists"
EDIT - Here's the doc on _get_property_list
https://docs.godotengine.org/en/stable/classes/class_object.html#class-object-method-get-property-list - From the example there, it added new things that don't "exist" that should now show up on the editor. The thing is, it doesn't specify if a locally created class would also work there.
#Might still be worth a shot, eh?
func _get_property_list():
var properties = []
properties.append({
"anchor_offset": Anchor.offset,
"anchor_connected": Anchor.connected,
"anchor_end": Anchor.end
})
return properties
@ICastFist @Bezier I agree with your overall explanation, but I would instead recommend using the class\_name
directive instead of adding it as an auto-load.
Auto-load will make it that a single Anchor
instance always exists in the root scene, and that Anchor
elsewhere in your code will always reference that single(ton) instance.
If you want Anchor
to behave like other built-in classes in your scripts and the editor, you need to give it a class\_name
and *not* use the same name ("Anchor"
) for an auto-load.
Had to look up how to do that, as apparently the docs don't have that kind of information. I did come across this SO question. So, the solution would be:
#anchor.gd
class_name Anchor
var offset: Vector3
var connected: Node3D
var end: bool
And that would create this new, readily accessible class throughout the project, correct?
@ICastFist also yes, the docs aren't that great at providing info on this in the reference.
There *is* a good page in the manual, however: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/static_typing.html
OP @Bezier you probably want to check this out if you haven't found it already by now, specifically the "Custom variable types" section.
@ICastFist more or less, but you still probably want your Anchor to extend something, be it Object, Node, Node2D, Control, etc.
If your anchors are going to be part of the scene tree, as in you're adding them as node children of (an)other node(s), then you will need to at least extend Node
. If you want your anchors to have a position, then Node2D (or 3D depending on how you need it to behave). If your anchors are part of your ui, then Control might directly be the best, and so on.
If your anchors are not going to be part of the tree itself, but just stored and/or passed around by nodes as data, I would encourage you to give this page of the docs a read: https://docs.godotengine.org/en/stable/tutorials/best_practices/node_alternatives.html
Thanks for that link, I now have learned why it didn't originally work (and that other features like reference counting aren't employed by default!).
The solution, if anyone needs this in the future:
# Separate file
extends Resource
class_name Anchor
@export var offset: Vector3
@export var connected: Node3D
@export var end: bool
It adds namespace pollution, but I'll deal with it by prefixing it with the original script's class.
@Bezier yeah it's good to know about the differences between Object and RefCounted when you're making custom data containers.
Personally, I've been suffixing my custom/"game object" resources with "-Rs", as in I have PlayerRs
, FileRs
, DownloadRs
, etc.
The namespace pollution is definitely part of the trade-off from just preloading wherever you need the class.