Fix C# Hint NodeType and ResourceType HintString

[ZerxZ]

Fix #91644

[raulsntos]

Thanks for contributing to the .NET module! This looks really nice although I feel like it goes against the current behavior.

The way [Export] currently works we don't usually override the hint and hint string computed from the property type, the type takes precedence over the attribute. This means if you have an exported property with an enum type, you can't change how the enum members will be displayed even if you specify it in the attribute.

I'm a bit worried that this change will make things a bit confusing to users, because now some times the type will take precedence and others it will be the attribute.

My personal preference would be for the attribute to always override the type, since I believe when the user is being explicit we should respect that. However, this is a behavior change that may be a bit too disruptive for existing users.

And now that I laid out my concerns and personal preferences, I'd love to hear what other .NET contributors think.

[paulloz]

My personal preference would be for the attribute to always override the type, since I believe when the user is being explicit we should respect that.

Same thing, I feel like always respecting the explicit metadata given by the user (if valid) is what we want / what anyone would expect.

However, this is a behavior change that may be a bit too disruptive for existing users.

Is it disruptive? I'd imagine existing users either

• Don't have hint string specified: no disruption for them.
• Have some hint string specified, but it does nothing¹: the behaviour will change, but how likely is it that users leave not working hints in their code?
• Have some hint string specified, and it works²: the behaviour should not change here, no disruption for them.

Or is there something I'm missing/misunderstanding?

Footnotes

1. [Export(PropertyHint.ResourceType, nameof(Texture2D))] public Resource Resource ↩

2. [Export(PropertyHint.ResourceType, nameof(Texture2D))] public GodotObject Resource ↩

[ZerxZ]

GDScript: Add @export_custom annotation #72912
Should [Export] be used consistently with @export_custom?
@raulsntos @paulloz

---

The new @export_custom allows this.

extends Node
enum Alignment { 
 Good,
 Neutral,
 Evil
}
@export_custom(PROPERTY_HINT_NODE_TYPE,"Node2D,Object") var node:Object
@export_custom(PROPERTY_HINT_NODE_TYPE,"Node2D,Resource") var node2:Node
@export_custom(PROPERTY_HINT_RESOURCE_TYPE ,"Node2D,Texture2D") var nodeResouce:Resource
@export_custom(PROPERTY_HINT_RESOURCE_TYPE ,"Node2D,Texture2D") var enumResouce:Alignment

I don't think [Export ] in C# should prevent users from using .
As long as both Hint and HintString are available, the user should be allowed to use them.

public partial class CustomNode: Node
{
    public enum  Alignment { 
        Good,
        Neutral,
        Evil
    }
    [Export(PropertyHint.NodeType, "Node2D,Object")] public GodotObject Node;
    [Export(PropertyHint.NodeType, "Node2D,Resource")] public Node Node2;
    [Export(PropertyHint.ResourceType, "Node2D,Texture2D")] public Resource NodeResouce;
    [Export(PropertyHint.ResourceType,"Node2D,Texture2D")] public Alignment MyResource;
}

Even if something goes wrong, it should be thrown a warning by the editor instead of being directly overwritten by the source code generator.

[raulsntos]

Or is there something I'm missing/misunderstanding?

@paulloz No, I think you got it perfectly. Whenever something changes behavior I get a little nervous, but I think you are completely correct that it won't be disruptive, thank you.

Should [Export] be used consistently with @export_custom?

@ZerxZ Yeah, I think the GDScript annotation fulfills the same use cases. Thank you for showing how @export_custom works, this was helpful. I think it makes sense to follow the same behavior, and it probably matches user expectations when using the attribute.

---

So it sounds like there's consensus on allowing explicit hints override computed hints, since explicitness indicates intention. We should probably make sure other hints also work like this, but that would be work for a follow-up PR.

This PR goes in that direction and works as expected, so I'm approving.

[ZerxZ]

Or is there something I'm missing/misunderstanding?

@paulloz No, I think you got it perfectly. Whenever something changes behavior I get a little nervous, but I think you are completely correct that it won't be disruptive, thank you.

Should [Export] be used consistently with @export_custom?

@ZerxZ Yeah, I think the GDScript annotation fulfills the same use cases. Thank you for showing how @export_custom works, this was helpful. I think it makes sense to follow the same behavior, and it probably matches user expectations when using the attribute.

---

So it sounds like there's consensus on allowing explicit hints override computed hints, since explicitness indicates intention. We should probably make sure other hints also work like this, but that would be work for a follow-up PR.

This PR goes in that direction and works as expected, so I'm approving.

Thanks! 🎉

[akien-mga]

Thanks! And congrats for your first merged Godot contribution 🎉

[ZerxZ]

Thanks! And congrats for your first merged Godot contribution 🎉

Thanks! 🎉