How to best @export an inner class.

gaborit

Hi, currently I'm working on adding an @export variable to the abilities of my game:


#AbilityData.gd
extends Resource

class_name AbilityData

@export var ability_name: String
@export var ability_name_UI: String

@export var targeting: Targeting

@export var damage: int
@export var srange: int

currently Targeting is a class that inherits resource:

#Targeting.gd
extends Resource
class_name Targeting

var srange: int
func _init() -> void:
	pass
	
func _initialize(ability:AbilityData):
	srange = ability.srange
	
func tiles(_source_unit: Unit, _BF: BattleField) -> TilePositionArray: #this is a custom class for a collection of tiles
	return TilePositionArray.new()

But this means that every targeting protocol I need has its own .tres file (Area, Melee, Beam, etc), I would love to have all these on the same file using inner classes, something like this:

class_name Targeting

var srange: int
func _init() -> void:
	pass
	
func _initialize(ability:AbilityData):
	srange = ability.srange
	
func tiles(_source_unit: Unit, _BF: BattleField) -> TilePositionArray:
	return TilePositionArray.new()
	
class Melee extends targeting: 
func tiles(source_unit: Unit, BF: BattleField) -> TilePositionArray:
	return  BF.neighbor_tiles(source_unit)

#etc for other protocols

but then the inner classes wont appear on the editor, if I stop extending this as a resource then I get the error.
"Export type can only be built-in, a resource, a node, or an enum." I thought maybe making an enum that interfaces the methods, something like this:

enum targeting_protocols {Area, Melee, Beam}

func return_targeting(protocol:targeting_protocols)

	match protocol:
		targeting_methods.Area:
			return Area
		targeting_methods.Melee:
			return Melee
		targeting_methods.Beam:
			return Beam

This works but I find it unwieldy and non elegant, especially since this Isn't just for targeting, I need this for procs, affecting area, etc. I'm sure there must be a better way.

xyz

gaborit From the docs:

Note: Custom resources and nodes should be registered as global classes using class_name, since the Inspector currently only supports global classes. Otherwise, a less specific type will be exported instead.
https://docs.godotengine.org/en/4.5/classes/class_@gdscript.html#class-gdscript-annotation-export

You need to use a separate script file per your custom resource class. Currently seems to be no way around it.
So create Area, Melee, and Beam classes, and reference each as needed.

GlyphTheWolf

gaborit But this means that every targeting protocol I need has its own .tres file

That is not exactly true. You may create one resource for each type in separate file and then just refer created .tres files, but you can also use Godot sub-resources and just create specific type whenever you need it in your ability.

For example you want to create new ability, let's say "SwordSlash", then you create new resource of type AbilityData and as targeting you does not select .tres file, but just create new MelleTargeting type resource (from the inspector). Then it's just sub-resource stored in your "SwordSlash" ability data itself. That way you treat MelleTargeting more as a type of Targeting you can choose from, than actual resource. In Godot 4.5 you can also make Targeting class itself to be @abstract, so it won't be available to choose from when selecting new targeting in inspector (you can only select specific targeting protocols, but not general type).

You may think it doesn't look as a good solution, because then your resource is created many times even though you actually keep only logic, which is always same for any reference to this resource, but cost of that is actually not so much (because at the end it is just object creation) and it also gives you some more flexibility. If you want to add any specific data for targeting protocols later, (like let's say you want to add cone and you need to specify angle, which is specific to cone only and not needed for any other targeting protocol) you can just @export specific data for given protocol and automatically, when you select new > ConeTargeting, you can also specify custom angle for each ability.

gaborit

GlyphTheWolf
But this would mean that I cant reuse the same targeting for multiple abilites, right?

xyz

gaborit But this would mean that I cant reuse the same targeting for multiple abilites, right?

Why not? Any ability class can have a property of any targeting class.

gaborit

From what I understand, say, I have a "SwordSlash" ability, and through the inspector I create and assign a MeeleTargeting to the targeting exported variable. But since I'm creating it through the inspector I can't reuse the same resource on another node.

If I'm wrong please I would love a visual example.

xyz

gaborit No, you can totally reuse it. That's the whole point of resources.

Create/assign the resource in the inspector, then right click on the down arrow next to it and save it to disk. For the next ability, instead of creating a new resource - load that one from the disk.

It's the fundamental mechanism of sharing resources in Godot. Without that, resources would be almost useless.

Alternatively, you can also copy-paste a resource. In that case the internal resource will be shared as well since both objects will hold a reference to the same resource object.

I'd go with saving though as you have a better oversight of what is happening.

GlyphTheWolf

gaborit

Here is example from my project how I use approach I described before:

I consider that my EffectApplier is something similar to your Targeting. It holds mostly some logic and data for that logic customization (in my case AttackDamageMod describe in code how to modify damage deal by character and exported Damage Mod is how it should modify damage). When I want to add some applier for effect I just create appropriate one "one the fly" as sub-resource, without saving it in .tres file (it is saved in specific effect .tres file). I don't think it's downside that I create many sub-resources of the same type by this method, because I don't want to manage thousands of file like "AttackDamageMod_1.tres, AttackDamageMod_2.tres, ... (and so on for all possible values I will use)".

Of course in this case new object is created for every Effect I define, but unless your resource is something very heavy (like holding textures, models etc.) then I don't think it's something bad.

If your Targeting types won't have any specific fields for logic customization, then you can also just save all targeting types as separate .tres files and reuse them, but as long as your Targeting object mostly describes some logic (and is not holding very large resources or data) I think creating multiple objects of same targeting type is not much cost and gives you more flexibility.