Replies: 37 comments 173 replies
-
|
Can a project setting be added to disable this feature? I would assume turning UIDs on at a later time when the feature is actually needed by a project would be possible, otherwise, turning it on with 4.4 would break everyone in the first place. What are the pros and cons of such a project setting? |
Beta Was this translation helpful? Give feedback.
-
|
For reference, there is an implementation already: godotengine/godot#100973 |
Beta Was this translation helpful? Give feedback.
-
The discussion in that referenced PR is long and ongoing. I thought we were supposed to discuss UID related feedback here? Who's moderating in the "we" above, or should I jump in? |
Beta Was this translation helpful? Give feedback.
-
|
feature as implemented currently, it's present in Godot 4.4-dev5 and later dev snapshots here (current as of this writing): https://godotengine.org/article/dev-snapshot-godot-4-4-beta-1/#downloads alternate/complimentary issues and proposals: a pull request that offered some reference implementation: the PR that implements the changes discussed in the article on 4.4-snapshots: separate but related/affected issues: |
Beta Was this translation helpful? Give feedback.
-
|
I think it's important for everyone to voice their concerns but it's equally important to say that some of us think the current implementation is a clear improvement. uids are a pragmatic, relatively simple solution to a widespread problem with resources (they cannot be moved outside of the editor). It's already the case that users must move There is value in a simple solution in term of maintenance. As everybody knows, godot is maintained mainly by volunteers so any over-engineered solution should raise some eyebrows. Most people complain about the file system being cluttered but some users already have pointed out solutions to alleviate the problem in external editors:
|
Beta Was this translation helpful? Give feedback.
-
|
I think the main issue is that it solves the problem for those who exclusively use external applications that support |
Beta Was this translation helpful? Give feedback.
-
|
Just want to add a programmer's perspective.
I barely aware of the
Visually we can hide them and call it a day, but these extra files can put pressure on the filesystem for Windows users. I think you'll agree that the Windows File Explorer performs significantly worse than Linux when handling a large number of small files. (If not go clone Linux kernel and try delete the repo in File Explorer, that's how I learn this.) RPGs can easily reach several thousands of assets. It is a pain point, but we haven't given it enough attention. |
Beta Was this translation helpful? Give feedback.
-
|
Kinda disagree with
|
Beta Was this translation helpful? Give feedback.
-
|
If use external tool/plugin to hide ".uid" and make it sync with the source file is reasonable, we can do the opposite, use external tool/plugin to notify Godot Editor to update dependency relationship without ".uid" files, this is more elegant, right? Edit: obviously use external tools/plugins to hide this problem is not reasonable, we can't force users to install them. |
Beta Was this translation helpful? Give feedback.
-
|
VS Code nested files does not work at alleviating the issue of manually moving .uid files. Moving the parent does not (and cannot) move the nested .uid file. A VS Code user still has to manually move .uid files. It helps remind you that you need to manually move the .uid, but it isn't a full solution. |
Beta Was this translation helpful? Give feedback.
-
|
For newcomers: If you want to see the feature in action, it's present in Godot 4.4-dev5 and later releases. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the tip! I'm new to Godot and am learning the ropes, so I don't mind this as it isn't a "new" feature for me. I can certainly understand the reservations of Godot veterans. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Just to give my 2c: i would rather have "magic" in my scripts than whatever these .uid files are |
Beta Was this translation helpful? Give feedback.
-
|
If annotating the uid in source files is magic, then using the uids to load resources must look like a spell. I see too much drama about a one line annotation of something that, in the end, shouldn't be stranger to devs. |
Beta Was this translation helpful? Give feedback.
-
|
These issues are only related to the mandatory use of comment-style UID, most of them do not apply to an optional comment-style UID. |
Beta Was this translation helpful? Give feedback.
-
Don't discard that right away! Will explain later.
Have to disagree with that. I prefer a way more a comment on my files with the "magic" number than thousands of uid files cluttering my repository. The only way to know what most people agree on would be some sort of poll.
This is an interesting idea, it could checksum files that are not already annotated an centralizad file (the monolitic approach) and check if it matches with missing files. It also would checksum files modified in the editor, and store on the centralized file. The only way it wouldn't work was if the file was externally moved and changed at the same time. Edit: Internally (in .godot folder) it could store the time each file was created, and when opening Godot only checksum the files with changed date, so it wouldn't checksum everything everytime. |
Beta Was this translation helpful? Give feedback.
-
|
Another alternative that i think would be much better than breathing hopium that Godot manages to track and update dependencies correctly would be to let the user fix the dependencies manually via a pop-up. This would give maximum control and transparency that the current and likely most other solution(s) lack. |
Beta Was this translation helpful? Give feedback.
-
Did the errors prevent you from opening the scene? There were a few bugs that prevented opening some scenes, but they should be fixed now. If you still have a scene you can't open, open a bug report. If you get errors, but the scene can still be opened, that's likely another issue. |
Beta Was this translation helpful? Give feedback.
-
The scene could be opened and the game ran just fine, it's just that Godot spammed "invalid UID, falling back to path" messages (and i don't remember if they were warnings or (soft) errors), which i assume means that something in the game had broken UID references yet Godot never prompted me to fix them |
Beta Was this translation helpful? Give feedback.
-
|
In case of such errors you should open the scene and save it again. The dialog I mentioned only appears if the dependencies can't be found at all and there is a risk of data loss. |
Beta Was this translation helpful? Give feedback.
-
|
I think the ability to replace files in the dialog could be refined a bit more. Though, checking for it in real time is overkill. So we can provide some kind of operation for dependency validation, which can be done either when a scene is opened or manually. Then, instead of replacing a single file, if we make the replacements search within a given folder as "searching for an unknown file", we can replace multiple paths at once. This is a fairly common practice in video editor and DCC software. It might be useful to have a subfolder search as an option, but since it is possible to misplace files with the same name, it may not be necessary for the moment. |
Beta Was this translation helpful? Give feedback.
-
Personally, i think the dialogue should appear whenever a UID is broken, not as a last resort emergency recovery tool. It's the only way to keep the project in a healthy state without manually ripping guts of scene files |
Beta Was this translation helpful? Give feedback.
-
|
Without trying to argue for one solution in particular, I just want to add this to put the downsides of the current solution in perspective: Millions of Unity users have been dealing with basically the same system (in the form of .meta files) for well over a decade and it's not been a big deal. Most game devs nowadays know how to handle metadata files, know to commit them, move them along the source file, etc. Lots of tooling has been made around them (like git pre-commit checks to ensure the user doesn't forget a meta file), which can be adapted to work for Godot. I have a feeling we're making a bit of a mountain over a molehill here.
|
Beta Was this translation helpful? Give feedback.
-
|
Ok I Will concede that. Nevertheless my main point is that the burden is not that big or problematic, as evidenced by the most used engine in the world. |
Beta Was this translation helpful? Give feedback.
-
|
I don't claim it is. I don't think Godot is trying to come up with an unprecedentedly good solution, but to solve a pressing issue in a simple and robust enough way. I'm not saying it's perfect, I'm saying it's good enough. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Your argument is that most devs know how to deal with this problem, so it's no longer a problem, it's a solution. |
Beta Was this translation helpful? Give feedback.
-
|
meta files and missing script issues have plagued Unity users for a decade and a half or more. It is a big deal, just we've gotten used to the constant pain and the rare week in a project where something doesn't break and a coder has to dig through yaml and investigate. |
Beta Was this translation helpful? Give feedback.
-
|
Firstly, I believe everyone agrees that UID is useful, and there is no need to discuss this further. Like UID fallback to path, I think we can use similar way to handle different types of UID. for example, GDScript, by handling All solutions are have cost, but we should try our best to avoid leaving burden on users. I wound prefer to add a simple comment to represent the UID of GDScript. By using comment style UID, just ignore an UID line in script, it not change anything (for users). By the way, like python, it usually have comments like |
Beta Was this translation helpful? Give feedback.
-
I can imagine a large number of users being scared by generating ”.uid“ files when upgrading their projects from 4.3 to 4.4, even though a large part of them do not use GitHub, Discord or other way to providing feedback, and have to silently adapted to this new change or rolled back to 4.3. The implementation of ".uid" files is quite radical, bring more manage burden to users (of course, it solve some dependency broken issues), bring compatibility issue, and leave them to users to handle. Anyway, it has hurriedly entered the beta phase, features are frozen. We can only adapt to this Irreversible change. |
Beta Was this translation helpful? Give feedback.
-
|
Is there even any downside to supporting optional UID comments? People who find them intrusive can just stick to UID files, so there's no downside for them at all. It sound like a win-win to me. I guess it's more work for the developers of the engine, but is it really that bad? Godot could just generate UID files for all scripts that don't have a UID comment. Maybe the script editor could have a menu item for switching between UID files and comments for convenience, but I could live without that too. I can just code myself an editor plugin to do that. I know UID comments won't be included to 4.4 because of the feature freeze, and that's fine by me. I'm skipping 4.4 myself because I don't think it's worth the trouble, but I'm looking forward to this or something else similar getting added to 4.5. |
Beta Was this translation helpful? Give feedback.
-
|
UID comments have to be disabled for .uid files to generate. You can support .uid files in projects with UID comments enabled (as read-only), but the other way around is not possible. So if you make an addon with UID comments, people that have them disabled won't be able to read script UIDs (which is only a problem if you refer by UID in your addon). It's unlikely to cause a problem, but not impossible. |
Beta Was this translation helpful? Give feedback.
-
Why? (i know how this sounds but i really just flat-out don't understand) |
Beta Was this translation helpful? Give feedback.
-
In the solution I mentioned( use fallback logic to handle different types of UID), this is not a question, both ".uid file" and "UID comment in script" can be recognized, instead, it brings a matter of priority. Of course, it also increases the workload of engine developers. |
Beta Was this translation helpful? Give feedback.
-
|
And add UID to all resources will bring a compatibility issue to plugins, please refer to this proposal. |
Beta Was this translation helpful? Give feedback.
-
|
This is actually a very worthwhile topic for discussion - most Node developers don’t include node_modules in their version control systems, but this is quite common in Godot (include I have no strong opinions about UID itself. I just hope that my plugin system can continue to function properly, or better yet, that the official team could provide some sort of package management system. |
Beta Was this translation helpful? Give feedback.
-
|
Without considering this flaw in the current implementation, on the long run uids would make it easier to refactor plugins, moving files around to reorganize them, without worrying about breaking dependencies in projects using them (or at least making them easier to fix). |
Beta Was this translation helpful? Give feedback.
-
|
I have a proposal, although I'm not qualified to implement it. But I hope Godot devs discuss these ideas if they think they're viable. The drawbacks of the current implementation:
I think this approach focuses only on devs using another IDE, the very well-known ones, and disregards other workflows. Storing the UIDs in the scripts as text has drawbacks too, but I think they are easier to solve, the results would be more robust and can meet the demands of more users. These are the drawbacks of embedded UIDs and the solutions I propose:
The implementation I propose is an hybrid of the UID files and embedded UIDs. I don't know much about how the Godot editor works internally, so I might miss something. Specially, the "Godot plugins having to parse the file" issue, I don't understand fully. I guess Godot builds a dictionary of files and UIDs when it opens a project. That dictionary could be available to Godot plugins so they don't have to open UID files or parse scripts. |
Beta Was this translation helpful? Give feedback.
-
|
i think a temp fix for now is to include the filename and the hash like "uid://some_file-fkjlqx8er2sg" , also regenerate uid after every rename |
Beta Was this translation helpful? Give feedback.
-
|
It seems like most against uid's focus on the upside of being able to move files outside the editor not being useful to them. Now it would be great if one of the engine devs could confirm this, but I thought that was only one of the benefits to the changes? I was under the impression that the full scope of the change that this improves was:
Some of these are crucial in bigger games. I definitely agree that it would be nice if there was some solution that didn't require extra files, but it also feels to me like a tradeoff I would willingly make/have been used to anyways. As well as some of the drawbacks being fixable with different methods eventually. (Like the text editor automatically displaying the path next to uid's) I don't have a clue if it would be viable to allow uid's to be disabled if its planned to be improved/extended upon in future versions. |
Beta Was this translation helpful? Give feedback.
-
Multiplayer spawner uses UIDs now. You need to re-assign the scenes (the functionality was added in recent dev release) and they will be stored as UIDs instead of paths (still showing paths in the inspector). |
Beta Was this translation helpful? Give feedback.
-
|
UID is a good think, it solve many troubles and new users(after 4.0) can't perceive the benefits it brings. |
Beta Was this translation helpful? Give feedback.
-
|
I just want to give a pretty big disclaimer here that I am fairly new to Godot. I've been working with software for a long while now, but Godot is a relatively new tool to me. I have done my best to understand Godot's concepts and the thinking behind them, but if I get something just plain wrong, please feel free to correct me. If I am straight up not absorbing some fundamental concept and am getting this whole thing wrong, then whoops! At least maybe I'll learn something new, then. 😊 Is perhaps the issue here a result of that code is being treated as just another resource? As far as I know, we don't have any kind of built-in package or namespace system to organize scripts. I actually think UID files make perfect sense for traditional resources like scenes, textures, audio, etc. But something about using the same approach for code files feels like a band-aid for deeper problems with project organization.
As I mentioned, all things said, I'm pretty new to Godot. But from what I can gather, could it be perhaps that the real friction here is not that UIDs exist, but that code is still being forced to behave like an asset, instead of adopting the packaging/namespace semantics we see in typical programming environments? Ìf so, then UIDs (when used for scripts) are addressing the symptom (broken references after moves) rather than the root cause (lack of a proper code module system). As far as I can tell, Godot doesn't even have a way to package libraries for downstream use, people are just chucking 3rd-party code wholesale into their project folders. Maybe adding deeper language or project-organization features might help solve the problem at its source, rather than relying on sidecar files to keep code references stable. Edit: GDScript that is a resource has its benefits. But having the ability to perhaps use GDScript in a non-resource context with proper encapsulation (modules, and so on), could strip away limitations that are being run into that result in these usability issues. This could even open the door to 3rd party libraries being properly packaged (and potentially even a proper package registry. Give me |
Beta Was this translation helpful? Give feedback.
-
|
I think they're just two different issues, a module system would likely have a different and more type-centric method of imports and exports that likely has some kind of root module "entry point" and then semantically determining where the dependencies of it are, to use some terms loosely. Or some type of map in the project file of included script files, similar to a C# project file. But either way it's likely to diverge from the way that assets are tracked. |
Beta Was this translation helpful? Give feedback.
-
|
It's really no stress at all. I can tell you are very engaged and interested in seeing a good solution to this problem. :) |
Beta Was this translation helpful? Give feedback.
-
|
I very much prefer this approach proposed by @adalinesimonian . Godot pre-UIDs for source files has a very clean and elegant approach to project organization. This is one of the main reasons why I immediately found joy in working with Godot, after decades of work in more fault tolerant (but also more clunky) engines. In this particular case, and given prior experience with other engines, I worry that the introduction of UIDs as standalone files introduces more complexity (and therefore more surface area for user error) than it potentially fixes. In the short-term, I believe dev time would be better spent on in-engine tooling, documentation, and educating users on this particular problem space. Long-term, packages/namespaces all the way IMHO. |
Beta Was this translation helpful? Give feedback.
-
|
I come from a corporate software world so the additional files were perplexing at first. I tried excluding them from source and fought them before reading about what they were. 😓 I much rather not have to deal with additional files and also prefer the approach proposed by @adalinesimonian. |
Beta Was this translation helpful? Give feedback.
-
This is definitely the case for me. I don't have an issue with metadata files for assets, I don't understand how any of the purported benefits of UIDs apply to code files. I would never load another script by UID in GDScript because that is unreadable nonsense, and the option is irrelevant in C# which is what I primarily use anyway. I have absolutely no interest in having to keep UID files consistent with code project structure as code files are renamed or moved around, or in having to worry about how Godot might misbehave if I don't. And I'd really prefer not to have them cluttering my file system. The cases where Godot should care about script references, i.e. being attached to nodes and resources, are generally already covered by class_name/GlobalClass. Right? So why would we need another identifier on top of this, in the first place? Why bring in this whole maligned UID system for scripts instead of simply extending this to the case of attaching a script to a node without wanting it to appear in the global class list? It's frustrating. If the Godot team could not communicate this change to the people who actually use Godot in a way that convinced those people it was beneficial, then the change shouldn't have shipped. Please, either explain much more clearly why such a fundamental change is needed, or else revise and refine the change until it's no longer this massive source of controversy. |
Beta Was this translation helpful? Give feedback.
-
|
I really hope this feature can be reconsidered. Totally agree that refactoring issues should be addressed, but current implementation feels so far from optimal.
In summary, the pros and cons of uid files feels very underdiscussed, there are absolutely no necessary to release the feature in its current state. |
Beta Was this translation helpful? Give feedback.
-
Among developers, not wide spread users, I guess. Many people only started paying attention to this feature after that blog was published (At least from what I saw on Reddit, many people were quite shocked by the introduction of UID). Discussions among a small group of people may not represent the views of the majority. |
Beta Was this translation helpful? Give feedback.
-
|
Well that's what this discussion is for, for those who didn't get involved in the development process But calling this under discussed seems like it implies that this idea is half-baked or not based in a long and involved development process, with many pros and cons being voiced, which isn't true So for the part of discussion with a wider audience, that's this, but before it was implemented it was discussed extensively from a technical side, and from a practical side Having users test features before they're added is hard, most users aren't able to build the engine on their own, so other than people looking at the feature it's hard to get people to actually try this That's my point, to clarify |
Beta Was this translation helpful? Give feedback.
-
|
The thing is that people are opposed not just to the implementation of this feature (and implementations, indeed, are majorly tested by contributors and maybe a few people who really need them), but to the idea itself. The idea could've (should've) been publicized way prior to deciding on any one solution. It's okay for the maintainers to make mistakes. The situation could've went perfectly smooth if everyone had just acknowledged that this feature wasn't anticipated to be something controversial. Instead, at least the way i see it, we have a double-down and a "we know what you need better than you" approach. The feature was frozen a day after it was announced instead of being (even if temporarily) rolled back, despite the full knowledge that this is (quote) "a bit of a hot topic". This all might have been a coincidence, but from the outside this feels plain hostile, feels like just a way for someone in charge to get their own preferred solution into the engine and then maintain status quo. I know this probably sounds like a fat-fetched conspiracy theory. And frankly, it doesn't look like i can do much beyond voicing opinions (of which i'm sure you've heard many already), as all the proposals have critical flaws and thus are unlikely to get implemented (neither should've |
Beta Was this translation helpful? Give feedback.
-
|
Follow-up: As Clay John clarified in the last core meeting, there apparently already was an attempt to implement this feature before (which i missed - my bad), but it likewise received pushback and got scrapped. The feedback to .uid files by most users was "i used to hate it but then stopped caring" and so it was decided that this solution is good enough. The article/announcement was more of a FAQ than a "true" announcement, and came more as a preparation for the beta rather. No conspiracy! We still have to hope that alternatives will be implemented too, even if for 4.5, but at least i can turn off panic mode 😅 |
Beta Was this translation helpful? Give feedback.
-
|
Maybe it's my OCD, but I still hate .UID files. I do care that my project folders are now littered with files, that I have to move manually(!?) if I want to replicate functionality across projects. This is the only change since I started using Godot in 3.4 that has soured my outlook on it. I am also afraid, since the change was to help "large projects" and bigger teams, and I'm just a hobby gamedev doing very small projects, that Godot soon will not be for me anymore... (And that is fine, I'd like to see Godot have even more success!) I'm sorry I can offer no solutions. I can only partly understand the problem (which I encountered only 1-2 times in as many years) is hard. I'd rather have UID comments than files, I'd rather have slower project opening than UID files. I'd rather have any option than being forced into this. PS: It grates on me a bit the "Unity does it this way", because in my mind Godot was so much better. |
Beta Was this translation helpful? Give feedback.
-
|
Would somebody be able to say has there been any update on this topic (UIDs in Godot 4.4)? By update I mean will there be mayby something like #11571 or other solution. Hidden TextIf it comes I can always add .UID files to .gitignore right ?Edit: If there wasn't solution found till time for 4.4 could .UID files be postponed till next release(4.5, 4.6, etc.)? |
Beta Was this translation helpful? Give feedback.
-
|
It's too late for changes, the stable will (most likely) come on Monday. |
Beta Was this translation helpful? Give feedback.
-
|
I wonder what "evaluate that feedback" from what akien-mga wrote means, still I feel like this should be solved before stable. |
Beta Was this translation helpful? Give feedback.
-
As the blog post says, you shouldn't add |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
UIDs in prev godot version were less stable for me than filepaths since UIDs would often self change when reimporting asset. Also I don't move files unless there is rl need to. |
Beta Was this translation helpful? Give feedback.
-
|
As a user, I see new |
Beta Was this translation helpful? Give feedback.
-
|
So if I am not mistaken with release of 4.4 today best way for now to make sure that UID files won't clutter git repo is to just add them to If somebody also wants to avoid commiting |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
Yes. |
Beta Was this translation helpful? Give feedback.
-
|
Paths were always more stable for me than UIDs so if it fallbacks to paths it is fine in my opinion |
Beta Was this translation helpful? Give feedback.
-
|
(IDK why github doesn't auto update responses and write smthg and see there was edit and etc) |
Beta Was this translation helpful? Give feedback.
-
|
Anyway I will hope that being ablt to disable .UID will become feature in next update |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure how I missed this thread when searching the web directory for "UID" before making my discussion on ways they may be re parented in cases where the .uid files are orphaned. I'm thinking it was as simple as the search being strict enough to see "UID" and "UIDs" as entirely different terms. Anyway, I'll just leave the simple version here. I think there should be some kind of popup much like the existing one for missing resource references to prompt the user to re parent .uid files before they forget what they did and where they might be, but im also not all that sure that orphaned .uid files will turn out to be an issue for users depending on how often they end up moving and editing files outside of the editor. |
Beta Was this translation helpful? Give feedback.
-
|
Maybe we can add a voting system in godot editor for collecting feedback from users directly, instead of partial users only. |
Beta Was this translation helpful? Give feedback.
-
|
If maintainers didn't care about feedback, they wouldn't have made this thread in the first place. UIDs were well under way when this thread was made, and I don't think the purpose was to see if it got reverted before 4.4, but rather to gauge how to proceed into the future. Maintainers merge dozens of PRs every day and they have a set workflow, we cannot expect them to adapt to everyone's individual needs, nor are they responsible for answering every single comment. If you want specific features you need to participate in the relevant threads in a timely manner. Maintainers are always welcoming to feedback and proposals, especially if they have strong support. Rolling back on a feature days before release because of some minor complaints is not the way to go anyway. The proposal you link as the most supported feedback (#11574) involves a lot of work, rewriting and even a change of paradigm on how scripts are handled internally. It would be interesting to consider the implications of such a proposal but it's not going to happen overnight. There needs to be people setting the specifications, solving possible incompatibilities and gauging overall interest in something of that scale. It will take time. For the record, I like .uid files. I rather have that than my references breaking every time I move a file. It needs work but it's a step in the right direction. And I'm glad everyone can participate and give feedback. |
Beta Was this translation helpful? Give feedback.
-
|
I wrote the proposal being mentioned, #11574 (comment), which currently is the most upvoted reply to this discussion topic. I want to share my thoughts. I don't think that Godot's maintainers are uninterested in feedback, neither do I think that they are intentionally unwilling to engage with the community. Godot started out as a fairly small project. While it is now significantly larger than it was in its beginning stages, I think it is fair to say that its growth in use in the ecosystem has largely outpaced the growth of the contributors to the project. This is normal and happens to many projects that get very big, especially if it happens fast. This is especially true for projects that require a very different level of technical skill and ability to contribute to a tool rather than use it. I am willing to wager that most users of Godot don't have the same comfortability with low-level software engineering as the contributors who have and continue to build this project. This is all to say several things:
However, it is also true that many users, @scott-lin included, in this discussion, have felt that their input in this issue was asked for too late into the cycle, that maintainers have not had the level of response to issues raised as expected, and several other similar concerns. It would be an error to disregard or explain away their feedback, just as it would be to disregard or explain away clear signals that the maintainers are interested in community feedback and engagement. If there is a problem here, it is simply that Godot is now a project of the size that demands resources dedicated to community engagement beyond the scale it has now. Smaller projects don't encounter this need as often. Neither do projects where the users are broadly in the same circles as the maintainers — take for example, a C library, used chiefly by C developers. However, Godot is neither. It is much more like Blender, used at scale and mostly by users that are not low-level system developers. Successful projects at scale need resources dedicated to actively engaging the community on multiple, layered channels, each tailored to the nature of their user base. For example, taking a look at both Blender and Unity for reference:
It would be patently false to say that Godot isn't doing any outreach, taking efforts to be transparent, or so on. We've got the blog, we've got the forums, there's this very discussion happening. My point is more that as this project continues to pick up steam and grow, that it's important to critically evaluate and dedicate effort to being increasingly proactive about feedback, rather than relying on the few most vocal users or most technically adept to push the conversation forward. More formalized, multi-channel approaches to community engagement would be a plus for Godot. Just like with my proposal, I recognize that these things take time and effort. If you take a closer look at my proposal, you'll note that I recognize the deep and large scale of the refactor that would be necessary, and suggest some smaller, more easily-implementable changes that could be useful and alleviate pain points until those deeper issues could be addressed in full more closely. None of this is trivial or easy, especially for a volunteer-driven, open-source project like Godot. I appreciate deeply the labor and passion that the maintainers, contributors, and volunteers already invest into this project. And I recognize that resource issues can also often come down to funding. However, as the project moves forward and continues to grow in both ambition and user base, addressing these communication and engagement structures will become increasingly essential. No one gets anything perfect, makes everyone happy — it's impossible. But it is also not true that Godot is a scrappy little open source project — at least not any longer. I believe the current situation around UID changes serves as a valuable learning opportunity. If we take what we've learned by seeing how this community reaction has played out and is continuing to play out, we can proactively prevent similar scenarios in the future, even if not all of them. And that would be a boon for Godot. |
Beta Was this translation helpful? Give feedback.
-
|
Replies for @Ignawesome:
Agreed, but only at that point in time. There needs to be continued involvement in the feedback process or else the initial effort is rendered not valuable.
That is part of the problem, and I hope they learn from it. If the popular support blows in different direction, I would hope the contributors listen and have the willingness to back up and change direction if need be. This was not the case for this feedback discussion.
This is a general comment, so let me focus it back on this particular discussion. The whole point of this discussion thread was to centralize feedback on the UID changes because they were dispersed among many different issues. So no, I don't buy that we needed to participate in any other particular threads regarding UIDs; they asked us to participate here regarding this specific feature. In akien-mga's original post of this discussion, they even said "We'll redirect discussions from other issues/PRs to this discussion, and evaluate that feedback while finalizing the 4.4 release." This tells us exactly the opposite of participating in other threads on this subject. As for timeliness, the most support piece of feedback was given 1 day after this discussion opened. I'll reiterate that not a single contributor or collaborator responded from what I inspected of the repliers.
I'm in agreement again that it will take time and work. However, these are not excuses for ignoring the feedback, nor being willing to halt the current solution and rethink. No one has asked that the most supported solution happen overnight. I may be coming off as harsh here, but my intention is to only promote learning and accountability for the future by being factual about what has occurred on this specific discussion. What is done is done; I know the UID changes are now in and not backing out. However, I would like this kind of feedback process to never happen in the future. @adalinesimonian Thank you for sharing your thoughtful perspective on growing projects and the challenges to make them successful. |
Beta Was this translation helpful? Give feedback.
-
The point is not UID is worth or not, UID is definitely a good thing. Instead, we against ".uid" files. This way to handle UID for scripts/shader is too crude, many new comments in #97352 after it was merged and this discussion can be so long are proofs of this. |
Beta Was this translation helpful? Give feedback.
-
I meant that having the UID as a line in the script isn't as bad as it's painted, and I think it would be the best solution. I may have explained it poorly. |
Beta Was this translation helpful? Give feedback.
-
|
How about this: If I give a class name to an script, Godot will reference it by class name with path as fallback, and it will have no uid. |
Beta Was this translation helpful? Give feedback.
-
I always add names to my scripts, never had any trouble with them and i don't see how naming them can be "a very troublesome task". You have a |
Beta Was this translation helpful? Give feedback.
-
|
If |
Beta Was this translation helpful? Give feedback.
-
|
Every global script is loaded when project starts. If they have preloads, they will be loaded together with the script and kept in memory. If you give |
Beta Was this translation helpful? Give feedback.
-
Well, if anything the pros vastly outweigh the cons for me. Besides, that sounds like something that could be fixed |
Beta Was this translation helpful? Give feedback.
-
|
i am not sure what information a voting system would give. going through the first 50 comments, i would say 3 are pro the uid system, around 35 are against the current implementation, 12 are kind of neutral. of course negative feedback tends to be louder than the positive, but 1:10 is a clear tendency. there is a certain untransparency to the decision beeing made but i dont know how much a user can expect from an open source community without contributing solutions. i myself will still use 4.4 even though i liked the simplicity of the old path system more. |
Beta Was this translation helpful? Give feedback.
-
Resource UIDs and .import files in Godot: Odds and Dead EndsI previously raised concerns about UIDs in their current implementation, which unfortunately have materialized exactly as feared. While UIDs represent an important improvement to Godot overall, their current implementation creates several technical challenges and workflow issues that need addressing. .uid and .import files, as they exist now, present both a cognitive and accessibility challenge when working with Godot. This proposal aims to be constructive by identifying the core problems and offering potential solutions. Current Problems1. Evil Twin Conflicts (ETCs)Problem: ETCs occur when resources (but not their ancillary .uid or .import meta files) are committed to version control and shared between different editor instances. For example, when an artist exports a new sheet of sprites and commits them without allowing the Godot editor to scan and generate UIDs and .import files first. (or a developer unpacks a set of source files, etc.) Team members unknowingly generate different UIDs for the same files, leading to merge conflicts that can destroy subsequent work or break dependencies. New files are particularly likely to be instantly taken and "used" for something, so breakage due to ETCs happens on a regular basis. Mitigation: 90% of these conflicts could be avoided by implementing deterministic UID generation based on file content or file path. 2. Invisible Critical FilesProblem: .uid files are invisible to users but crucial for project integrity. Some resources require .uid files while others don't, and some systems (like .tscn) appear to handle UIDs differently. Resources with similar name "stems" can exist side by side, putting the onus on the user which of these can be moved alone, and which of those will break the project in a heartbeat if a .uid file is moved just 1 editor tick later. Mitigation: Either make .uid files visible in the file system tab or implement reconciliation strategies when files are moved. Alternatively, combine UIDs with their resources. 3. Evil Clone ConflictsProblem: When a file is moved without its UID, Godot destroys the orphaned UID and creates an entirely different one in the new location. This is particularly problematic for teams that organize files by type or use external tools to move files. The issue is also triggered when switching branches or using certain version control operations while the Godot editor is running, often leaving projects in unpredictable states. Mitigation: Remove the requirement for .uid files to be in the same location as their resources. This is challenging but solvable (a solution is discussed below). 4. Poor Human ReadabilityProblem: UIDs are not human-readable, making it difficult to resolve conflicts or identify missing resources during VCS merges ("What was uid://zuodsghup4ik?"). Mitigation: Always prioritize paths over UIDs in the interface and GDScript, as paths better represent user intent. Use UIDs only to resolve unknown paths at export time, replacing them with final paths. 5. Procedural Generation ObstaclesProblem: Procedurally loading resources (e.g., levels 1-37 for a puzzle game) is more difficult with UIDs than with path-based approaches. "Paths" are essentially URIs, so they are already uniform and identifying), their only problem is they aren't immutable at project edit time. Mitigation: Prefer paths for resource access, using UIDs only to resolve unknown or modified paths at edit/build time. 6. Untyped Resource FilesProblem: The combination of untyped .tres files and untyped .uid files creates confusion when multiple files share the same base name but have different extensions. Your teammate finds a warrior.tscn, warrior.glb, warrior.import, warrior.gd, warrior.png, warrior.tres, warrior.json and warrior.uid in a folder they wish to reorganize. It's up to them to know which pairs belong together. Together with the effects no.2, they may not even know some of these existed / were created. Mitigation: Use .import files to specify UIDs, and ensure all resources, from script to text to scene, have .import files (not .uid files). The import filename should in all cases include the resource's extension for clarity. 7. Premature Resource ManagementProblem: Godot often makes changes (destroying/recreating .uid files) before fully evaluating the state of the entire project. Mitigation: Build a complete list of observed filesystem changes before acting on them. Never act in multiple passes. Proposed Solution: Per-Project Centralized Resource DatabasePerhaps we should not chase after layers upon layers of mitigations, though. Instead of multiple ancillary files (.uid, .import, etc.), I propose to banish any non-user generated file into a single database (using either a memory-mapped file or SQLite, the latter preferable as a reliable and performant solution where recovery and repair functionality also exists, just in case). For version control, it can be dumped into a single text file. Primary Resource Table
This database would track every file Godot has ever seen in this respective project, with an option for users to perform garbage collection via Project Settings. When files are moved, Godot can query this database to determine if a file with the same content, name, or type was previously known, and reconcile dependencies and restore import settings accordingly. This process could be configurable, allowing automatic reconciliation based on matching criteria (e.g., same name, hash, and type but different path). A editor or project setting could look like "4 matches: Auto", "3 matches: Auto", "2 Matches: Manual", "1 Match: Never" (defaults to Manual) These database operations would be efficient, and the content hashing would only need to be performed once per file move (or optionally, every change). The history maintained in the database would also help with accidental deletions or external tool operations, allowing automatic restoration of settings when files reappear. It is important that all "known" columns for each file are regularly updated, but they don't need to be updated all the time (but likely they could - I'm working on a PoC for an Engine project that does exactly this and it looks promising so far) Reconciliation through the "history" of this table will also remove most of the impact temporary deletions have, or partial moves of more complex assets (e.g. .obj files and their accompanying .mtl and textures) Layered, Reversible Dependency Reconciliation (optional, later!)To address limitations with the current "fix dependencies" dialog, I propose a secondary alias table:
This table would:
Users could "apply" the alias table (making all operations permanent and clearing the table) or "garbage collect" the primary table (removing entries no longer in the project) through Project Settings. TLDR;.uid files are 💯 percent a dead end and will keep adding technological baggage and painful corner cases to engine maintainers and users alike. The current UID system in Godot, while an improvement in some respects, represents a technologically obsolete bad practice, that causes significant issues for teams and complex projects. The proposed centralized database approach would not only solve the immediate problems but provide a foundation for more robust resource management in the future. I welcome feedback and discussion on these ideas. |
Beta Was this translation helpful? Give feedback.
-
That's exactly why i mentioned the "fallback" option!
Sorry, can you clarify? In what way do IDEs like VS Code and JB Rider process |
Beta Was this translation helpful? Give feedback.
-
They can hide ".uid" files in their file system dock, and rename, move, or delete ".uid" files when source files are changed in their file system dock.
What I means is that, if we allow external tools to handle these tasks, we can just say, "hey, let it handled by xxx plugin/tool, we don't need to do anything". |
Beta Was this translation helpful? Give feedback.
-
|
Could we maybe let people have options? |
Beta Was this translation helpful? Give feedback.
-
That would certainly be the most versatile solution, but likely also the most time-and-effort-consuming |
Beta Was this translation helpful? Give feedback.
-
Oh! That definitely wasn't my intention, but i can see the danger here, thanks for pointing this out |
Beta Was this translation helpful? Give feedback.
-
|
Question: Would somebody be able to say were there any new issues/PRs/discussions regarding UIDs that should be checked ? Like is there any solution to a problem being worked or discussed that might be or was merged ? |
Beta Was this translation helpful? Give feedback.
-
|
Now I wonder, could any of ways to not have .UID files make it into 4.5 (the next version at the point of me writing this) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
I did seen this... Still that isn't only UID problem solution, I remember there also being centralized db and uid comments for gdscript files... |
Beta Was this translation helpful? Give feedback.
-
|
Hopefully something is tracking how many less-technical users are helped by UID files. I'd be surprised if it solves people dislodging files outside the editor, but it would be convincing if there were data. |
Beta Was this translation helpful? Give feedback.
-
|
The situation around this issue becoming slightly frustrating. Went from "hey, community, share you feedback" to "it's not kind of feedback we wanted, please stop" pretty straight. Two most promising and realistic compromise solutions (uid comments in scripts, option to disable uid files per project) have zero progress. I'm still using 4.3 now in illusory hope that core team will consider one of them. Otherwise don't see options to avoid dealing with uid files in nearest future. Any database related approaches and such are much more long term discussions. |
Beta Was this translation helpful? Give feedback.
-
|
I share my idea of notating the uid within the comments of the code. Translated with DeepL.com (free version) |
Beta Was this translation helpful? Give feedback.
-
|
Can we get a solution/alternative ways to store UIDs instead of UID files before 4.5 launches? |
Beta Was this translation helpful? Give feedback.
-
|
A file name with a path is itself a human readable unique identifier. Adding a non-human readable unique identifier right next to it as a separate file to identify the file is not needed. It solves nothing. It can't solve anything because to generate the UID file Godot needs to know about the file and in that point the developer has already added a reference to the file to the project by using the file name. It is just a duplicate id in a separate file which makes no sense. Another way to look at it is the fact that almost all the software ever created (including for example Godot engine, games made with previous Godot versions and so on) is working just fine without such UID file system. That's the proof that UID files are not needed. Correct way to fix the issue is to get rid of UID files. They are a mistake. |
Beta Was this translation helpful? Give feedback.
-
Aren't there file system events Godot can listen to?
Sounds like it needs improvements then, not the UID system :P
Guess so, i'll personally pass |
Beta Was this translation helpful? Give feedback.
-
Godot can only detect operations in editor. This is the reason why we need UID to keep reference. |
Beta Was this translation helpful? Give feedback.
-
|
What about if godot had relative paths available, like if you have scene.tres and scene.gd in 1 folder and you dupe it it keeps ref to it's local one? Also can we just select do we want auto dependency resolving or by hand? I much more prefer filepaths since they don't require turning my head into database that needs to keep track of all uids. Like can we get ADVANCED mode that for any unresolved dependency shows red box and says Like ability to change autogenerated uid to something like |
Beta Was this translation helpful? Give feedback.
-
Here's an example of a tool that could be used to handle file system events that occurred because of operations outside the Godot editor: https://github.com/SpartanJ/efsw |
Beta Was this translation helpful? Give feedback.
-
|
I found how to use gdscript without UIDs in latest... Example (non-recursive):
extends Node
# Called when the node enters the scene tree for the first time.
func _ready() -> void:
var scripts_dir = "res://scripts/"
for file in DirAccess.get_files_at(scripts_dir):
if file.ends_with(".gd.txt"):
var node = Node.new()
var script = GDScript.new()
script.source_code=FileAccess.get_file_as_string(scripts_dir+file)
script.reload()
node.set_script(script)
add_child(node)
extends Node
func _ready():
print("Hello world with no .UID files!")
You could take that example further by using node groups or node names to decide what scripts to attach where... |
Beta Was this translation helpful? Give feedback.
-
|
Most of the many downsides of UIDs for scripts have already been mentioned elsewhere so I don't have much to add in that regard without repeating them, but I'd like to leave my two cents regarding this. The mandatory addition of UIDs for scripts is in my opinion a big mistake that worsens the experience for many if not most developers, for no tangible benefits. To make things worse, it seems the maintainers are reluctant to even add an option to disable it, despite overwhelming negative feedback from the community regarding the feature. This feature is the only reason why I haven't updated to v4.4 yet. For my current game I'll stay on 4.3 until we're able to officially disable this feature, or if that never happens, maintain a fork if there are important bugfixes missing from future versions. For future games/games in early stage I'd have to move away from Godot altogether -- IMO the project as a whole needs to prioritize stability, onboarding more contributors, improving documentation and bug triaging instead of merging more problematic features to "stable" versions. One last thing I'd like to make clear: None of the proposed "solutions" completely fix the many problems introduced by this feature. They're just attempts at alleviating the symptoms of a harmful feature. But also, nobody wants to fight their tools and deal with workarounds and hacks for an unnecessary feature introduced to a minor version bump on a stable release. For me personally, the only solutions are: either remove the feature, or add an official option to disable it on a per-project basis. It is specifically .uid files for scripts that I find problematic. For assets, not so much. Code and assets are completely different beasts. |
Beta Was this translation helpful? Give feedback.
-
|
I think 4.5 will be another version without this issue solved... |
Beta Was this translation helpful? Give feedback.
-
|
Brrr... Do you feel that? That's the cold response to all the suggestions so far |
Beta Was this translation helpful? Give feedback.
-
|
I found that it might be possible to DISABLE UIDs by setting UIDs one wants to disable to This doesn't fix .UID files problem, but if I am not mistaken this allows to shutdown UIDs... Note I did not test this...So this might be a way for plugin devs to have no UID conflicts when shipping their plugins. |
Beta Was this translation helpful? Give feedback.
-
|
I would much rather plugin makers use exclusively uid paths to allow plugins to be stored anywhere rather than be forced to add the plugin at |
Beta Was this translation helpful? Give feedback.
-
|
I have yet another idea... One that seams good. It might even be as the Also it could be expanded as whole version without UIDs, but that might be a stretch. I am speaking of separate available build since at least for me it is hard to know when to update custom fork to have it as stable version. |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
As we announced in UID changes coming to Godot 4.4, to be able to better handle refactoring of files within projects, both in the editor and externally, we generalized the UID system to all resources, including scenes and scripts.
That has a number of implications which are naturally tradeoffs, and we are aware some of the decisions made are unpopular with some users, notably the addition of separate
.uidfiles for.gd,.gdshader, and a few other file types (custom resources notably).We'd like to centralize user feedback in this discussion, which unlike PR or issue comments, has the advantage of supporting threaded replies. This makes it easier for users to make separate arguments and to discuss them in a focused manner.
Please read the blog post we published, notably the FAQ, which addresses a number of feedback points we already got before announcing this change. Of course you are welcome to bring up some of those FAQ items here too for further discussion.
We'll redirect discussions from other issues/PRs to this discussion, and evaluate that feedback while finalizing the 4.4 release.
Since this is a bit of a "hot" topic, I would like to remind everyone to be constructive and courteous, even if you disagree with points made by other users.
Beta Was this translation helpful? Give feedback.
All reactions