Godot: add a way to utilize single properties from the engine config file, on exported games

[ghost]

Godot version:
3.0
OS/device including version:
win10, 64bitz
Issue description:
using OS.window_fullscreen = true in gdscript (after you run the game, will cause screen tearing for a second while it enables the fullscreen). this also means, you must do:

if OS.window_fullscreen: 
    yield(get_tree(), "screen_resized")
````
before adding nodes to the scene, or their control layouts won't be updated correctly


if you set project.godot, this is not an issue

[display]
window/size/fullscreen=true
```

except 1 problem. you cannot have just that configuration inside project.godot on exported games. you need to have your entire project.godot file. which has application, autoload, editor, editor_plugins. input, locale, and rendering. i don't know if other players should have access to these settings

it would be nice if we could have a file that modifies the game configuration settings just like how project.godot does, before it hits gdscript (so it doesn't causes screen tearing when running OS.window_fullscreen = true). also allows for a much smoother UX experience (when launching the game)

[Phoenix1747]

using OS.window_fullscreen = true in gdscript (after you run the game, will cause screen tearing for a second while it enables the fullscreen). this also means, you must do:

if OS.window_fullscreen:
yield(get_tree(), "screen_resized")

before adding nodes to the scene, or their control layouts won't be updated correctly

Not experiencing this issue with a debug build on Linux. Setting OS.window_fullscreen = true just works for me. You should try upgrading to 3.0.2, though, maybe that helps.

[ghost]

interesting. thanks for checking. might be windows issue only then. on windows, using OS.window_fullscreen=true in gdscript, the game will load up to whatever setting is in project.godot, then do a screen tear, and go into fullscreen. it would be nice to have a config file (similar to how project.godot gets ran on exported games). but not requiring all the different [name] categories. or maybe, just overwrite the properties in the project.godot if it's an exported game. not sure just brainstorming

[Phoenix1747]

Oh, you mean that the bootsplash already starts in fullscreen. Ok then I have the same "issue" (it's not really), of course setting OS.window_fullscreen=true in any function of your game will only load when the game has already started. But why do you mind having the bootsplash windowed for a short moment and then the game doing what you want?

Btw, you could invert the way you're working: Enable fullscreen in the settings and disabling it where you don't want it.

[ghost]

of course setting OS.window_fullscreen=true in any function of your game will only load when the game

yes, i know. that's why i said "before hitting gdscript". because the only way to not have that screen tear is, if you use a project.godot file on an exported game

But why do you mind having the bootsplash windowed for a short moment and then the game doing what you want?

lol -- because you then have to use this:

if OS.window_fullscreen: 
    yield(get_tree(), "screen_resized")

when changing to window_fullscreen in code, if not, control layouts get messed up (when the screen tear is happening). it's best to use project.godot

[Phoenix1747]

lol -- because you then have to use this:

if OS.window_fullscreen:
yield(get_tree(), "screen_resized")

when changing to window_fullscreen in code, control layouts get messed up (when the screen tear is happening). it's best to use project.godot

Oh ok, now I understand. That's odd, I'm really not experiencing that on Linux or with any export on Windows :thinking:

[ghost]

@Phoenix1747 well, i could make another issue about that, but was just answering your specific question. this issue, the screen tearing still happens (but i mean, it's normal because it's being called in gdscript, which is after the game loaded) you are right. i'm just saying if using project.godot it would be a lot more smoother.

we can already do that now, but it involves including all the other categories and properties. plus, AFAIK it's already reading the one inside the res:// virtual directory, no need to have 2 of em either. i think if a project.godot exists in the same directory of an exported game, the categories/properties can just be overwritten. i'm just throwing ideas out though, what are your thoughts?

[bojidar-bg]

Would it help if there is a user://settings.godot file, which gets automatically merged into res://project.godot on startup, and can be read from and written to whenever one feels like it?

[ghost]

@bojidar-bg +1 to that. for example, the entire reason i'm making this issue is because i store players game options in a .json file. and if they have enabled a fullscreen option. i then use OS.window_fullscreen=true in gdscript. then when they open the game, it loads up whatever was in project.godot first, then goes full screen, causing the screen tear. not just with fullscreen, screen size too. it would solve two problems actually.

with @bojidar-bg's implementation/idea, the developer could just update the settings.godot file:

[display]
window/size/fullscreen=true

which now, when they re-open the game, this file merges/overwrites/or whatever into the main project.godot, and launches smooth without waiting for gdscript to call OS screen methods (no screen tearing for OS.window_size or OS.window_fullscreen). it's a double whammy, really

[Phoenix1747]

Can Godot's ConfigFile interfere with the project.godot in res://? If yes you could read and write the different keys from there; maybe that's a workaround.

Also @girng what exact version of Godot are you using? I'm doing almost exactly the same as you do but it works without any layout issues.

Btw, have a look at the ConfigFile class, I think that's a better way than to store json files for you, https://godot.readthedocs.io/en/3.0/classes/class_configfile.html?highlight=config

[ghost]

thank you @Phoenix1747 but unfortunately i have to stick with json for configuration, easy to organize and works really nice in godot since json is handled beautifully. @Phoenix1747 i compiled the one from 5 days in 3.0 branch

Can Godot's ConfigFile interfere with the project.godot

i'm not sure (but even then, it might be too late). but if u do ProjectSettings.save() on an exported game it'll export everything and now we're back to the original issue 😁

[Phoenix1747]

Yeah it'll export everything so I guess you really just want the settings file to be in user:// and not just leave it in res://?

EDIT: Just tested it, you can indeed manage the res://project.godot via the ConfigFile class and change any setting that will be applied at the next restart though.

[ghost]

@Phoenix1747 my english not so good, so i apologise. even if its in user:// player can still access the entire project.godot file which i feel like is intrusive and partially redundant, since the exported game already reads from it internally. i just wish there is a way to modify that file internally.

im doing some testing:

    ProjectSettings.set_setting("display/window/size/fullscreen", true)
    ProjectSettings.save_custom("res://project.godot")

this creates the entire project.godot as a separate file when you run as an exported game. maybe that is the root of the bug, since its not updating the one internally in the virtual directory? (res://)?

because if the developer can do this, then no need for separate file? developer can just update the internal one

[Phoenix1747]

Ok I see, thanks for the clarification :+1:

[ghost]

@Phoenix1747 but you are right i think, modifying the project.godot internally on exported games would be the best solution (if possible). but need more godot contributor devs to chime in, i wait patiently

[vnen]

Would it help if there is a user://settings.godot file, which gets automatically merged into res://project.godot on startup, and can be read from and written to whenever one feels like it?

Isn't that exactly what override.cfg is about? Though it's not documented and still keeps the old name from Godot 2.1, I guess only a handful of people know about it.

[Phoenix1747]

Isn't that exactly what override.cfg is about? Though it's not documented and still keeps the old name from Godot 2.1, I guess only a handful of people know about it.

Damn there exists something like that?

[vnen]

Essentially if you put a file called override.cfg alongside the exported binary, it will be loaded on top of the regular settings file. I never actually tested it, just know it by reading the code, so don't know if it's really working.

[ghost]

@vnen what is this sorcery! i just put

[display]
window/size/fullscreen=true

in override.cfg and it works!

[Phoenix1747]

Does the override.cfg need to be in the same directory as the bin and the .pck file or does Godot also look at the user:// directory?

[eon-s]

If the engine can look at user directory, will be a great plus.

And please, add a mention in the documentation, I do not know where, maybe saving games section?

[jknightdoeswork]

Does the override.cfg need to be in the same directory as the bin and the .pck file or does Godot also look at the user:// directory?

Agreed override.cfg should be in the user:// directory so that 2 users on the same machine can have different settings.

And override.cfg should be documented. I almost built this same thing!

[Calinou]

@jknightdoeswork override.cfg is intended for development. In an exported project, you'll want to specify the path to a project settings override in the Project Settings; see https://github.com/godotengine/godot/issues/30087#issuecomment-505879289.

This should be mentioned in the documentaion, but I don't know which page would be the most suited for this.

[aaronfranke]

Might be worth placing on the 4.0 milestone, we can use the compatibility breakage to rename this file to override.godot or config.godot or similar.

[girng]

Yeah, I didn't even know about override.cfg (thanks @vnen!), that solved my problem (no screen tear, smoother UX upon startup, etc). I am not sure if this is still an issue since there is documentation for it now.

[akien-mga]

res://override.cfg works, but the better option is to use a Project Settings Override saved in user://: https://docs.godotengine.org/en/latest/classes/class_projectsettings.html#class-projectsettings-property-application-config-project-settings-override (new in Godot 3.1).

I'll close this issue as it's old and solved. There might be ways to make this more user-friendly for Godot 4.0, but those should likely be discussed in https://github.com/godotengine/godot-proposals