___________________________________________ - GreedFall - MOD SLOT SUPPORT [PC] ___________________________________________ July 29, 2020 Version: 3.01 Written by: Dheu Email: Dheuster@gmail.com Use subject: MOD SLOT SUPPORT v3.00 QUICK SUMMARY ------------------------------------------------------------------------------- Adds Quest Initialization and localization support to GreedFall to make it easier for various mods to run together without conflicting with each other This distribution is not a MOD in and of itself. It provides a framework for mods to override. ------------------------------------------------------------------------------- I. > > > > The Problem ------------------------------------------------------------------------------- A. Problem 1: Mod Configs GreedFall is a config driven game. So most mods edit the configs to provide you with cool features. Problem is, many of those configs are centralized. ALL the weapons and armor are defined in 1 file. ALL the potions are defined in another. All the merchant inventories in another. So if 2 mods want to edit the merchant inventories, they confict. Maybe one mod wants to change the pricing while another mod wants to change the weight and yet a 3rd mod wants to add some new items. You can't have all three of these things at the same time because the merchant inventories are controlled by 1 single config file. B. Problem 2: Mod Quests/Initialization Many mods require more than just config edits. For example, if someone wishes to add a new craftable potion/wand/staff, etc... to a workbench, it isn't enough to define the spell, recipe and items in config files. The player has to GET the recipe somehow. To do that, the mod needs to run a quest to give the player the recipe. Quests ultimately fire from level loaders. So when they edit that level loader, they now conflict with every other mod that edits the same level loader. C. Problem 3: Localization Localization refers to the process that games use to support multiple languages. Most games use placeholder type tokens like #AWESOME_SWORD within the game code. Then when you start the game, it reads in a region specific table that defines what text to use for that token. Subtitles, item names and descriptions, tool tips; if it involves text then it is supported by Localization tokens. The issue is that GreedFall does not allow mods to alter the localization tables. While most aspects of the game can be modded and overridden by placing files in your GreedFall\datalocal directory, localization updates are ignored. There are ways to get around this with ITEMS. IE: Things you can purchase from a merchant. But that isn't actually localization support. The mod has to include hard coded text that will be the same regardless of the users language settings. ------------------------------------------------------------------------------- II. > > > > The Solution ------------------------------------------------------------------------------- This mod solves the problems discusssed above. A. Mod Quests/Initialization support Mod Slot Support edits every single level loader in the game and adds an event hook. All the level loaders inform a single level loader d efined by this mod of their level loading event. They pass the name of their level as part of the event. This mod in turn relays that event to 20 non-existent quests named "mod_slot_1" -> "mod_slot_20". If a quest doesn't exist, the game simply ignores it without error. So by default, the level loader does nothing. But if the user installs another mod that defines a file named "mod_slot_#.sqg" (where # = a number between 1 and 20), that mod will receive level load events from this mod. So what if you download 10 mods and they all use the same mod_slot number? Well, this distro has you covered. It includes an executable (And source code for the paranoid) that scans your datalocal directory for conflicting mod_slot files and if it finds any, it renames them so that they don't conflict. B. Mod Config Merge Manager The same executable I mentioned above will also scan your datalocal directory for any and all game files and detect if 2 mods are trying to edit the same file. If conflicts are detected with CONFIG files (files that end with .sli), Mod Slot Support can attempt to merge all the conflicting files into new overrides created within the !ModSlotSupport directory. Not all files can be merged, but Mod Slot Support provides feedback and tracks which mods have outstanding conflicts. Even if you opt out of the merge, it will give you a summary of what is likely working and what is likely broken. C. Localization Support The same executable I mentioned will also look for localization files. It will then backup the original game localization table and manually re-write it with any localization files found in the datalocal directory. Thus authors can now include localization files with their mods and the application "updatemods.exe" will find them and integrate them into the game. ------------------------------------------------------------------------------- III. > > > > Installation ------------------------------------------------------------------------------- 1) If you do not already have it, get 7-zip : www.7-zip.org ** Do not use WinRar to open/extract .7z files. It can corrupt them. 2) Once 7-zip is installed, open the .7z file Typically you need only double click the file: ModSlotSupport_v2_00.7z 3) The 7-zip window will show 1 file: /datalocal 4) Extract /datalocal to the location of your Greedfall installation. Most people will find it in one of these two locations: Computer -> C:\Program Files (x86)\Steam\steamapps\common\GreedFall or Computer -> C:\Program Files\Steam\steamapps\common\GreedFall Once Extracted, the final directory path should look like: ...GreedFall\datalocal\!ModSlotSupport ...GreedFall\datalocal\mod_slot_0.sqg ...GreedFall\datalocal\updatemods.exe ------------------------------------------------------------------------------- IV. > > > > Usage ------------------------------------------------------------------------------- 1) Organize your mods.... When you install a mod, I do NOT recommend using Vortex. Vortex will blindly extract the mod archive to the datalocal directory of GreedFall. But many mods fail to create a sub-directory that identifies the mod. So, manually download mods, look at the archive in 7-zip. If the mod author structured their archive so that the mod is well idenfied, great! Just extract it. For example, Naut-E Wares, Map Anywhere and Romance Enhancer all do this, so nothing is needed on your part. Just extract them to GreedFall. But if the mod archive doesn't have structure that results in a single subdirectory within datalocal that identifies the mod, then you need to extract it yourself to a directory that identifies the mod. PRO TIP: All GreedFall files have unique names so the game doesn't care what the directory structure of datalocal looks like. Example 1: Sheathe (Version 1.3.10) Start by creating a directory for the mod under datalocal: ...\GreedFall\datalocal\Sheathe\ Then extract all of Sheathes files to the directory you just made: ...\GreedFall\datalocal\Sheathe\0_Libraries_Sheathe_Both_Weapons\ ...\GreedFall\datalocal\Sheathe\2_Sheathe_Both_Weapons\ If you download any optional downloads, make sure you place them in the same directory (Sheathe). Example 2: MoreCarryWeight (Version 1.0) Start by creating a directory for the mod under datalocal: ...\GreedFall\datalocal\MoreCarryWeight\ Then extract all of the mods files to the directory you just made: ...\GreedFall\datalocal\MoreCarryWeight\attributes\ Example 3: All Items with all merchants from start game This one is interesting because it contains datalocal at the root, and has a single directory above it. But the directory is generic and doesn't identify the mod. In this case, I actually extract the mod to the GreedFall folder as is, but then I rename the generic name "game_components" to something that identifies the mod: Extract the archive with datalocal root to GreedFall: ...\GreedFall\datalocal\game_components\game_components_ld_autogen\... Rename the generic name to something you recognize: ...\GreedFall\datalocal\AllItemMerchants\game_components_ld_autogen\ 2) Run updatemods.exe After you finish installing/organizing your mods or after you install a new mod, return to the datalocal directory using explorer and run the executable: ...\GreedFall\datalocal\upatemods.exe updatemods.exe will ensure all your mod slots are unique. It will make sure all timestamps are valid. It will identify and possibly resolve conflicts and it will look for mods with localization updates. In most cases, it will prompt you before making updates. If you install additional mods in the future, you will want to repeat the process above (make sure the directory identifies the mod, run updatemods.exe). NOTES: ------ updatemods.exe detects your current language settings by attempting to read in the Steam config. If it fails, it defaults to English. If you experience issues with updatemods.exe detecting the correct language, or you are not using the STEAM version of GreedFall, you can force the language by copying one of the files from: ...\GreedFall\datalocal\!ModSlotSupport\lang_support To ...\GreedFall\datalocal So for example, if you have a russian version of the game and you purchased it from a non-steam based website, you can copy: ...\lang_support\upatemods_russian.cmd to: ...\GreedFall\datalocal\upatemods_russian.cmd Then when you run upatemods_russian.cmd, it will force updatemods.exe to use the russian language packs and search for russian localization files. PARANOID PEOPLE: ---------------- If you are paranoid and don't like running executables from mod websites on your computer (like me), the source code for updatemods is included. It is located under: ...\GreedFall\datalocal\!ModSlotSupport\updatemods_src\updatemods.py The app was written in Python and converted to an executable using the pyinstaller utility. If you are not interested in running executables, an alternative is to install Python 3.6 or newer and copy the updatemods.py file to the datalocal directory. You can then run the script directly instead of using an executable. As a python script, the source code is there for you to look at if you want to confirm it isn't doing anything malicious. NOTE: If you want to use the python script AND you need to force language support, you may need to edit the last line of the .cmd file so that it runs updatemods.py instead of updatemods.exe ------------------------------------------------------------------------------- V. > > > > Un-Install ------------------------------------------------------------------------------- A Word of Caution: Other mods may rely on this mod, so if you uninstall it, be aware you may break other mods. 1) Using File Explorer, locate the games installation directory on your computer. Most people will find it in one of these two locations: Computer -> C:\Program Files (x86)\steam\steamapps\common\GreedFall or Computer -> C:\Program Files\steam\steamapps\common\GreedFall 2) Within the GreedFall game folder you will find: ...\GreedFall\datalocal\!ModSlotSupport 3) Double Click/Run: ...\GreedFall\datalocal\!ModSlotSupport\uninstall.cmd (This is a batch script. You can edit it with a plain text editor and view what it does if you wish) The uninstall.cmd will kick off updatemods.exe with the "-r" flag, which tells it to reset. This includes deleting any merged config files and restoring the original language file. 4) Right click the directory "!ModSlotSupport" and delete it. DO NOT DELETE the parent folder "datalocal" as other mods or DLC may be stored there. Only delete the child directory "!ModSlotSupport" 5) Finally, you will need to remove the following files: ...\GreedFall\datalocal\mod_slot_0.sqg ...\GreedFall\datalocal\updatemods.exe ...\GreedFall\packs\*.spk.bak ...\GreedFall\packs\*.stc.bak So for example, if you see the file "loc_eng_data.spk.bak" in the packs directory, you would remove it. Using file explorer, you can sort the folder by File TYPE to quickly isolate the ".bak" files. Most users should only see 2 bak files. 6) You are done! ------------------------------------------------------------------------------- VI. > > > > Version History ------------------------------------------------------------------------------- 1.00 : May 2020 - Initial Release. Introduced Mod Slots 2.00 : June 2020 - Added Localization Support (updatemods.exe) 3.00 : July 2020 - Added Mod Config Merge Support (updatemods.exe) 3.01 : July 2020 - Fixed Localization Merge Failure when changes smaller than original file. ------------------------------------------------------------------------------- VII. > > > > Technical : How to edit SLI files for Mod Authors ------------------------------------------------------------------------------- Mod Slot Support's trivial merge capability has a few simple rules: - Inserts (new lines) are always okay. To be precise, you create a new line by placing the cursor at the beginning or end of an existing line and hiting enter. You can then put whatever you want within or create more lines. If all mods made additive changes with inserts, then all mods would succeed to merge together. - Updating an existing line is allowed, but only 1 mod can update a given line within a file. So 10 mods can all make updates to the same file as long as none of them update the exact same line. - Deletes should be avoided. Deletes are allowed, but instead of contention being resolved at the LINE level, contention is resolved at the FILE level. So if Mod A deletes a line in some file, no other mods will be able to delete lines in that file. So be aware if you delete lines from SLI files, even blank lines or comments, you greatly increase your odds of contention with other mods. Special Cases: -------------- There are some auto generated SLI files in the game that have very few line feeds. Updatemods.exe has a special pre-processor that breaks these files up using the command: content.replace('\r\n','\n').replace('><','>\n<') This isolates the XML elements so that most elements exist alone on a line. This allows element-level changes by various mods. Here is a list of the files that get pre-processed: autogen_blend_prioritysets.sli actions_autogen_cutscene.sli actions_autogen_cutscene_background.sli actions_autogen_dialog.sli actions_autogen_hum.sli actions_autogen_mob.sli actions_autogen_skills_hum.sli actions_autogen_skills_mobs.sli attributes_patterns_autogen_mobs.sli cha_autogen_background.sli cha_autogen_cs_extra.sli cha_autogen_mob_variantes.sli cha_autogen_npc_variantes.sli craft_conso_items_autogen.sli craft_recipes_conso_autogen.sli craft_ingredients_autogen.sli game_components_ld_autogen_traders_inventory.sli items_autogen_craft_settings.sli items_autogen_crafts.sli items_autogen_creatures.sli items_autogen_equipements.sli items_autogen_recipes.sli items_autogen_loots_all_conso_recipes.sli loots_autogen_armors_trash_mobs.sli loots_autogen_chests.sli loots_autogen_mobs.sli loots_autogen_quests.sli loots_autogen_random_sets.sli loots_autogen_sets.sli loots_autogen_weapons_trash_mobs.sli objects_autogen_base.sli pattern_squads_autogen.sli skills_autogen_hum.sli skills_autogen_mobs.sli skilltree_autogen_default.sli skilltree_autogen_mobs.sli skilltree_autogen_player.sli soundimpacts_autogen.sli Example: items_autogen_equipements.sli Normally each item definition is on a very long single line and it encompasses almost everything about the item: What recipe it is compatible with, what its weight is. What its price is. What damage it does, what model it uses, whether it can be upgraded. Since the file above gets broken up, each element can be edited by different mods without affecting the others. So one mod could change the price of all items. Another could change the weight. Another could increase damage and yet another could make all items compatible with upgrade slots. Such combinations were not possible in the past, but thanks to the pre-processor, they are now possible. Other: ------ For the purpose of comparing lines, leading/trailing whitespace is ignored. So if your changes are limited to addign indention for readability, (especially to the files above that get broken up into thousands of lines) then those changes would not be considered an update. Test: ----- I recommend downloading a few of the more popular mods and confirm that everything after running updatemods.exe before you release. If you have conflict with a popular mod and the merge fails, you have some decisions to make: Either fix your mod to avoid the contention or accept that your mod won't be compatible with the other mod. ------------------------------------------------------------------------------- VIII. > > > > Technical : Localization Examples For Mod Authors ------------------------------------------------------------------------------- The localization file for a language has 2 parts: GreedFall\packs\loc__data.spk GreedFall\packs\loc__data.stc A) loc__data.spk The SPK is a Silk Package. It is a 4K Zip-Aligned Archive that you can open up and extract with 7-zip. Within you will find a number of pre-existing text files that define localization tokens. There are some general purpose files like: gameplay_items_.txt And then there are files that support conversation banks. B) loc__data.stc The STC is a Silk Table of Contents. It basically provides a lookup so that the engine can quickly figure out where a file is located within an SPK without having to load the entire SPK into memory. This is important for large SPK files (texture archives), but is less important for localization files. C) NEW TOKENS: ADDITIVE CHANGES The pre-existing filenames in the SPK and STC are for categorization reasons only. All files get read in and loaded when the game runs, so it doesn't actually matter where new tokens are defined: If you define an item token in a dialogue bank or a subtitle token in the items bank, they will all get loaded and simply work at runtime. For this reason, I made sure "updatemods" scans for NEW FILES and simply appends them to the existing SPK/STC. This way mods with only additive changes can simply add their content to a mod specific localization file. So what do you need to do to make this happen? In your mod specific directory, make a sub-directory named "text": ...\GreedFall\datalocal\YourModDir\text\ Then within the text directory, create a new localization file: ...\GreedFall\datalocal\YourModDir\text\YourModDir_eng.txt Notice that the example above ends with "_eng.txt". This tells updatemods that the file should only be merged if the user has their language set to English. If you want to support other languages, you will need to create a seperate file for each language (and define the same translated tokens within each): ...\GreedFall\datalocal\YourModDir\text\YourModDir_chn.txt ...\GreedFall\datalocal\YourModDir\text\YourModDir_eng.txt ...\GreedFall\datalocal\YourModDir\text\YourModDir_fra.txt ...\GreedFall\datalocal\YourModDir\text\YourModDir_ger.txt ...\GreedFall\datalocal\YourModDir\text\YourModDir_ita.txt ...\GreedFall\datalocal\YourModDir\text\YourModDir_pol.txt ...\GreedFall\datalocal\YourModDir\text\YourModDir_ptb.txt ...\GreedFall\datalocal\YourModDir\text\YourModDir_rus.txt ...\GreedFall\datalocal\YourModDir\text\YourModDir_spa.txt Main two take aways: - File goes in a directory named "text" - File ends with "_.txt" If either of the above 2 conditions above are not met, updatemods will ignore the file. IMPORTANT: If you are using NotePad++ to edit/create your .txt files, you must set the Encoding to "UCS-2 LE BOM". Otherwise the game will report an error on startup regarding the localization files. If you do not use NotePad++, then you should always start by extracting the existing localization files and rename/edit an existing file to ensure the encoding is correct. C) UPDATING TOKENS: Suppose you want to change the name of the Greater Haze potion to use the word Stealth instead. In this case, you would need to locate the name of the file where the Haze Potion name is defined and update it with the a new description: In this example, the file would be: gameplay_items_eng.txt and the token would be: Greater stealth potion Then in your mods text directory, you would include the file: ...\GreedFall\datalocal\YourModDir\text\gameplay_items_eng.txt ** And any other languages you want to support updatemods.exe will notice that your filename matches the name of an existing SPK/STC filename and instead of appending it to the end of the archive, it will update it in place. Note that when you UPDATE game files, you risk conflicting with other mods that also attempt to update those same files. So in general, it it is better to avoid editing existing game files unless the nature of your mod is that it alters or fixes original game text. (In which case, a user would likely expect such conflicts). As of version 2.0, updatemods.exe only supports ADDITIVE MERGING. So if you edit gameplay_items_eng.txt, but you place all your changes at the END OF THE FILE, and two other mods do the same, updatemods.exe will merge all the additive changes into a new file and append it to the end of the archive. However... if 2 mods edit the body/content of an existing file, that is not a conflict that version 2.0 handles. In that case, 1 file will "win" and the other will "lose". So again, unless the nature of your mod is to edit existing text, it is better to make new tokens in a new file then edit ther original files. If I have time, I may eventually add trivial merge support to later versions of updatemods.exe that does conflict resolution on a per-token basis, but as of version 2.0, conflict resolution is still done on a per-file basis. IMPORTANT: If you are using NotePad++ to edit/create your .txt files, you must set the Encoding to "UCS-2 LE BOM". Otherwise the game will report an error on startup regarding the localization files. ------------------------------------------------------------------------------- IX. > > > > Technical : Mod Initialization Examples For Mod Authors ------------------------------------------------------------------------------- There are a couple of approaches to integrating with this framework. A. Balanced So the balanced approach works best for mods that typically only need to edit 1 level loader script. Scenario: You add a new item to the game. To get the item, you tell users to simply travel to New Serene. Meanwhile, you edit the New Serene Level loader and add a callgraph that activates a custom quest. That quest checks to see if the player has your new item or recipe and if not, adds it to the players inventory. Then on your front page, you tell users to simlpy travel to New Serene and the item will appear. In this scenario, you would keep your edit to the New Serene Level Loader (lvl_02_south_city_background.sqg), however you would pass the name of the city to your quest when you hook your code in. IE: In lvl_02_south_city_background.sqg at the bottom of the start block: ---------------------------------------------------- datalocal/your_mod/lvl_02_south_city_background.sqg: ---------------------------------------------------- ... ... ... ---------------------------------------------------- Then in your_mod_loader.sqg: --------------------------------------- datalocal/your_mod/your_mod_loader.sqg: --------------------------------------- ... The above example would bail if the level name wasn't "lvl_02_south_city". This is important because when it is driven by ModSlotSupport, it would get called every time you changed maps or travelled to a new area. So if you want something to ONLY HAPPEN in a single area, you need a name check. The last step is including a mod_slot_#.sqg with your mod that redirects to the same quest. Simply copy "mod_slot_0.sqg" from datalocal to your mods directory and then follow the directions in the file. datalocal/mod_slot_0.sqg -> datalocal/your_mod/mod_slot_12.sqg If a user does NOT have ModSlotSupport installed, then mod_slot_12.sqg above would never get called, but your mod would work because you edited the level loader for New Serene. If the user has ModSlotSupport installed, then ModSlotSupport would override your changes because it installs its changes in a high-priority folder, however your mod would still (probably) work because it would call your mod_slot_12.sqg initializer. What if it doesn't work? For conflict resolution, you would tell users in your documentation (or on your mod page) to go to datalocal and run "updatemods.exe". This should update the mod slot numbers so that there are no conflicts. I say this is balanced because you are only really including 1 additional file with your mod to ensure compatibility SHOULD the user have ModSlotSupport installed. But your mod remains quite capable of working on its own without the external dependency. B. Dependency: Some mods may need more expansive support than a single hook/entry point in some level. Also... localization is a non-starter without Mod Slot Support, so if you want to update text in the game other than items (or you want international support for your item names), you will want to simply have a dependency on this mod. Scenario: Lets suppose you are making a mod taht involves a new spell that will bring up a dialogue menu of optional commands that the user can select from. Unfortunately dialogue menus can not normally be started from a spell effect. So you need a quest monitor that runs on every map in the game to wait for your spell to get cast (maybe the quest waits for a global variable to change and the spell changes it) But that is only part of the problem. There is no way to add new spell names or change existing spell names without localization support. In the above scenario, you are looking at capabilities that will require editing every single level loader and you need a way to update the SPK/STC files. Technically, you could pre-generate the SPK/STC and include it with your mod, but then you become incompatible with every other mod in the world that adds text to the game. In this case, it makes sense to just embrace Mod Slot Support The best way to embrace it is to simply make it a hard dependency. That is, in Nexus (and your readme) mention this mod is required for your mod to run. In the case of Nexus, the site will actually inform and enforce requirements. If someone installs something with Vortex and your mod has another mod marked as a dependency, vortex will automatically download it. The other way is to include this mods code as part of your mod. You shouldn't need to edit any of the this mods files. Rather, you include this mods code in case for whatever reason this mod disappears from the internet. Even if a user has this mod installed, clobbering the files wont hurt anything (as long as they are exactly the same). MY ONLY CONDITION with including this mod with your own is that you must include the source code to updatemods.exe. If you go with the inclusion route, you also won't inherit updates and bug fixes. C. Does and Donts (Mostly donts) 1) DONT put ONCE elements in your mod_slot_#.sqg file. If a user uninstalls your mod and installs a different mod in the same slot, the game has no idea a different mod is now using the slot. So you don't want any residual state to affect the next mod. To avoid residual state, you want to limit what you do in mod_slot_#.sqg to be a simple redirect to your mods own initializer. Furthermore, updatemods.exe may change your slot number when ran by a user. So any assumptions about the slot being ran for the first time may be invalidated by that fact. So you want the mod_slot_#.sqg to always call your own questGraph initializer to ensure any state is properly maintained even if the mod_slot_#.sqg changes. ** This is exactly what the example mod_slot_0.spg does that comes with this distro. 2) DO: Use unique names for your files and tokens. Remember, there are lots of mods out there, so don't make the name of your files too common like "initialize.sqg". In fact, putting a prefix on all of your mods files and text tokens is a good habit. It makes it easier to uninstall and avoids conflicts with other mods that are doing similar things. 3) DONT include a FULL EXTRACTION of the localization text directory with your mod. That is... If you update the games original tokens, only include files you actually EDITED. Including unedited files will just create confusion and unneeded conflicts. D. Advanced scenarios Lets suppose your mod needs to legitimately make a change to one of the level loader scripts for reasons other than getting a thread of execution. NOTE/FYI: All the level loader scripts are located under "datalocal/levels/levels_dedicated/" and end with "_background.sqg" In this hopefully rare case, you could merge your changes with the changes from this mod into the affected file. This mod adds exactly 8 lines to each of the level loader scripts. Basically a hook added to the end of the startBlock. So lets suppose you needed to edit lvl_02_south_city_background.sqg. Then you would take your file, add the 8 lines that this mod adds to your start block and then you would save the file in the directory: datalocal/!#ModSlotOverrides/lvl_02_south_city_background.sqg The directory name is important. The "!#" at the front ensures it will take priority over the lvl_02_south_city_background.sqg that ModSlotSupport normally ships with. Even if you are not using ModSlotSupport, this will work fine because the game doesn't complain if you use callgraphs to quests that don't exist. So the above makes your code compatible with ModSlotSupport when installed, but doesn't harm anything when it isn't installed. Now.. If another mod needs to edit the same file (and the user tries to install it), then they will become aware of the contention because 7-zip will tell them about a file overwrite that they shouldn't be getting prompted for. As for resolving those types of contentions, that is between you and the other mod author. I am not getting into the middle of that. =) E. Level Names (Optionally Passed along as quest script arguements) lvl_00_travel lvl_01_continent_city lvl_02_south_city (New Serene) lvl_03_dungeon_crypt lvl_03_dungeon_mine lvl_03_south_plain lvl_04_south_front lvl_05_east_valley lvl_06_south_valley lvl_07_dungeon_lab lvl_07_east_city (Hikmet) lvl_08_west_city (San Matheus) lvl_09_dungeon_cave lvl_09_east_savage lvl_10_west_valley lvl_11_west_savage lvl_12_dungeon_king_cave lvl_12_heart_village lvl_13_north_valley lvl_14_heart_sanctuary lvl_15_heart_valley lvl_16_north_sanctuary F. User Uninstall Considerations If you include the ModSlotSupport files as part of your mod, then your uninstall process should just leave the ModSlotSupport files on the users machine (as they may have existed before your mod and other mods may be relying on them). Your uninstall instructions should only focus on the contents of your mods directory. If your mod includes a text directory and you only made additive changes, you don't need to tell users to run updatemods.exe as the additional tokens wont harm anything. However, if you made CHANGES to the original game tokens, once your mod directory has been removed, you will need to instruct users to run updatemods.exe, so that the original tokens are restored.