Allow loading custom ProjectSettings instance

[KoBeWi]

This PR allows loading ProjectSettings like a normal resource (even though it's an Object...). It's accomplished using a special constructor that bypasses creating singleton etc.

This fixes an issue introduced by #69338 where renaming project would remove comments from project.godot.
Also needed for #75047, because it has the same problem.

tbh the original issue could've been fixed by a simple return if a singleton already exists. All the stuff in the constructor does not need to run for the project settings to load and save correctly.

[KoBeWi]

This makes the error actually displayed. Previously it did nothing.

[YuriSizov]

tbh the original issue could've been fixed by a simple return if a singleton already exists.

Well, the idea was to never create a singleton in the first place. What you suggest would create at least one, which is still incorrect in the context of the project manager.

Anyway, why not add support for comments to the ConfigFile? We are in no hurry anymore, we can work on a more robust solution.

[dalexeev]

Anyway, why not add support for comments to the ConfigFile? We are in no hurry anymore, we can work on a more robust solution.

I had this idea a long time ago. ConfigFile shouldn't remove the comment at the top of the file, plus we can add methods like get_top_comment() and set_top_comment(). The same can be done for sections and keys, although this is probably overkill. This can be useful not only for the engine, but also for users.

[KoBeWi]

Well, the idea was to never create a singleton in the first place.

Ah, that makes sense.

As for ConfigFile and comments, preserving exact comments is not that simple. get_top_comment() is only a half-solution, because inline comments are also possible (and I use them in my manually-written files).

Also ProjectSettings is not even a ConfigFile. It implements its own reading and writing methods, which just happen to serialize the same strings, because they use Variant API. The original PR mentioned other differences than the comments (which don't seem to exist anymore though).

I think my solution is good. If we want to improve ConfigFile to fix this issue, the ProjectSettings should move to using ConfigFile first.

[KoBeWi]

Not sure what was the intention here, but get_resource_path() can point to invalid directory and _csproj_exists() crash. If the previous code was correct, I could handle it in _csproj_exists() instead.

[raulsntos]

The intention was to get the path to the directory that contains project.godot (which is res://). Maybe we can just use the literal string "res://" here and it would be handled by DirAccess.

The _csproj_exists method is just meant to be FileAccess::exists("res://*.csproj") but FileAccess::exists doesn't support globbing.

[KoBeWi]

get_resource_path() returns the loaded path. With my change, save_custom used to save to a directory different than res:// will look for .csproj inside that directory instead of the load path. Would that be correct? (I think it doesn't affect the editor, as save_custom() is normally always used with the current path)

[raulsntos]

I feel like we always look for the .csproj in the res:// directory so looking in a different directory wouldn't be correct. Are you saying the project.godot file can be in a directory other than res://? Doesn't the editor always assume this file to be in the root project directory?

In which cases is save_custom used to save to a directory different than res://? I see that this method is exposed to scripting, is this the case you are concerned about? If so, I don't think we care about this scenario. This detection is only used to add the "C#" feature tag to be used by the Project Manager, so any usage outside of that doesn't really matter.

[KoBeWi]

I checked how we use save_custom and it's used only for creating new projects and for saving project file for exported project. So I guess my concerns are irrelevant.

[akien-mga]

Thanks!