FOMM is one of the leading mod managers for FO3, yet there are relatively few mod authors that release FOMods. In an attempt to improve things, I would like to hear from mod authors regarding:

• If you have not previously released a FOMod, why did you decide not to?
  
• If you have previously released a FOMod, how was your experience?
  
• If you have previously released a FOMod, would you do it again? Why or why not?
  
• What do you believe is the biggest weakness of a FOMod?
  
• Are you familiar with Premade FOMod Packs (PFPs)? If so, what are your thoughts about them as opposed to FOMods?

I would primarily like to hear from mod authors, but I am also open to comments from others.

For some context, the reason I am now asking about FOMods is that I am gearing up for FONV, and want to get FOMM off to as best a start as I can; this includes fixing problems as seen by mod authors, not just mod users.

To me its just extra work I really wont want to deal with. When making mods you need to use the GECK, and depending on what else you need, the list of programs can get rather large. And when all is said and done, when I am about to release a mod, I am tired from all the work put into it, I frankly don't really care what format the mod is in.

Every Mod with a regular File structur can be easiely converted into a FOMOD by everyone who needs to. Also the scripting is not as diffuclt for a more complex one. I can understand the point with the extra work.

I figure more or less everyone who uses FOMM FOMods everything they download anyway, so releasing as an archive means you'll still get the main benefits of FOMods without confusing users without FOMM.

This.

Plus for those who have not done it before, the process is not necessary "intuitive", you have to play around with it until you get the knack of what files to add, etc. It's a good question honestly, I recall it being used much more as a standard with Oblivion, but that could be just observation. I think if a mod author has alot of models and textures, then making BSA archives is nice but it too has problems.

It may be the same with FNV as it was with Fo3 given that the technology and formats are not changing significantly. Heck we may be able to use our Fo3 tools on the FNV masters/plug-ins without modification of the tool!

I remember a program that packaged Oblivion mods for distribution: ESP, ESM if necessary, meshes, textures, etc.

That's probably harder with Fallout due to the way textures work, but something similar that packages in FOMOD ready format would be incredibly helpful to a lot of people.

Do you have a link to that tool?

FOMM includes a graphical FOMod builder, and I'm curious how it compares to the tool you mention.

I haven't got much in the way of released mods, but I have downloaded a hell of a lot of them.

To me, I honestly don't see the problem with dragging and dropping the necessary files into the Data folder. As long as mod makers clearly name their folders, uninstalling is a breeze.

I never really understood why they needed a special file format to do that. In games like Dragon Age, the .dazip file makes perfect sense, because Bioware didn't give us a clearly-marked downloads directory. But in Bethesda games, it's so mind-numbingly easy to install mods, that idiot-proofing it seems unneccesary.

They don't. Or they do, but the content is shared between several mods, or a resource with a different name, or they keep them in Weapons\Type, Armour\Headgear and so on rather than $Name\Weapons and $Name\Armour. Or they include extra creature meshes which have to go in the creatures folders.
And then even if all modders structured everything in the same way and never used any resources from someone with a different name, it'd still take longer to hunt down all the esps and the $Name folders in sound, voices, meshes, textures and so on than to just click "Deactivate".

Another thing.

FOMods may be clean installing and uninstalling, but its more clicks. Drag and drop is very few and easy.

Now i need to turn off my comuter before it overheats... Stupid 100+ degree weather...

I used an FOMod because it was simple to make. I didn't require a script so it was almost trivial. I think a lot of people want FOMods. The zip can be installed through FOMM, or manually by those who would rather unzip it and drag the files over themselves.

This is the one. http://straygenius.com/index.php?title=TES4Files

None of my mods were every complex enough to need it, but it certainly sounds beneficial.

Depends. Some mods have multiple options, external dependencies (ie. FOSE) or need ini edits. Writing a script makes it more likely that people install the mod correctly. But you are right. The vast majority of the mods out there do not need custom scripts. Uninstalling is more tricky, even if mod makers have named their folders, and it is a lot more work than pressing "Deactivate" in the package manager. Larger replacers can be a pain to uninstall manually.


It is pretty easy to generate a fomod from an archive if it is packaged in a sane fashion. So, when the installation is simple, there is little reason for the mod author to do explicit packaging. On the other hand, the packaging is pretty simple: Just add a description and an icon for the package manager, and you are done. Handling more complex options, such as detection of external dependencies or custom install options is a bit more tricky for the average mod author.

