Add overwrite functionality about godot-mod-loader HOT 10 CLOSED

I successfully tested this with Brotato-Explosion-Mute, by allowing file replacement.
The complexity to achieve the desired result is greatly reduced.

KANA-ExplosionMuteV2.zip

from godot-mod-loader.

From my reply on Discord:

What about a separate folder? Eg mods-overrides. That way it'd give them a standardised structure and would make it clear when a mod is overriding something in vanilla
Then we could just run _load_mod_zips twice, with the second call being passed an arg that says to use the "overrides" folder and use true for load_resource_pack

from godot-mod-loader.

Darkly77 - Another use case for replacements: You could do stuff like make a balance pack for Brotato. Eg people often say Plank is weak, so someone could release a mod that improves its scaling by replacing the vanilla file.

from godot-mod-loader.

From my reply on Discord:

What about a separate folder? Eg mods-overrides. That way it'd give them a standardised structure and would make it clear when a mod is overriding something in vanilla
Then we could just run _load_mod_zips twice, with the second call being passed an arg that says to use the "overrides" folder and use true for load_resource_pack

Now that I'm working on it - we can't do a separate folder because the only way to overwrite is to mirror the file paths inside the mod zip.

yourmod.zip
├───.import
└───mods-unpacked
    └───Author-ModName
        ├───mod_main.gd
        └───manifest.json
└───projectiles
    └───rocket
        └───explosion.png

There is also no point in adding something like "is_overwrite": true to the manifest.json That is loaded after we need to set the replace flag for ProjectSettings.load_resource_pack()

So the only way to send data in this stage to the mod loader is the name of the zip file?
That would mean we can't use arbitrary zip names any more.

from godot-mod-loader.

(my input from Discord:)

Hey, I've been looking into this too! I realised that allowing full overrides would mean we're loading stuff from mod ZIPs before we get a chance to read their meta data.
That means a mod could be published that doesn't even have a manifest.
So my approach is to simply replace resources from within mod_main. That ensures mods stay within our current standards

EDIT: Loading directly from the ZIP would also mean wouldn't be able to do validation stuff, like check dependencies etc, as we'd be loading in modded content before the manifest was ready.

from godot-mod-loader.

Example mod with my approach. Changes the color of the logo. Has 3 different colors, the last one mentioned in the code is the one that gets used.

mod_main.gd:

extends Node

func _init(modLoader = ModLoader):
	var new_logo = preload("res://mods-unpacked/Darkly77-LogoReplacement/overrides/ui/menus/title_screen/ui_logo__blue.png")
	new_logo.take_over_path("res://ui/menus/title_screen/ui_logo.png")

Download:

• Darkly77-LogoReplacement--ML-3.1.0.zip -- (compatible with ML v3.1.0)

Screenshot:

from godot-mod-loader.

🇦 ) Mod Loader Handling - Restart game once ( if a overwrite mod is added / removed )

var overwrite_index = preload("res://mods-unpacked/ModAuthor-ModName/overrides/path/to/overwrite/resource")
overwrite_index.take_over_path("res://path/to/original/resource")

🇧 ) Let mod authors create the overwrites.gd at the root of the mod folder

🇨 ) use --script run.gd

from godot-mod-loader.

Just to reference it here as well:

There is also the possibility to reload a scene with a new PackedScene.

• For that I used get_tree().change_scene_to(PackedScene) in a script extension of the scene that is the owner of the overwritten resource.

• That allows to use just load() to load the replacement resource

• load() can take variable resource paths

• That potentially allows to add a util function to the mod loader for mod authors to use

• I didn't explorer this further because the preload() solution currently seems way cleaner and doesn't require to reload / replace in a scenes _ready() function.

Example Brotato Mod of this solution:
Darkly77-LogoReplacementSceneReloading.zip

from godot-mod-loader.

closed by #74

from godot-mod-loader.

Darkly77 - Another use case for replacements: You could do stuff like make a balance pack for Brotato [...]

I've found that replacing files can be a bad idea because it can mess up extended scripts.

I was trying a few things with the file character_selection.tscn, and after replacing it I found that the extended scripts for character_selection.gd (which is referenced in character_selection.tscn) no longer worked. Replacing .tres files likely has the same negative effect, where any .gd scripts that are referenced in that .tres file will ignore their extensions.

This needs further testing though.

from godot-mod-loader.