Autoload order is not affected by override.cfg

[Qubus0]

Godot version

4.0.b13, 3.5.stable, 3.4

System information

OSX

Issue description

Overriding autoloads with an override.cfg ignores the order set in the override. Newly defined autoloads are always loaded last.

Why does this matter? I'm trying to (co-)create a mod loader that works with any Godot game. The loader itself is an autoload. With the override we can 'install' it into a game without having to touch or modify its source code. The loader always being last limits the capabilities for extending existing autoloads heavily.

Steps to reproduce

1. Have a project with at least one autoload and one other script to make a new autoload
2. create an override.cfg
3. add the other script to the overrides and move it into the first spot
4. run game

; project.godot
[autoload]

Autoload1="*res://autoload_1.gd"
Autoload2="*res://autoload_2.gd"

; override.cfg
[autoload]

AutoloadOverride="*res://autoload_override.gd"
Autoload1="*res://autoload_1.gd"
Autoload2="*res://autoload_2.gd"

result: order does not matter, the autoload from the override is always last

autoload 1 init
autoload 2 init
autoload override init
autoload 1 ready
autoload 2 ready
autoload override ready

each file only contains this

extends Node

func _init() -> void:
	print("autoload x init")

func _ready() -> void:
	print("autoload x ready")

Minimal reproduction project

for 3.5, but also works after 4.0 conversion
AutoloadOverrideReproduction.zip

[RedMser]

This is because the override.cfg file adds settings, rather than replacing them (e.g. if you only included the AutoloadOverride entry and nothing else, the autoload 1 and 2 prints are still there).

Since autoloads are the only project setting that is "order-dependent", not sure what a good solution would be here, but I don't think this is a bug, but rather a feature request.

Can't find a workaround, since even a custom MainLoop type seems to initialize later than any autoloads...

[Qubus0]

This is because the override.cfg file adds settings, rather than replacing them

That is very unexpected behaviour for something called override

Especially with the wording in the documentation

Overriding: Any project setting can be overridden by creating a file named override.cfg in the project's root directory. This can also be used in exported projects by placing this file in the same directory as the project binary. Overriding will still take the base project settings' feature tags in account. Therefore, make sure to also override the setting with the desired feature tags if you want them to override base project settings on all platforms and configurations.

I suppose it is the way it works for most properties since they only have a single value, so nothing can be 'added' to it.

I would really love to have this, if only for autoloads and nothing else. If someone can point me in the right direction, I am completely willing to implement it myself - I just don't know what to go off of

And I feel like the changes necessary will probably fit well with these two PRs from last week

• Refactor ProjectSetting overrides #71325
• Move global script class cache to separate file #70557

[akien-mga]

override.cfg does override the values of existing properties, and appends new property/value pairs which aren't present in the original project.godot.

The problem here is that autoloads as registered as properties themselves. And there doesn't seem to be a mechanism for removing existing properties.

Changing it to e.g. a dictionary property could make the dictionary overridable, e.g.:

[autoload]

autoloads={
  "AutoloadOverride": "*res://autoload_override.gd",
  "Autoload1": "*res://autoload_1.gd",
  "Autoload2": "*res://autoload_2.gd",
}

But that's indeed material for a feature proposal, so we can discuss possible solutions and implement the best one.

[Qubus0]

Closing in favour of the new proposal #6137