If possible, one could build a simple gui to generate an xml to handle the most common install options. This xml could be read by FOMM to build a simple form. I'm thinking an expansion of the format used by FWE.


Only slightly. I'm unsure what extra functionality they bring to the table, except from being able to be distributed independently of the mod.

That's what I do. Every mod I download I make into a fomod, not only for a more organised data folder, but nine times out of ten modders can't pack an archive correctly anyway so I'm used to re-packing it then making a fomod. Doesn't matter if it's just an esp it gets made into a fomod. Oh, but those with BSA's get extracted and re-packaged, too. My BSA Archive list in my Fallout.ini is at the maximum character limit already, so no more.
My mods released aren't fomods. I leave it up to the downloader.

Does the name trick not work with Fallout 3? That made the Archive list unnecessary in Oblivion.

Most archives that are simple in structure can be read and installed by BAIN without repackaging.

Name trick? Unneccessary archive list? That'd be handy
Well, here's how I've got my list, trimmed and re-done. All DLC's repackaged in shorter named BSA archives (except for the orignal Fallout ones) - AII!.bsa, Fallout - Textures.bsa, Fallout - Meshes.bsa, Fallout - Voices.bsa, Fallout - Sound.bsa, Fallout - MenuVoices.bsa, Fallout - Misc.bsa, DLC1.bsa, DLC2.bsa, DLC3.bsa, DLC4.bsa, DLC5.bsa, UF3P.bsa
Unfortunately when I toggle Archive Invalidation it changes AII!.bsa back to its really long name. Although I've only to switch them around again.
Should I be removing the originals from the Data folder? FO3Edit likes to load the originals as well as the newly named ones making opening the program take that little bit longer. I wasn't sure, so left them all in there.

But, I'm open to suggestions on making that list smaller, or doing away with it altogether

Are there changes that could be made that would make FOMod-ing worth your while? Changes either to make making FOMods easier, or to increase the value they add to your mod, I mean. Or is it that FOMod-ing will always be too much work?


FOMM already natively supports an XML file. It basically is the FWE script, but much expanded in functionality. I have not yet made a GUI to generate the XML, however. If you are interested in what I've done, virtually all of the mods I have made http://www.fallout3nexus.com/downloads/file.php?id=11200 for use an XML file instead of a C# script.


One of the problems that I see with FOMods is that any change to the mod requires a re-upload of the FOMod. So, for example in the case of FWE or any other large mod, you release version 7, but then the next day find a bug and release version 7.1. Your choices are to re-upload the entire several hundred MB FOMod, or simply upload a few-KB hotfix. Uploading the entire FOMod is user friendly but very time intensive. Uploading the hotfix sort-of breaks the FOMod paradigm, but is easy and quick. Which are you more likely to do? Which makes more sense? Most will just upload the hotfix; to me, this makes sense, as under these conditions managing the FOMod is cumbersome. Unfortunately, a mod doesn't have to be several hundred MBs for this to hold true.

A PFP is a set of instructions on how to combine and turn given files (usually plain old archives) into a FOMod. They themselves are a simple archive, containing a few well-known files. As a PFP only contains instructions and metadata about a mod, they are generally very small (only a few KB). PFPs allow you to upload instructions on how to build a FOMod separately form the mod data itself. So, in the case of our theorectical FWE, you upload the several-hundred MB version 7.0 file without any FOMod related info, and a PFP. As PFPs are generally only a few KB in size (very small), this isn't very burdensome. This way of maintaining a mod has a few advantages:

• The main data file is not tailored to FOMM, so users of other mod managers (or no mod managers) don't have to deal with extraneous files.
  
• When you find the bug and want to upload the kew-KB hotfix to 7.1, you can do so. Then, instead of having to re-upload a huge FOMod, you just need to re-upload a small PFP, modified to incorporate the new hotfix. Users can then download the hotfix and the updated PFP, and generate a new, updated, FOMod.

FOMM is able to take the vast majority of PFPs, and, along with the relavant data files, automatically generate a FOMod: the user just has to tell FOMM where the PFP is, and where the data files are. If a user is missing some data files, FOMM will even give them a message telling them which files are missing, and where they can be downloaded.

