4.6+ new self setup

[Qubus0]

since the --script launch parameter will be gone if the game doesn't use a custom compiled export template godotengine/godot#111909 we need to change our setup process.

while override.cfg can be disabled completely now godotengine/godot#108818 it is our only (non-intrusive) entry point for now.

we do however have the new autoload_prepend option for override.cfg godotengine/godot#113078 . this means we can add an override which does not affect any other option in the project settings and only adds our autoloads. We don't necessarily need --script anymore since we don't need to read the project settings.

this means the new setup is probably just placing an override.cfg in the correct place (next to the <game>.exe on windows/linux and inside the <game>.app bundle /Contents/MacOS/<game> folder). this mainly needs testing and a docs update.

i think with this prepend we won't need any direct injection with gdre or pcktool anymore.

for mac we might want to consider a tiny bash script to move the override in the correct location, since not that many people know about .app being a folder

[kyfex-uwu]

I've just finished making a setup for this, and while I'm sure it can be improved I can confirm that you can get 100% functionality just from overriding the config file and adding a couple other support files

[Qubus0]

nice. do you want to open a pull request for it? then we can check fr improvements or just take it as the starting point

[kyfex-uwu]

sure :) before i start working on anything specific, i do want to give some insight
when running with the ModLoader and ModLoaderStore added as prepended autoloads, none of the other supporting scripts are loaded into scope. There's 3 ways (as far as i can tell) to fix this:

1. Limit the mod setup to only access these 2 files (could break mods, since preload/load wouldn't point to the right files anymore because they're not being loaded)
2. Override the global_script_class_cache (keeps our dependency on GDRE and creates another folder (ew))
3. Have a "ModLoaderLoader" script that just loads the mod loader as a zip, so everything is in scope and no files break (making a zip on the fly sounds like the best option, since users can still have file autocomplete when using preload/load)

Personally, I'm inclined to go for option 3, but I'd love to hear your thoughts before i do anything drastic

[Qubus0]

1. should already be the case, all the setup scripts are disconnected from all other classes because this issue has existed in all versions.
2. yeah nah that seems annoying in multiple ways
3. that's the cleanest, yes. i'd only use the zippacker to wrap the class cache file and nothing else. the scripts work fine like they are even without being wrapped into a zip.

with 3 we also don't need to do this stuff here, since godot should properly combine them
https://github.com/GodotModding/godot-mod-loader/blob/4.x-dev/addons/mod_loader/mod_loader_setup.gd#L303-L327