Give Feedback
0 of 0
Documentation
Readme
View as plain text
___________________________________________
- GreedFall -
MOD SLOT SUPPORT
[PC]
___________________________________________
July 29, 2020
Version: 3.01
Written by: Dheu
Email: [email protected]
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_
GreedFall\packs\loc_
A) loc_
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_
And then there are files that support conversation banks.
B) loc_
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 "_
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:
----------------------------------------------------
...
...
target="your_mod_hook"
targetPinIndex="0"
pinName=""
targetPinName="Start" />
levelSpecific=""
graphName="your_mod_loader">
...
----------------------------------------------------
Then in your_mod_loader.sqg:
---------------------------------------
datalocal/your_mod/your_mod_loader.sqg:
---------------------------------------
...
levelSpecific="">
target="checkConditions"
targetPinIndex="0"
pinName=""
targetPinName="" />
levelSpecific="">
target="one_time_only"
targetPinIndex="0"
pinName=""
targetPinName="" />
mode="ALL">
leftOperand="@LevelName"
operator="="
rightOperand="lvl_02_south_city" />
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.