Further, as PFPs are able to combine several files together to make a FOMod, this can simplify distribution of large mods. A huge mod can be broken into smaller files to facilitate distribution (for example, on the Nexus with it's 300MB per file limit), and the PFP can automatically combine them all into a single FOMod.

Those are the highlights, if you will, of PFPs.


The same is true of FOMM. FOMM may decide to repack the archive, but it doesn't require any user interaction: the user just tells FOMM to install the simple archive.

I think for the mod-user audience that the FOMM is a Great tool. I used OBMM for everything before I started modding Bethesda-ware, and use FOMM just as religiously as a modder now. In both cases the problem I had with running big Mod lists was not that FOmods didn't work and nor were downloading updates that big a deal. The problem was the Non-FOmods; the fact that I had to create them for all the mods Not distributed that way. I did it because I found it Much faster to rebuild my Fallout3 directory when I needed to, and helped me deal with some crash issues and made turning them on/off extremely simple.

One way in which FOMM could be made The default method of installing/managing mods is if FOMM had options for dealing with Non-FOmods. For example, say I download 5 mods for my rig and one of them is not a FOmod but comes as a standard Zip extractor into the Fallout3 or Data directory. FOMM could have a button perhaps called "Install non-FOmod" that would open a file explorer (perhaps into the Downloads directory as default) so the user could select it. FOMM would then open the Zip, check for the ESP/ESM and Data/ files/directories, make a determination of where the files would be installed and automatically build a FOmod striaght-away. Then FOMM would simply activate it's own new FOmod and the mod-user does _nothing_ but click Install, then Activate and finally Launch - as it should be IMHO. You could offer a template .ini file to the community as a resource that defines the base installation directory for that mod and maybe a few other details (just like your PFP but even simpler, a starting point from which FOMM would build the FOmod). Mod authors could include that .ini file and let FOMM do the rest - making it easier for the modders as well. This would make FOMM usable for almost All types of mods, and the added convenience would I think create more stability in the resulting mod rig.

Another major problem for modders is conflicts and mod-order, probably the single most dreaded issue with Fallout3 from my perspective. BOSS is one of the God-sent gifts IMHO to the community in this problem; a common way for modders to get their mods put in the right place (or most probable right-place) to prevent conflicts and smoothen the experience for modders. I think a major way FOMM would benefit itself and the community is of these two tools were digitally linked and made to work together. Further-more, I think FOMM would benefit if it had a button such as, "Update BOSS list", that would automatically download the latest masterfile from Nexus and run BOSS to re-order the list inside FOMM.

Options could make the overall process even more "streamlined" (pardon the pun) for the mod-users, but by adding the ability to handle Non-FOmods gracefully/easily and the ability to use BOSS to help correct mod-orders would make FOMM as close to a push-button solution as one would find. There will still be conflicts to deal with, merged/bashed patches that will be necessary, I don't think we will ever escape that need - but this would get FOMM closer to the user expectation than it is today.

Food for thought,

Miax

One area to consider is that users may still desire to extract a FOMOD or OMOD in order to clean the plugins involved.

I used OBMM before BAIN in Oblivion and FOMM before Wrye Flash BAIN in Fallout 3, so I'm very used to this process.

With Oblivion that is furthered by optimizing meshes. So as long as plugins are released that need to be cleaned I will repackage, and this is true for simple archives that I install with BAIN as well.

Fair point, but surely packaging your mods as FOMODs or FOMOD ready archives lead to less post-Relz support for all of the people who don't install the mod correctly?


Exactly. That is why in Oblivion I liked to use OMOD ready relases, rather than dowloading ready-made OMODs. I have no doubt that this preference won't change now I've stated adding mods to FO3. Finding that folder marked "fomod" in a download always makes me a happy man.

This is what we(the FWE team) experienced regarding fomods:

We released both a fomod ready archive and a premade .fomod file(which we pointed out was the recommended version). What happened then is that a lot of people(who of course don't read the readme) had trouble installing the .fomod version(also because a lot of people have never used to the package manager).

What really adds to the problem is that you cannot upload .fomod files to fo3nexus. That's a terrible oversight(from Nexus not FOMM), which forced us to pack the .fomod file into a 7z file. Alot of people then tried to install the 7z file via the package manager, without extracting the .fomod file first. Of course that didn't work and led to lots of confusion.
With 5.03 we decided to remove the entire .fomod package and only offered the FOMOD ready 7z version. That turned out to be the best solution overall.

Does this generate an updated FOMOD from an existing FOMOD plus the PFP plus the hotfix archive, or does it require an original downloaded archive plus the PFP plus the hotfix archive?

Basically, if FWE released v7.0 as a FOMOD ready archive, which I made into a FOMOD and erased the original archive from my hard drive, could I still use a PFP and hotfix file or would I have to redownload the original archive?

I'd like to thank Kaburke for the hard work he's done improving FOMM. This is an important thread to draw attention to the FOMOD creation tool, which is now so easy to use no-one should release a mod without a FOMOD folder.

I will also strongly second Kai's comments regarding FOMOD vs. FOMOD-ready. I erred badly in distributing my first FOMODs as genuine FOMODs wrapped in a NEXUS approved .7z file. Result was a never ending stream of "where the esm" questions. FOMOD-ready structure definitely reduces support issues.

I'm not sold on the utility of pre-made fomod files as a solution for patches. The level of cognitive effort required to drag and drop files between folders is even higher than that required to just dump mod files into the data directory and be done with it. And we all know how large a challenge that is for some.

FOMM does that now. Click "Add FOMod," select the zip/7z/whatever and FOMM does the rest. In a few moments you'll have a FOMod in your list to Activate. This is something several people have asked for, and not realized already exists, so perhaps a change in nomenclature is in order.


FOMM actually does integrate BOSS. The "Auto Sort" button uses the BOSS masterlist. The "Check for updates" menu option downloads the newest masterlist without further user interaction. Basically, FOMM includes (much of) BOSS's functionality, using BOSS's data. Again, this is a much-requested feature that many don't realize already exists.

Thanks for your feedback.


I'm afraid I'm not following. Do you mean you like to clean the ESPs using FO3Edit (or some similar)? Are you suggesting that this is something FOMM should/could do automatically?



This brings up a nuance that I think is lost to many, likely as a result of everyone's experience with OBMM. With OBMM an OMOD was a specific file format: any archive/mod had to be precisely structured to be an OMOD. This caused a lot of problems, hence the concept of an "OMOD-ready" archive that could be easily converted into an OMOD if desired, but could be treated like a regular archive for use with Wrye's tools and the like. With FOMM, Timeslip abandoned that proprietary route, and instead a FOMod is nothing more than an archive whose extension has been changed to .fomod. That's it. As of the 0.12.x series of FOMM, a FOMod is a Zip file or a 7z file or z tar file or any type of compressed archive, with a .fomod extension. There is absolutely nothing special about a FOMod. Optionally, FOMods can contain a fomod folder that can contain information about the mod (website, screenshot, install script), but it is completely optional. The only reason, in fact, that a custom extension is even used, is to allow the association between FOMods and FOMM, so that a user can double-click a FOMod to install it, without having to know where to copy it manually. Hence my response to the first remark in this post: FOMM can already add "non-FOMod" archives, as there is no such thing as a "non-FOMod" archive. If it is an archive, it's a FOMod.

Currently, FOMM will still often repack an archive that's added to FOMM, but this is for performance reasons (mainly due to the fact that extracting single files from a 7z archive is very very slow).


This is a valid point, I think. My http://www.fallout3nexus.com/downloads/file.php?id=11200 is doing fairly well, without many complaints, but I have often wondered how many people are actually using it. I have a feeling it my be a fairly small number, and likely not the sort of people who are easily confused.

My goal with FOMM is to eventually have a tool that makes post-release install support obselete. I would like something that is easy for users to install, but is not cumbersome for authors to maintain (as if it is cumbersome to maintain, it won't be done).


A good point. A PFP doesn't care: it will do what you tell it. However, in this scenario, given how PFPs work right now, there would have to be a PFP that requires the original+hotfix+PFP, and a separate PFP that would use FOMod+hotfix+PFP. While maintaining two PFPs wouldn't be too terrible, it is worse than one, and two of anything often confuses users. It would, however, be fairly trivial for me to "fix" PFPs so only one would be required.