Modders plea with BGS.
Those little touches mean a lot.

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

Elder scrolls games are masterpieces of game design and mod-ability. 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 its potential mod-ability, I was doubly amazed, and did not know what to think of this.

I had long thought about games with such potential in mod-ability 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, and I fear that if Skyrim is mod-able, which probably is, this it might have the same problems, so I decided to write about a way to reduce the potential problems between mods.

I know that it is probably too late for most of these suggestions, but who knows, and when needed one sticks to the smallest of hopes, and here it goes:

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

First of all, I think that BGS 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 mod-able games on the planet, so they surely recognize us, because I know that, but I meant recognize us as what we are, unskilled mortal 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 realize 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, and if one section does not interest you please skip to the next part and it might be more interesting.

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

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, which 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:skyrim_meshes
02:skyrim_textures1
03:skyrim_textures2
04:skyrim_dialogs
05:skyrim_events
06:skyrim_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: " skyrim_textures1\textures\clutter\vase7.dds ".

When the resource number is zero then it means from the resources within the current mod'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, and the changes.

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 [2] then the item [1] is automatically selected, and if you select item [3] and item [4], then the two items [1] and [2] 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 texture themes inside the same reference file, and the users could select their preferred texture theme 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 can check all the modded data in the selected reference files and smartly combine them with the original master files from BGS, 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.

After that, if 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.

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

The final result of the above suggestions is something like this:

• 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 cannot 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 and this has another really interesting side effect: 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.

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.

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

Script suggestions:

I have some ideas about character development in TES games, which I have described in http://www.gamesas.com/index.php?/topic/1144150-character-development-and-you thread, which I do not have a hope to see in Skyrim, but maybe in the next TES game?

But if I had some arsenal, in scripting language, I could try to do it myself, and I have some experience in character development mods.

First of all, I'm really hopeful to see the http://www.gamesas.com/index.php?/topic/1107940-perks-they-can-make-each-play-through-a-unique-experience with at least the functionality and versatility that they had in Fallout 3, so I do not have anything to say.

1> In Oblivion we could change the skill advancement rate via GMST values, but it would be real helpful, if we could change them in the run time with a script function.

2> I know it is too much to ask, but if we could have array variables, and a way to iterate through array items in a single frame of script, it would be really great. A one dimensional array would suffice to make our scripting lives a lot easier.

3> A facility to save and load some quest variables via scripting language, in an external text file.

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

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

Dear BGS fans and TES modders, please add your ideas to mine hoping that maybe some of them catch the eyes of a BGS developer.

Edit: some stylizing.

I'd love it if when we type in who's mod it is, nobody else could open it up with the CS and change it. While it normally wouldn't be an issue, you know there's the possibility for people out there to want to be popular so they steal everybody else's mods and place their name on it. :shrug:

Good suggestions, might I add. It would help people not overwrite things they don't mean to.

your request is duely noted but their not changing a thing about it, they have already had this for a while they cant just changes 4 years of work in 1 year and still finish the game, its already done

Good suggestions, so modders could lock parts of their mods that they did not want to permit others to change, including the credits part. :thumbsup:

U don't need this. The modding community should stay open source. If u want to protect against this just stay active with your development. People will know wichita version is the real one. It's only when your not open and private that ripping will be a real problem.

Well, this seems reasonable, and the more I think about this, the less likely it seems to be developed by BGS.

Yeah I know, I just get kinda anxious sometimes.


Mhm, doesn't really matter all that much when you get down to it. I just thought of the ability everybody has to do something like that the other day,

its not about changing 4 years of work, its about arranging 4 years of work into a manageable system.

While I'm going to have to put off reading the whole thing for when I can pay better attention, a lot of that would certainly help me not screw things up so much.

:thumbsup: :rock:

As a modder I understand what you'e getting at but honestly I wouldn't ask BGS to go the effort in any area the community can otherwise manage. I'd rather them simply allow us bit more latitude in their 'hard' code.

I do not understand.

