Replies: 18 comments 75 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.
-
|
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.
-
|
Forcing administrative burden upon users is not a cosmetic complaint. |
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.
-
|
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.
-
Yes, this is a question, maybe use a another class 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.
-
|
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.
-
|
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.
-
|
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.
-
|
How? If can trace file system change correctly and reliably after changing files outside editor, the UID and related design will become redundant. |
Beta Was this translation helpful? Give feedback.
-
|
No, you just assume that users change the files directory or remove files, how about users changing the file name and change file content? There have not any reliable way to compare and distinguish these change. |
Beta Was this translation helpful? Give feedback.
-
|
I appreciate the active discussion about ways we might tackle the UID portion specifically. I think it may perhaps belong in another thread under this discussion, since I started this thread more so to explore mid- to long-term solutions to the underlying issues behind why this proposal has become so controversial, as well as discussions as to why or why not addressing these underlying issues may or may not be feasible and on what timeline, and if engine developers are on board. That way the comments on this thread can stay a bit more uncluttered and on topic. :) |
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 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.
-
This is simply not true, this has been discussed for literally years, see for example: The different options have been discussed extensively in various issues (like that proposal), various issues (issues this change solved), several different PRs, and in various developer chats and discussions, by various teams |
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.
-
|
Is it possible that Godot has outgrown the use of the platform's native file system, and needs to implement its own internal file system, possibly using an SQL database? This approach would require import/export functionality for scripts and assets. It might also require an integrated version control system, which may or may not be compatible with git. I suppose this might have to wait until Godot 5. |
Beta Was this translation helpful? Give feedback.
-
|
I may be mistaken but even big engines like Unreal use similar file-based resource management, so i doubt that we "hit the limit" |
Beta Was this translation helpful? Give feedback.
-
|
I am constructing scenes that include tens of thousands of files. Unfortunately, until the scenes are complete with local storage, I have to import these files - over a million files. My PC, or Godot, cannot seem to even handle ~150k files, so I have to do it in batches. Am I now going to have to halve my batch size again because there will now be THREE files for every single file? I am forced to have an .import file in cases that I do not want one, now I will be forced to have another? I have never had a problem with moving files, this is an imposition with absolutely no upsides for me personally. Will this increase the size of a fully compiled/exported project? Can anyone tell me why this can't be an option? |
Beta Was this translation helpful? Give feedback.
-
|
For files with |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, that's at least less worrying |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for providing this example. I previously considered working on optimizing Godot's file performance, but it didn't receive much attention, making me feel it was a non-critical need. You've shown me that this is indeed a practical requirement. If possible, could you open an issue or provide an MRP in the main Godot repository? |
Beta Was this translation helpful? Give feedback.
-
Scenes don't have .import nor .uid. The UID is stored inside the file, because it's custom format and allows it. |
Beta Was this translation helpful? Give feedback.
-
Yeah that's a good clarification |
Beta Was this translation helpful? Give feedback.
-
|
We have multiple developers, and UIDs have never been very stable across multiple environments. Godot will occasionally arbitrarily change a UID on a scene or import. (Yes, we've followed the best practices around imports and such that we can find documented). I have a couple questions if anyone knows the answers. When Godot arbitrary changes a UID of a code file:
|
Beta Was this translation helpful? Give feedback.
-
|
About first one, i think it might be possible. At least looks like this is source of problem described in |
Beta Was this translation helpful? Give feedback.
-
|
Seems similar to what we've run into. Unfortunately, I haven't been able to isolate the specific situation because as soon as I try to reduce to an MRP, I can no longer reproduce the issue. Specifically here, we haven't used a |
Beta Was this translation helpful? Give feedback.
-
|
Editor tracks dependencies by both UID and path, so scenes/Resources won't break if UID change but the path stays the same. |
Beta Was this translation helpful? Give feedback.
and others
-
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