Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit)

This looks like one of the classic cases of Strive glitching on a mod installation. I would recommend (unless you’ve already got it fully fixed) just unzipping and creating a new game folder (with the Exe, not the app data) to be sure it hasn’t left any duplicated code in their that will mess you up later on. It should be pretty easy and take 1-3 minutes to fix that way and shouldn’t affect your saves or mods.

If you do that, then you do need to delete the FileOrder.ini from your mods folder just to be safe like he said

While I agree that a full re-install is likely the safe bet, FileOrder.ini is a records file for the GUI and mostly inconsequential.  Neither leaving it nor deleting it will have a positive or negative effect on the game.

It just ends up an taking extra reboot step to “disable” the mod then enable it as the game will still detect it as installed if it was active when the game was last booted.

You are welcome to look at modpanel.gd and try to find that mechanic; however, you are reading between the lines to find mechanics that don't exist.

"func show():" refreshes the mod list GUI, and uses loadorder to sort the mod line, determine which mods have pressed buttons, and get the order number shown beside the mod.

"func _on_applymods_pressed():" uses loadorder without any checks for "enabled" or "disabled".  The first thing it tries to do is erase all currently installed mods, so it doesn't care what is installed. Next, it iterates on loadorder to install mods one at a time.

Thus, removing the mod from the load order has a total functional result of forcing you to add it back to the load order.

Ok thanks. I kinda of figured that out myself once i fixed that and started getting other errors coming up and code duplicated in other spots. I think its because as someone else mentioned I was using the code fixes and didn't quite understand how horrible the mod system was in this game yet.