Do you suggest the community change the source of the game engine, and data structure, and convert all the old data files into a new structure and ask the community modders and users to emigrate to the new file formats and the lot?

Edit: This would be impossible for the community to manage, and I know it is a bit too late to ask BGS to do, but as I have written in the OP, one can just stick to the slimmest of hopes.

My most-requested feature is to allow mods to define lists that do not replace existing lists, but modify them.

Sample psuedo-spawn leveled list:

CoastalIslandLL0:
1 BabySeal
1 Horker
3 Seal
5 Penguin
7 Walrus
11 PolarBear

AppendList HMACreaturesCoastalA
BaseList=CoastalIslandLL0
5 Riekling
13 SnowWolf
18 RabidMoose

DeleteList HMACreaturesCoastalD
BaseList=CoastalIslandLL0
5 Penguin

This setup would add Rieklings, Snow wolves, and Rabid Moose to the possible spawns. And we all know there aren't penguins in Skyrim, so we removed the possibility of penguins spawning.

Next, another mod comes out (The Sheogorath Christmas Special), and it wants to add creatures, too.

it could overwrite the base list...
or it can simply ADD Deranged Snowmen, Toymaker Falmer, Felldew Reindeer, and the elusive Santa Claws spawns to the existing list by the same mechanism.

Could be wrong, but that sounds like an Ogrim's ass-load of work.

No. I'm talking about relaxing contraints on things that could be expanded like: number of equipment slots, size of bounding boxes, use of special anim groups, etc. The 'hard coded' walls we ran into in OB.

Community has been able to deal with file stuctures, mod conflicts, and stuff.

Quite good idea, but they have changed the random selection method between Oblivion and FO3, so we do not know if they still use those random lists or not.


I was stressing that it was impossible for the community, but for the actual developers...

They already use BSA files, that can contain all forms of resource inside them, except for actual ESP and ESM data files, so I suggested that they place those files inside the BSA files and have only one type of data file in the whole, BSA.

Then instead of referencing other ESPs and ESMs as master files, they reference other BSA's as reference files, and select master files from those reference files.

And also point to resource files from inside those reference files.

This should not be too much for the ones that have access to the source codes of the game.

Except that they might not want to add the new task to the heap when they are so much into the development of the game.


That's always a good suggestion, IMHO, but like my suggestions, we can only wait, cross fingered, with just a tiny spark of hope.


Deciphering, understanding, and using, not altering the structure.

I know.



Probably not.

I hope that while designing dialogs, if modders do not supply voice overs for text lines, they can define the amount of seconds that the dialog would remain on screen before fading away.

The whole issue of data structures falls under the heading of 'how it was designed and for what'. Since we know that gamesas is using a inhouse engine this go around, using Morrowind/Oblivion/Gamebyro data structure requirements is kind of dubious. Compare that to Daggerfall's data structure, and you get serious differences, since that was XnGine, also an inhouse designed engine. Unless BGS actually -bought- the Gamebyro source and totally reworked it, then the past two games will most likely have bloody little similarity to Skyrim, as they had to structure their data to conform to what the renderer demanded, and built the gameplay part of the engine to deal with that, and the console neccessities.

I would want to see exactly what their data types and structures are before even attempting a wish list. They could have gone the Doom 3 path, and have low poly geometry with texture/shader/lighting trickery to make the environments live. They could have very low weight meshes and be using displacement maps or normal maps to add runtime detail. What the data is will determine what the structure has to be; and the limited memory pool and horsepower of the supported consoles will also limit and shape things in ways that could adversely affect PC moddablility.

My suggestion is to wait and see exactly what we get regarding a construction set, and how the data is arranged, for Skyrim. That would effectively be version 1.0 as far as real world modding goes. And if this is an engine gamesas is going to use for multiple games, which is my guess, they will most likely be very quietly receptive to how things work, and the consistency of praise or trouble feature X or lack of feature Y causes. The Unreal editor for Unreal 1 was a royal beeotch to use....and Tim Sweeney and the dev crew listened to the modders, and applied a lot of the changes to later versions of UnrealEd. Bethesda will likely do the same, once real modders are using it, as it is mods that give a game its longevity with the PC crowd.

