Proposal for the Standardization of Mod Packaging

[Circuitous]

Okay, I like where this is going now.

 

I've taken the liberty of making three example mods (using Bingo's Bongos, of course). All the files are empty dummies, I'm only using them for display purposes.

 

The first using my original outline,

 

the second using LHammond's modifications,

 

and the third using kapro's outline.

 

I think I prefer kapro's. It sets up well for mod managers and is also easy to use when doing manual installations.

 

Which do you prefer?

[Sithrain]

Personally I prefer the third format, since it keeps readmes and screenshots out of the way but organized as I'd prefer them.

[kapro]

Woot! Someone likes my idea! Well, anyways, if we can all agree on one of the three formats, I'll write up an article and post it on Fallout 3 Nexus.

[myrmaad]

Woot! Someone likes my idea! Well, anyways, if we can all agree on one of the three formats, I'll write up an article and post it on Fallout 3 Nexus.

 

 

Sounds like a good plan to me, I prefer the third example, as well, works for both OMODs and Manual installations. I do use OMODs at times, but actually prefer to manage my own installations for the majority of the time. If LHammonds gives his blessing on structure example 3, you'll be good to go I think.

[kapro]

Article posted: http://www.fallout3nexus.com/articles/article.php?id=18

[nosisab]

This thread have good intentions but the process is being done backward. The first thing, this can't be easily changed, is keep in mind the best is the way the engine will find the mod and locate every file it needs. This requires deep understanding of the way the engine works. People from OBMM is working just now at doing the FOMM and they have experience with it already. Second, the whichever mod manager will be and I think FOMM is a good candidate if not the only, need a way to organize things the simpler and human readable way possible.

 

Nowadays, in the Oblivion scene there is Wryes bash with a proposal too, that intend to go longer than simple naming conventions, but take into account things like groups, priority of loading, etc too.

 

The Standardization process is not that simple and I will not go so deep to propose the model used by ISO and similar organizations goes (years, under a commission charged to analyze propositions and release RFCs, etc), it would take too much time, maybe, before mods achieve a volume of mess enough to hinder standardization attempts 'too late'.

 

This is very complex to be followed by casual modders, one may say, and he will be right. Thus is where the Utilities come to take over that task, acting as a check list. Leaving to the modder the work to answer it's standardized questions and concerning with the mod itself.

 

Yet, what I personally would like to see was FOMM and Wryes teams and anyone else that can and will make something for real, present here, with propositions and Request For Comments, to guide and help them to filter the good ideas (Edit: dubious this will help). For now, with Fallout 3 things are yet being disclosed, not even a CS is seen in the horizon... well... Modding fallout 3 is yet in a very incipient stage.

 

Edit: as the way each one like to store their mods, it's another history.

PS: Normally mods that come inside a modname folder is because they can't be just unpacked into the game tree, most of times because they have choices to be made.

[DonReba]

This thread have good intentions but the process is being done backward. The first thing, this can't be easily changed, is keep in mind the best is the way the engine will find the mod and locate every file it needs. This requires deep understand of the way the engine works.

It does not really require deep understanding. There are utilities like Process Monitor that show all file accesses a program attempts to make. Just run the game and see which files (existing or not) it tries to open.

 

In the STALKER community anarchy works great. The game expects a single "gamedata" folder containing modified files. The mod manager takes care of merging mods and organizing information like readmes.

[nosisab]

This thread have good intentions but the process is being done backward. The first thing, this can't be easily changed, is keep in mind the best is the way the engine will find the mod and locate every file it needs. This requires deep understand of the way the engine works.

It does not really require deep understanding. There are utilities like Process Monitor that show all file accesses a program attempts to make. Just run the game and see which files (existing or not) it tries to open.

 

In the STALKER community anarchy works great. The game expects a single "gamedata" folder containing modified files. The mod manager takes care of merging mods and organizing information like readmes.

I was thinking about the "how" conflicts are managed, archive invalidation done, and I'm assuming things are near enough to Oblivion ways...

This by far is more critical than may seems. Things all wannabe modders should understand at least a bit more than end users.

 

