Skip to content

Add behavior change note for @export_file annotation in Godot 4.4 #11075

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

Ayush41
Copy link
Contributor

@Ayush41 Ayush41 commented Jul 2, 2025

This PR updates the "Upgrading to Godot 4.4" documentation to include a breaking change notice for the @export_file annotation.

As of Godot 4.4, setting a value via the Inspector stores it as a uid:// reference instead of the familiar res:// path. This causes mixed path formats and may break assumptions in GDScript or serialized .tscn/.tres files.

Based on issue #11065

Details

  • In 4.4, @export_file behavior changed, and there's no built-in way to retain res:// paths from the Inspector.
  • Users must manually edit .tscn or .tres files to preserve the old path style.
  • In 4.5, a new annotation @export_file_path was introduced to restore the original behavior explicitly.

This documentation update helps users understand:

  • Why their exported paths changed.
  • How to work around it in 4.4.
  • What to use in 4.5+ to restore the previous behavior.

References

Let me know if this needs formatting changes or should be placed in a different section.

@Calinou Calinou added enhancement area:manual Issues and PRs related to the Manual/Tutorials section of the documentation cherrypick:4.4 labels Jul 2, 2025
@AThousandShips AThousandShips changed the title Added breaking change note for @export_file behavior in 4.4 Add breaking change note for @export_file behavior in 4.4 Jul 7, 2025
Copy link
Member

@Calinou Calinou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would list this as a behavior change in the Core section rather than a breaking change. While it may break things in your project, it won't cause a project with formerly valid API usage to be invalid (this is generally what's understood as a breaking change).

@Ayush41 Ayush41 changed the title Add breaking change note for @export_file behavior in 4.4 Add behavior change note for @export_file annotation in Godot 4.4 Jul 8, 2025
@Ayush41
Copy link
Contributor Author

Ayush41 commented Jul 17, 2025

@Calinou Just checking in, looking to update or close the PR if it's no longer relevant. Let me know if any changes are needed! :)

Comment on lines +68 to +72
Related issues:

- PR: `Add @export_file_path to export raw paths (no UID) <https://github.com/godotengine/godot/pull/105414>`_
- Issue: `@export_file behavior change is breaking <https://github.com/godotengine/godot/issues/11065>`_
- See also: `ProjectSettings stores UIDs for file paths <https://github.com/godotengine/godot/pull/104818>`_
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things here. One linking to the two issues is excessive. It's helpful for a documentation review since that gives me an easy way to verify information, but as an end user it's not helpful.

Two, the link to the PR should be formatted like the other links on this page. but don't just leave it down here, put it after "instead of the traditional res:// path. " in the beginning of the warning.


.. warning::

The behavior of ``@export_file`` changed in Godot 4.4. When assigning a new value from the Inspector, the path is now stored and returned as a ``uid://`` reference instead of the traditional ``res://`` path. This is a **breaking change** and may cause issues if you're expecting ``res://``-based paths in scripts or serialized files.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line as well as line 66 need to be broken up. We don't like endlessly long lines. Technically we have no official hard limit. But when I can see it spilling out onto multiple lines on github that's a problem. Personally I make lines 85 characters long at maximum, but again that's not an official limit. It just needs to be shorter and broken up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:manual Issues and PRs related to the Manual/Tutorials section of the documentation cherrypick:4.4 enhancement
Projects
None yet
Development

Successfully merging this pull request may close these issues.

"addons" folder should be renamed to "plugins"
4 participants