As far as editing wishes are concerned, the ability to attach a metadata field to existing figures, level sections, dungeon modules, etc, would make life =so= easy. That way you could attach simple tags to anything, and create simple apps or scripts that take advantage of them (make meta tags for the dungeon modules that describe type, openings, and unit size of openings, and general unit size of module, and you have all the data you'd need to create a simple random dungeon generator. You'd still have to bo the lights, traps, entities, etc in the official editor, but for those who yearn for those Daggerfall sized dungeons, or who want some variety, it would speed the process considerably).

They're not going to make the game cater to modders... At least I hope not. Sure I like to mod, but I can't anymore, my PC doesn't have the right software, and when I try to download the right software it won't let me :brokencomputer: . I seriously hope they make the game with PLAYING the game in mind rather than MODDING the game. I'd rather they try and cram as much armor/weapon/quest/faction/landscape/etc. variety in the game rather than trying to make it easy for modders to change.

OK I won't pretend I understand most of what you said...

BUT I understand that since ES games are mod-friendly, they should at least have option to make "cleaner" mods, God knows how many uninstalls I did after slapping 60+ mods onto oblivion , in the end I made them work with little to no glitches but still it was a lot of work.

I fully support what ever the modders need, and I think Bethesda will be wise to accommodate them, since they sometimes fix the silly mistakes they do, for free and with good spirit

I know it is too soon to know about their probable changes to the engine and the data structure, and a bit too late to suggest about editing feature, but I hope that the have listened to modders before and might even consider a change that helps the modders cope with each other and the game engine better.

As you said about the unreal engine, one can only hope for the best, and those changes would help their own designers as well, and are not only for modders benefit.

If several designers are developing different aspects of a game, then a clean cut format would help them cope with each other better.


Yes!

This is one of my dreams about a game engine, and if they manage to pull this off with this, or their next game, it would be the happiest day of my gaming life.

I have suggested something like this in my old posts in the other forum page, but I did not go into much detail there, as I did not have much hope of its being noticed, and even less hope of its getting implemented.


If they make a game, mod-friendly, the make the game design friendly, which makes it easier for them to develop.

And they make better profits on PC platform, because mods is are clean and do not conflict with each other, and easy to develop, can attract a lot of customers to the genre.

Most of what is being suggested isabout making the developer tools developer friendly. Not the game itself per say. Modding TES games is pretty similar to how Bethesda themselves created the content for the game.

At the end of the day it takes nothing but forethought when programing the in game systems to be more versatile than what the game ships with.

They will be constantly messing with each feature during development, in some cases simply adding a higher number to an array would be enough. I would have done that anyway to save a designer coming back to me later saying, dude I need an extra animation slot for this weapon class...

each component should be programed to allow designers as much freedom as possible. Just in case

Exactly! :goodjob:

With computer horse power and memories increasing on daily basis, it would not be a problem to always supply a bit overhead to what resources that we think enough for unknown future requirements.

Mostly pays off later.

The problem with a lot of what you ask is that it is designed for modders, not the developers. Because when BGS makes the game they have just one .esm, and they don't make DLCs that are hugely conflicting, or really needs any of the features asked for. So it won't really make development easier for them, will just add a bunch of extra time adding features that they probably won't even use (especially at this stage of the development, when they have done most of the game and are moving onto the dialogue and voice recording.)

I'm afraid I think AliTheLord is right. Most of the problems the original poster raises are problems caused by having a lot of people working in their own way on their own projects with no consultation.

Bethesda are a development team. They will have an agreed way of working, the different groups will be working on assigned areas/assets, they'll be consulting with each other, and they'll almost certainly be using third-party file-version archiving software.

Bear in mind that Bethesda don't license their game engines to other developers. That means they have no direct financial incentive to make the tools generally applicable or user friendly. They release (possibly cleaned up) the tools that are designed only to do what Bethesda use them for. I'd love to see modding tools that avoid the worst problems faced by modders, but I really don't see that happening .