Ideally the end user should have just do unpack the mod unto the game root folder, not even into some data folder. But world isn't ideal, and sometimes we need to deactivate or remove (uninstall) mods.

 

I'm favorable to keeping easy to locate files, and keeping them into easy to identify folders is good. Should the end user ever need to deal with "handle it step by step"... Indeed keeping files under isolated folders may help avoiding conflicts, or worsening things if they refers to the same object... under the 'bug tracking' point of view.

 

PS: sorry I'm almost sleeping in the chair, shall rest for a while. This thread may be enlightening to some people if it evolves well and above the simple organization side and go toward 'standardization' as the OP proposed.

[LHammonds]

Well that was quick and didn't really get much feedback from the community before stamping it as a done deal. I didn't even get a chance to reply and explain that the "LHammonds Example" by Circuitous was done incorrectly.

 

- Grouping assets is a good idea but I think they need to reside under the appropriate sub-folder. Such as Meshes\Weapons\MyMod\ and NOT Meshes\MyMod but this is my personal opinion which can be debated but my reasoning is to match the design of the game architecture as much as possible rather than going off the beaten track. Keep in mind that some content HAS TO be placed under certain sub-folders before the game will work correctly. Textures\Menus is just one example.

- It is NEVER a good idea to include the mod's version number as part of the plugin name. NEVER. Well, there might be a need but 99.99% of mods should not include a version number and many have learned that lesson the hard way.

- The only "mention" of a version number should be inside the readme file, the description and the archive filename itself. The other filenames should not contain version numbers. If screenshots need to be noted as to which version it depicts, it should be part of the image.

 

Author name as part of the mod name? Really? Some individuals do that for recognition and branding but I do not think it would be wise to make it a "standard." What about mods that involved several authors / contributers? Who gets their name on the file name? How long can it get before it becomes ridiculous?

 

I will never support a method where people are advised to extract an archive to the game's program directory where the .EXE files live. The "Data" folder is there for a reason which is to separate content from the game engine. If it becomes "acceptable" to package and extract mods to the "Fallout3" folder, do not be surprised if you see .esp plugins, readmes, screenshots, etc. showing up beside Fallout3.exe as well as the games "readme.txt" being overwritten by a mod file readme. This would be a poor mistake.

 

The standard should really be driven by tools as it is a bit much for every-day modders to figure out the 200 steps to standards compliance.

 

That is why I have promoted things such as creating OMOD-Ready archives where the mods have already been added to a mod delivery tool and is the output of such a tool in a common and expected delivery format (how files are arranged in the mod).

 

Other helpful tools such as TES4Files was brilliant and a major time-saver to package your mod files (if you had more than just a plugin) and ensured that you consistently produce a high-quality archive by not "missing" files that should have been included in the archive. Here is a tutorial I wrote on how to prep mod files using TES4Files. I hope a similar tool will be created for FO3. NOTE: The TES4Files author wanted the "Data" folder included in the distribution archive but my tutorial steps around it. I've already stated why mods should not be made to extract to the game folder.

 

The "Mod Info" folder would also need to be discussed much further in greater detail. I am not sure having a sub-folder that contains a space is a good idea for several reasons. NOBODY is releasing mods in this fashion and like I said before, if it is not being done this way, there needs to be a VERY strong case for why it should be done. A prettier file listing is NOT a valid argument to harass authors into re-packaging their mods to fit that standard. If a mod manager can "pick up" files (readme / screenshots) in the archive regardless of where they are located and handle them appropriately, this is a moot point. It would be even better if said manager could then export / package the archive for distribution and places those files in a truly standard location.

 

Until you fellas get actual feedback from big names such as Timeslip, Wyre, MentalElf and others, this is just another "talk" page that has no capability of enforcing a policy...let alone call it a standard.

 

For a standard to work, it needs to be widely accepted and supported. Posting an article and calling it a standard isn't going to make this happen and might actually work against it if done prematurely.

 

LHammonds

[kapro]

LHammonds is right. I shouldn't have posted that without waiting longer. For now, it's hidden from the public until we get more input and work out the kinks as well as get the go ahead from the mod manager programmers, other mod developers, etcetera.