...Poll is pointless..


and you can do pretty much everything stated already in Oblivion.....what makes you think Skyrim will be any less..

as far as i know, the cs does not generate forests. and the scripting is so limmited there cannot be modds that completely change an aspect of gameplay without doing something extremely hackey (deadly reflex for oblivion broke the game, i had to delete it and all its relatives)

How to make more modder friendly games.
The Elder Scrolls Edition.

=== === === === === === === === === === === === ===

Elder scrolls games are masterpieces of game design and modablity. The first time that I was playing Morrowind, when finally after a long journey, I reached Balmora, I looked at the world map and I was amazed!

Such a huge world and I had only discovered a tiny part of that in such a seemingly long journey, I was completely dumb-founded, with such a huge and detailed world in just one CDROM.

That's pure masterpiece, but after I found out about the modded side of that game and tried to mod it a bit, and discovered the extend of it's potential modablity, I was doubly amazed, and did not know what to think of this.

I had long thought about games with such potential in modablity and then I saw one before my eyes, it was a miracle.

But after I started to add mods after mods to my setup for game, the problems started to show, as unclean mods, conflicts, misplaced resources and so on...

This problem has remained with Oblivion as well, so I decided to write about a way to reduce the potential problems between mods, and here it goes:

=== === === === === === === === === === === === ===

First of all, I think that Bethesda has to recognize the modders of his games. This is the first step, and do not say that as the elder scrolls are the most moddable games on the earth, so they surely recognize us, because I know that, but I meant recognize us as what we are, unskilled modders that try to alter their work with our limited resources and no QC department by our sides.

So I think that some relatively small changes in editor and the game engine would do wonders and would definitely increase the customer satisfaction, and you have to admit that one of the most attractive features of the series is their extended life cycle because of the unceasing flow of mods after their release.

So if for instance we recognize that without much effort, we can alter a game in a way that would make the life of modders and the users of the mods a bliss, then why not try to do that.

OK, I will list the current problems and try to find solutions for them.

=== === === === === === === === === === === === ===

Cluttered data folder, mixed official files with modder's add-ons, and misplaced resources:

1-Let's separate the official data folder from the mod folder:

• Editor
  
• Data
  
• Mods
  
• Config
  
• Runtime

2-Each mod is just one pack, and all its data and resources are packed within the file.

This way, we do not have ESPs, ESMs, BSAs, and so on, but just one archive format, that could contain any data and resource, in separate folders inside that zipped file if needed.

The developers could include different archive files for different types of resources and one archive to hold the equivalent of their ESM data, if they like, but those are always in one format, for instance BSA.

The official BSAs go into the data folders and the modders' BSAs go into Mods folder.

This way, a BSA can hold their data files as well as their resources, and those archives can contain a content definition XML that defines the mod's name, its version, its author's name, its genre and scope, its reference files, its data file list, and the like.

For example, if a mod's pack file is called [Tree of life.BSA], then its content can be like this:

• Content.xml
  
• Data\Tree of life.mod
  
• Data\ToL-Dangerous_Flora-Compatibility.mod
  
• Data\ToL-Twisted_Life.mod
  
• Meshes\Flora\ToL.nif
  
• Texture\Flora\ToL_Trunk.dds
  
• Texture\Flora\ToL_Leaves.dds

Then in editor, we could open a dialog box and select the reference files for our current mod, and make a list like this:

01:esvi_meshes
02:esvi_textures1
03:esvi_textures2
04:esvi_dialogs
05:esvi_events
06:esvi_menus
...
13:common_resource_library
14:p_l_creatures
15:martsmonstermod
16:random_dungeon_extension
17:advanced_combat_moves

After that when editing one of the data files in our current mod, we could double click on each reference file in the list to select the data files that we want from that mod to be master file to the current data file.

Whenever an element of a game requires a resource, it would define a number for the reference file and a name for the actual resource, like this:

Texture: [2, " \texture\clutter\vase07.dds "]

Which in the above example would mean: " esvi_textures1\textures\clutter\vase7.dds ".

When the resource number is zero then it means from the resources within the current mods's BSA file.

This way we would have no clutter around hundreds of sub-folders.

=== === === === === === === === === === === === ===

Dirty mods:

Simple concept, extensive implementation:

Just after each "OK", and "Accept" button of editor's dialog boxes, check to see if the item has actually changed from the master files or not, and if not then discard the item.

Do not include a "Recompile All" button in the released editor, or disable it by default and add the option to enable it only via the configuration file.

=== === === === === === === === === === === === ===

Conflicts:

For previous TES games, there are 3rd party programs that look at the content of several mods and their master files, and if they see that those mods have changed the same item of the master files, they combine the changes and apply those changes to the master file's item and make a new data file that contains the new item that has the combined effect of the mods in one place, and the resulting data file is loaded after the previous mods to override their changes with the combined effect.

That is the case if we know how to use such a tool to fix the problems, and then try not to place another mod that would nullify our efforts with the tool, without us knowing about that.

