Godot: Suggestions for Version Controllability

Created on 14 Aug 2018 · 14Comments · Source: godotengine/godot

Similar to how having the md5's in the .import files reduced the ability of godot projects to be version controlled (which is now solved), a few other thing have also been annoying me slightly.

In project.godot, the typed gdscript introduces: _global_script_classes=[]. If you have a project where the levels are in a separate repository, and not always present, then this list changes depending on what levels for the game are present locally.

Proposal: Create an editor_cache.conf file inside the .import folder for information that needs to be cached at project level and isn't associated with an asset.

In the tscn files, there are frequently _sections_unfolded = [ "Margin", "Rect", "Theme" ] lines showing up and changing - because people opened the file to inspect something, and closed it without doing anything.

Proposal: Store this information inside the .import folder. Perhaps the .import/<resource>-<md5>.md5 file can be renamed .import/<resource>-<md5>.conf and contain both the md5's and the _sections_unfolded. This file can contain other information that is useful to cache about a scene/resource, but is either local-only information or autogenerated.

The resourcefile.import file for a .escn file contains:

animation/clip_1/name=""
animation/clip_1/start_frame=0
animation/clip_1/end_frame=0
animation/clip_1/loops=false
animation/clip_2/name=""
animation/clip_2/start_frame=0
animation/clip_2/end_frame=0
animation/clip_2/loops=false
animation/clip_3/name=""
....
snip ~800 lines
...
animation/clip_254/end_frame=0
animation/clip_254/loops=false
animation/clip_255/name=""
animation/clip_255/start_frame=0
animation/clip_255/end_frame=0
animation/clip_255/loops=false
animation/clip_256/name=""
animation/clip_256/start_frame=0
animation/clip_256/end_frame=0
animation/clip_256/loops=false

This information is auto-generated and that is simply cached here (as far as I can tell). It is not an import parameter and thus does not need to be version controlled. It also means all .import files are ~30kb. Fortunately it doesn't change.

Proposal: Put it in the afore proposed <resource>-<md5>.conf file inside the .import directory.

archived discussion enhancement editor gdscript import

Source

sdfgeoff

👍15

Most helpful comment

How necessary is it, really, to store _sections_unfolded? Personally I would prefer it if all items start collapsed if I close and re-open Godot. I would vote to just store the list of open sections in RAM.

aaronfranke on 14 Aug 2018

👍7

All 14 comments

Maybe related to this topic: #6527 and #18283, which are about resource identifiers getting shifted/reordered when adding, removing, or sometimes not even changing a few items in a scene, causing diffs that are way larger than what the change actually was (the two issues are mentionning cases but this happens in general with TSCN format)

Zylann on 14 Aug 2018

aaronfranke on 14 Aug 2018

👍7

The _global_script_classes is on project.godot because it's needed by the exported game (also, as note, it's not really related to typed GDScript). What could be done if it's worth it, is keeping this cached somewhere else while in editor, and bundle them in project.binary on export.

I don't think those things should use the .import folder though, because they're not really related to importing. It would be better to add a generic .godot folder to hold this kind of information (and maybe move the .import to inside the .godot, to keep it all in one place). Other things could be kept in this folder, like the preview thumbnails which are currently kept in the user config folder.

vnen on 15 Aug 2018

👍5

Note that project metadata can already be written to and read from ~/.config/godot/projects/<name>-<hash> (%APPDATA%/Godot/projects/<name>-<hash>), which is where IMO anything project and user specific (like node folding status) should go.

akien-mga on 15 Aug 2018

👍5

@vnen would that .godot folder have the same "deletable" property as .import? As in, "no need to version it and Godot can regenerate it as needed"?

Zylann on 15 Aug 2018

@Zylann yes, it wouldn't be needed in the version control.

And as such, it would be user and project specific anyway, since each user would have their own folder. My issue with writing these things to %APPDATA% is that is quite easy to clutter it with projects that you don't have anymore (especially if you're used to open sample projects from issues). If it's on the project folder, it all goes away when you delete the project.

vnen on 15 Aug 2018

👍2

It's nice because it would basically makes the project self-contained with no need for the editor to find some sort of identifier to match it in %AppData%, so you can rename the project or move it around and the editor doesn't have to keep that in sync.

Zylann on 15 Aug 2018

👍1

How necessary is it, really, to store _sections_unfolded? Personally I would prefer it if all items start collapsed if I close and re-open Godot. I would vote to just store the list of open sections in RAM.

This would work for me, I don't want this to persist across editor sessions or to have editor state saved with the scene files.

As things stand I currently have Editor Settings > Interface > Inspector > Disable Folding checked to achieve these goals but I would prefer an option to default to folded on start up.

KellyThomas on 27 Sep 2018

The point on _sections_unfolded is fixed by e6473421.

akien-mga on 18 Dec 2018

About this .godot folder, this made me think, in Unity the concept of "import" has a larger meaning, where scripts do get imported together with assets under the same Library folder (.import equivalent). In fact, that's what happens too with named classes... a process runs through files and store processed info in a cache. We just don't call it "import" for some reason. In this regard, I wonder how much sense two folders would make for a user.

Zylann on 18 Dec 2018

In the tscn files, there are frequently _sections_unfolded = [ "Margin", "Rect", "Theme" ] lines showing up and changing - because people opened the file to inspect something, and closed it without doing anything.

This should be fixed for the scene tree as of https://github.com/godotengine/godot/commit/c1dcdf6109dbe29549517d683d85b81c0ade8611 :tada:

Calinou on 13 Apr 2019

For the remaining issues, I really like vnen's suggestion of creating a .godot folder which we can move all gitignore-able stuff into, including .import (#23368).

This should be bumped to the 4.0 milestone, it'll be a big change.

aaronfranke on 7 Nov 2019

👍6

Partially related to https://github.com/godotengine/godot/pull/38607

A lot of the points in the OP have been fixed, so might be worth closing this and opening a proposal for more VCS-friendly enhancements.