But this fix for the conflict problem can be completely automated by two methods:

• Restructure the items in memory in a way that would be able to accept the combined effect of the changes of several mods without conflict. This is the hard way, but the better solution.
  
• Recognize the mods in the game engine itself and add a section for them, and handle them like the following:

In the main menus before a game is loaded into the memory, we can have a menu item called by a name like: "Manage Add-ons" in PC and "Manage DLC" in console version.

In that section there can be a list of BSA files in the "Mods" folder, (The files in "Data" folder are automatically used, so there is no need for a selection list"), and you could rearrange those reference packs in the list, and then you could double click the mouse pointer on each BSA file to open a selection menu in which you could select which part of the reference pack we want to use so for instance in the previous example, we could have a menu like this:

• Resources.
  
• Tree of life.mod
  
• ToL-Dangerous_Flora-Compatibility.mod
  
• ToL-Twisted_Life.mod

And you could select the check box in front of each selection, to include the item from the reference file in the game.

If you select the item [1] then the item [0] is automatically selected, and if you select item [2] and item [3], then the two itms [0] and [1] are automatically selected as they are required for the last two items.

This is the default menu if we do not define any menu in the Content.xml file, but we could define our menu and categorize the resources in there in any way we like and pack them under different menu items to select from.

So there can be some mods that change the texture of a shield for instance and have different textures inside the same reference file, and the users could select their preferred textures from the menu to include in the game.

When the players have selected the data and resources within the reference packs as they liked, they would press an "Accept" button to return to the main menus, and at that time the engine would do an important job before entering the menus:

It checks all the modded data in the selected reference files and smartly combine them with the original master files from Bethesda, and create a combined data file in the "Runtime" folder, and after that when playing the game there is just one data file to look for in-game items, and that is in the "Runtime" folder.

In the combining process all the items that referenced their required resources as [ Reference Number , Resource Name ] are reevaluated so that their Reference Number points to the correct reference pack file.

If after that, you want to add or remove modded content from the game, you enter the "Manage Add-ons" menu and do the desired changes from that place, but if you delete a reference file from the "Mods" folder and a part of it was previously used in the game, then the next time you run the game the recombining part is automatically performed before entering the main menus.

But if the pack file that you had removed was also referenced and used by other pack files, then those packs are also disabled and the user is informed that some of the mods were disabled because their reference file was removed, and when they enter "Manage Add-ons" section they would recognize disabled mods with one glance because they would be hued red.

And if you add new reference files to the "Mods" section, they are not included in the game until you select their content in the "Manage Add-ons" section.

=== === === === === === === === === === === === ===

Current mods have (with the help of OBSE), some configuration facilities and it would be great if this feature was included in the base game, so that you could define a configuration menu in the Content.xml file and define the type of the configurable items and their type of data input in the game, and their minimum and maximum and default values.

Something like this:



When in "Manage Add-ons" section you could click on each mod and if a configuration menu is defined for the mod, then the configure button at the bottom of the page is highlighted, so that you can click on the configure button, which causes a menu to open with a list of items that you could select and each item would open a small box in the right of it that contained an input box or a slider and so on...

The configured values could be stored in INI files within "Config" folder, and be applied after the game is loaded into the memory, and if the scripting language could supply a similar save and load function for the mods to be able to save their changed values in the course of the game then it would be perfect.

=== === === === === === === === === === === === ===

OK that's all for now, and hope that some of these ideas find their way into future TES games.

Edit: corrections.

I think the editor is only going to be as good as the developers need it to be. If there was anything that needed to be changed for making the actual games (which I think there is, like all of the bugs) than it will be, but I really don't think they are going to do anything specifically for modders other than hand off the editor they used.

I also remember Todd saying that all of the tools they use are jankey anyways, and are just as complicated (needing workarounds) as the stuff modders are using.

One of the things that they need is well satisfied customers, and those suggestions can be a good step toward that direction.

As for those suggestions, they are useful for themselves as well, because they would probably release some DLCs themselves and those suggestions:

• They keep the folders in neat order.
  
• They eliminate the Mesh and Texture misplacement, so you either use a mod/DLC as a whole, or your mod/DLC is wholly disabled if it can not find its reference pack.
  
• They eliminate the dirty mod/DLC problem.
  
• They mostly eliminate the mod/DLC conflict problem, except for when they change the exact same thing in the game which would probably be on purpose.

So why not implement them, those ideas only make the end game more robust, and full proof.

Have you considered what would my solution for mod conflict mean for the game?

Increased speed and unlimited mod count, because in the end, the game engine would be using only one data file. The one in the Runtime folder, so that means speed and unlimited mod and DLC count, and this factor should be enough for them to desire to implement this suggestion.

You change the face of a character in the game and another mod changes his clothes, and another one changes his equipments, and the end result would be a combined effect of those changes, not just the changes of the last mod or DLC, and this is done without any third party application.


I know, but if those workarounds could be added or their need eliminated by a relatively small amount of effort, compared to the whole project, then I think that it is worth the effort.

Edit: corrections.