Like I explained above, the main problem is that you cannot upload files with the .fomod extension to nexus. So if you actually do want to upload an actual .fomod file, you need to pack it into an extra archive with a proper extension. And that is what leads to so much confusion among the playerbase.

It's simpler to only upload a 7z file containing the mod and let the player handle the archive however he wants. If nexus allowed the upload of files with the .fomod extension this would be an entirely different story. I think this should answer your question as to why there aren't more mods using the .fomod extension, it's simply uneconomic.

When I referred to cleaning - yes I meant with FO3edit and not that FOMM should do it.

As long as a plugins needs to be cleaned - I will be tearing it apart and cleaning then repackaging - and that is true whether as a FOMOD or with BAIN.

In fact in these cases then if it is already a FOMOD it is actually more of a hassle to extract it then clean then repackage, so by that point it becomes a BAIN package.

That is why I requested he extract to folder option all those months ago.

I guess my question should have been clearer, then, as I was somewhat ambiguous. As any archive is already a FOMod without any further action, it doesn't matter that the files uploaded to the Nexus don't have a .fomod extension. The use case for the end user is the same: click "Add FOMod" and select the file (regardless of whether or not it is a .fomod or a .zip or a .7z or whatever).

My question should have been perhaps along the lines of:

• Why do so few mod archives contain a fomod folder?
  
• Given that mods often release hotfixes or patches as separate files, what could be done to simplify incorporating those hotfixes into the main archive?

The main reason for Question 2 is that, in my experience, hotfixes confuse end users. They often don't know which files they should download, or how they should install them, or in what order they should be installed.

The difference between FOMOD and FOMOD-ready IS just the file extension, but it is significant. If a .FOMOD is distributed ( in a wrapper), FOMM does not recognize the zip within a zip format and tries to install the .FOMOD file. If distributed as a "FOMOD-ready" file, the whole concept of file association with FOMM is lost.

Regarding upgrades, is it possible for FOMODs to be specifically tagged as hotfixs that FOMM can insert into existing FOMOD packages already in the mods folder?

I have multiple data directories going so that I can keep my mods compatible with other mods that don't work so well together (I also like being able to try more load order configurations). But that means I never use FOMOD to install anything - it would add several steps when transferring from one load order to another (as it is all I have to do is rename the data directories and re-import the right load order). I'll probably never FOMOD any of my mods, because its not something I use.

Am I understanding that you would like to be able to distribute files with the .fomod extension?


Something of that nature is certainly possible. I will think about what it involves. Would this be something that would help mod authors?

Ideally yes, but until Nexus allows .FOMOD uploads, it is pointless. FOMOD folder remains the best distribution model. If FOMM could recognize the FOMOD within a wrapper situation and handle it properly, it would add a layer of fault tolerance for modders experimenting with the tool. As we all have learning curves to climb, so the more forgiving, the better.

Well is the current workaround for Nexus just to put the FOMOD into a 7zip - that should be to hard to get FOMM to see the FOMOD in an 7zip should it?

Relating back to what Imp said above about multiple data folders - with the release of the total conversion for Oblivion called Nehrim, we have been slowly porting tools and mods to that TC - we have learned that with OBMM just installing it into the alternate data folder that Nehrim creates that it runs as a completely separate and discreet program than the normal OBMM in the the Oblivion/data folder.

Would this be true for FOMM as well if a TC were made or as Imp is attempting - alternate Data folders?

With respect to FOMM recognizing FOMods inside an archive, that should not be too difficult.


It should, yes. However, it's a good thing this has been mentioned, as I am going to be changing how FOMM figures out where it is. Now that I know multiple Data folders is important, I'll remember not to inadvertantly kill the ability off.

It took me a few readthroughs to figure out exactly what you were saying, but having a separate install of FOMM for each data directory would save me some time, as well the occasional headache from forgetting to save my load order before switching directories, and would allow me to take advantage of nearly all FOMODs.

Perhaps its cus my mods aren't really big, but really I don't care. I don't understand how it could be hard to plop in a meshes and textures folder and an esp. Drag and drop and override when necessary, check off the ESP and the mod is installed.

Personally I prefer having mods I download NOT in FOMod format because I do a lot of tinkering with the files, so having them packaged up like that is really annoying for me. As such, I also reverse this. Since I mod for me and release because I can, if someone wants an FOMod, then that is up to the them and not my responsibility. This is a hobby and not an obligations, so if I don't feel like doing something, I wont.

That's fair. I very much appreciate your feedback.

Well there is more to it than that.

What plugins are active is saved in your plugins.txt file in your saves folder. If you swap save game profiles (easy to do with Wrye Flash) then it is just making sure that it all matches up. I find Bash invaluable for this kind of thing.

The http://www.gamesas.com/index.php?/topic/1116792-rel-inizer/ for Oblivion show much promise but I can only get the reassigning ini files to work and not the reassigning plugins.txt. and with the Nehrim TC they are pondering how to further separate their game from the main Oblivion game.

Edit: Added another paragraph

I distribute all my mods as fomod-ready archives (ie, with a fomod folder) because Fo3Nexus doesn't allow *.fomod's. It's so easy to make one that there really is no excuse not to, I'd just end up making it for myself anyway.

My UNAR mod actually has a basic script to resolve compatibility with Vanilla/FWE too.

• I think it's because for simpler mods it's not actually necessary, since FOMM will install them properly anyway. You miss out on the additional info in the package manager, but other than that it's usually not a problem.
  
• Not sure, but allowing modders to mark some fomods as a hotfix file to a specific mod, and then updating the original and/or installing the hotfix automatically might be an idea.

That's what I thought, too, but I get a lot of requests for PFPs for mods that are as simple as it gets. I'm not sure if it's because people like the version checker, or just like to see metadata, but the lack of fomod folders seems to bug people.


Earcache42 mentioned the same thing. I'm going to add that to the next version.

my reason for not trying to turn my mod into an FOMod or a PFP is simple, I'm human, I make mistakes, I want to be able to fix those mistakes without spending a lot of time on the back end. I would love to pack my mod up into a proper, universally accepted format but, as I see things, the player should turn my work into a FOMod. I want to have the freedom to change my mod, update it and support it, without a lot of back end work.

Is there anything you see that could be done to reduce the "back end work" to a reasonable level? Or is any amount of additional work not worth the return, from your point of view?

kaburke,

A thought on that...

FOMM is already an Awesome tool for any Fo3 player that wants to run mods, it's absolutely essential and does quite well IMHO. It could use a little more marketing of it's features at Best.

But taking CevSteel's example, the situation is different for mod authors that have a different set of requirements than the users, and an ease-of-use idea that might help:

Create a "Repackage" feature in FOMM that a modder can, by clicking a single button, have FOMM repackage a mod based on known directories, and 100% prepare it for upload to Nexus. That way when I was done working on my mod I could launch FOMM, click re-package and have FOMM do all the work of building the archives, zipping it up, incrementing the version number (optional) and putting the final upload file into the Downloads directory so that when we click on Upload from Nexus, the file is sitting there ready to be clicked without having to navigate directories to find it. An "Easy" button by any other name for mods that doesn't require setting up special directories and configuring .ini files.I'm sure the next thing your going to tell me is that FOMM already has this feature and again I was just unaware, but from what I have seen in the Package manager, the process is not super-simple as described above.

To make such a feature work, I recommend a GUI wizard that the modder can launch from FOMM, and would walk us through setting-up an initial FoMod (or project if you will). Here the idea is to greatly simplify the tasking required to inform FOMM about our mod, where it should look for the files, what to call it, what version number its on, etc - make all that easy in a 4 or 5 step wizard, the output being a new FoMod project that the user can the click "RePackage" to have FOMM build it up and make it ready for Nexus.

Now I have a tool that can in about 5 minutes learn about my mod, where it lives and what needs to go in the package. After that its a 15 second task to open FOMM and click re-package when its time to update Nexus, and I can go to Nexus and do my essentials there for uploading a new file. Then "Ding!" Your Fomod dinner is ready, and by then I'll be to the step on the Nexus form where I upload the new file, and wala - it's right there waiting for me.

I would use that, alot. Even that might not be good though, as each mod is very unique and I'm not sure how easy it will be to simplify the process of telling FOMM what has to go in the FoMod, so this idea may not even be viable.

Food for thought.

Miax

Your idea is not without merit, and it is precisely that sort of info I'm looking for.


It does, sort of. FOMM includes a FOMod creator. It's basically a wizard with some help text on each step. It doesn't allow editing of FOMods directly, but it does allow for the simultaneous creation of a PFP, and PFPs can be edited. The main reason FOMods can't be edited is because they don't store information about where their files cames from. PFPs do. Indeed, I use PFPs to do exactly what you are describing. I create a PFP for a mod, and build the FOMod at the same time. When the mod is updated, I use FOMM to edit the PFP, change the FOMod file structure/edit the readme/script/do what I need to, then regenerate the FOMod and PFP. For simple mods without a script, the workflow would look like:

• Open FOMods Creator.
  
• Drag files to where you want them in the FOMod.
  
• Author the FOMod Info.
  
• Write the Readme.
  
• Select Create FOMod and Create PFP.
  
• Click OK.
  
• Upload FOMod.
  
• Keep the PFP for your use.

That would create your initial FOMod and PFP. To do an upgrade:

• Select "Edit PFP" in the Package Manager.
  
• Specify the PFP you created.
  
• Specify where your mod files live.
  
• Rearrange files in the FOMod as required.
  
• Edit the FOMod Info.
  
• Edit the Readme.
  
• Select Create FOMod and Create PFP.
  
• Click OK.

[EDIT]
Sorry, my head was out to lunch. To build/update a FOMod:

• Open FOMods Creator.
  
• Drag files to where you want them in the FOMod.
  
• Author the FOMod Info.
  
• Write the Readme.
  
• Select Create FOMod.
  
• Click OK.
  
• Extract the fomod folder from the new FOMod to you mod's folder, so you have it for future updates.
  
• Upload FOMod.

That would create your initial FOMod. To do an upgrade:

• Open FOMods Creator.
  
• Drag files to where you want them in the FOMod, including the fomod folder you now have.
  
• Edit the FOMod Info.
  
• Edit the Readme.
  
• Select Create FOMod.
  
• Click OK.
  
• Extract the fomod folder from the new FOMod to you mod's folder, so you have it for future updates.
  
• Upload FOMod.

[EDIT]

I don't think many people know about this functionality, and I'm sure it can be improved upon (hence this thread, actually - I'm wanting things to be easy easy easy for mod authors come FONV). If you feel up to it, take a look at the creator, and let me know what you think.

I am also open to extending FOMM's functionality for mod authors. Not only with regards to simplying maintenance, but also, for example, I have a tool that uploads my files to the Nexus for me. I could incorporate that functionality into FOMM if it would make things easier for mod authors.

Interesting! As you suspect I didn't know about this, so I'll run an experiment this weekend and will package my mod with FOMM and report back my experience. Last weekend I finally finished making it ready for conversion to FNV (if that ends up being possible), and successfully made BSA archives for it (though I'm not going to use them for this test, I'll use the raw files). I've got about 480 megs of textures and 35 megs of meshes and will report back the build times and any difficulties or inconveniences that I find.

Cheers and stay tuned,

Miax

kaburke,

Overall the process worked, but it was not smooth. Here is my experience:


Took me a few minutes to find this, but I got into the wizard okay.


Very confusing situation here. I can select plug-ins and masters, but cannot simply select the directories in Data\Meshes or Data\Textures that I need. Example; My meshes are all kept in Data\Meshes\Miax and Data\Textures\Miax (with sub-directories underneath each). If I select the Miax directories when creating the FoMod, in shows the Starting path of these directories as Miax\, and will actually Combine my meshes and textures. I cant select Data\ or Data\Meshes as that would include a million files. The only way I could do it was to create a staging directory that had the right Data\Meshes\Miax, Data\Textures\Miax structure with the files that I could then select in FOMM to create the FoMod from and end up with the right directory structure on the output... I wasn't sure what I needed to keep in the the Source files section versus what I wanted in the FoMod either. Using the staging directory I got it to work, but that required that I either copy Everything into that staging directory Or that I move my main source files into the staging directory for the duration of creating the FoMod.

So either I am doing something Horribly wrong here, or this part of the Fomod creation process needs Very much clarification. At minimum when the wizard asks for what to include in the FoMod, it should remember and understand the basic Data\ directory structure of the game, and I shouldn't have to stage everything in a special directory to get the right stuff included. If the modder selects a sub-directory such as \Data\Meshes\Miax, FOMM should include Data\Meshes\Miax as the path to those files, same for textures, sounds and every other sub-directory off Data where FoMod informaiton might reside. I understand that many modders have directories off Fallout 3 or even elsewhere and thats fine, but FOMM should have enough smarts to know that when a modder selects something inside the primary Data\ tree to record its path accoridnly. This would make the task of telling FOMM what directories to include in my mod intuitive, easy and quick.

...

You forgot the step on Download Locations. I still down entirely understand the point, some vague help is included in the top of the section but not enough for me to understand which option to select. I chose Included in all cases to get through the section. I recommend clarification on what the mod author is supposed to do when this step comes up. I also didn't get a good handle from FOMM on what a "Premade FoMod Pack" is - I still have no idea. Some clarifiaction in this seciton on what the modder needs to do and what the options mean would be greatly recommended.


The rest of this is well constructed and worked well. I really enjoyed the fact that FOMM would sense errors in the input, tell me where they were and giving me the chance to fix them - very slick! I tested the created FoMod and everything worked smoothly. I like what you have done, and if the file-addition part is clarified and made simpler, then creating FoMods is not in fact hard to do at all. Nice work! :goodjob: I ended up with a Fomod that is just over 400 megs in size, and all interior/exterior cells work without issue after install.

But... (and here comes the but). Its still a process. There is not an "Update" button in there that will re-build the FoMod based on my previous directories/selections for that FoMod and upload it to Nexus for me, I still have to go through all that pain. So the FoMod isn't really saving me any time, as making a Zip file of my contents isn't any more difficult or less time consuming that what I just went through to create a FoMod. Updating it, with all the required steps/fields I have to touch, is still a cumbersome process that I wouldn't want to go through if I updated my mod on a frequent/regular basis. For big, one-time releases that get rarely updated, the FoMod offers some nice options. But it's still a process and its not 100% compatible with what the peeps run in the field. The tough reality here is that FOMM is not universally used like OBMM was in Oblivion, and in some cases the FoMod hurts.

I think that (assuming the clarification parts are fixed) the FoMod creation process is about as simple as anyone could expect. You could improve the UI here and there, add some ease-of-use options and such, but I don't think that doing so would by itself resolve the challenge of adoption for FOMM/FoMod. I do recommend the "Update" button that would result in a FoMod dumped into our Downloads directory so that uploading them to Nexus is a few-clickers simpler.

Another recommendation is instead of producing just FoMods, give the mod author an option of creating a FoMod or creating an self-installed Zip-package (or both). In the latter case you would be packaging a mod with a simple install script that would automate the process of decompressing the files into the right directories and checking that mod in the players mod list. This would support people that don't use FOMM, but would still offer the mod author an advantage for going through the process. The player can choose to run the install script or install the mod by hand, but this would ensure that the files go into the right directories and removing a player's ability to screw-up by putting the files in the wrong place or not checking the mod. This alone would remove a ton of newbie feedback/questions, which we modders like and offers another reason why to use FOMM for this.

Another comment; I was using an older version of FOMM and didn't realize how far behind I was. I think having a "Check Version" button on there would be good, the user could see if they are on the most recent version and either have the tool prompt the user if they want to download/install the latest version (recommended) or just show that they are out of date and offer a link to the web-site (cumbersome). Food for thought.

Cheers,

Miax

There is one additional recommendation I want to make that has the potential of making FOMM a Much more universally adopted solution for mod management; link FOMM with Nexus. What I mean by this is to offer us the ability to upload the updates we make to our mods to pre-existing mod projects on Nexus when we click the "Update Fomod" button in FOMM. Once the Fomod creation/update is done, it could prompt the user, "Do you wish to upload this update to Nexus?". Instead of having to log into Nexus and do all that work, here is what I envision:

1. FOMM would ask all of the questions that Nexus usually asks when we upload a File to a project, such as version number, project Name or Number, etc.

2. FOMM would store your Nexus credentials so we would only have to enter them once, and would use them when posting the update.

3. You and DarkOne would work out a simple API (such as SOAP) that could be used to post updates to projects, and the process would work exactly the same as uploading a File to a project on Nexus works today (its a simple, one-page form, selection and uploading of the files, etc). The FoMod would be uploaded as a Zip file (which FOMM would create) and be called by a Name-Version combo that you prompt the mod author for.

4. FOMM would connect to Nexus pull a list of the projects that your credentials are authorized for, and the user selects the project for this update.

5. FOMM uploads the new Zip file and info to Nexus via the API, and Voila - updated mod with one button clicked.

Yes this is takes some work and would require negotiating with DarkOne on an API/method by which you could safely/securely upload mods to Nexus. I recommeded that it work only for pre-existing projects, as creating new projects requires alot more steps and for security it would be better to require mod authors to still do that via the website. But once a project is created, uploading addition files to it (given the proper credentials) presents much less risk, is less complex and could still follow all the same upload restrictions that Nexus requires.

So lots of work for you in this idea, but the pay-off for us IMHO would be huge. It would be much more than just a convenient way to upload mods in my view. It would actually be the first-step toward creating a Client for Nexus. The way I look at it is that Nexus is THE source for mods for the games we love, and has a well-established system and methodology for storing them and offering them up for hungry modders. On the other hand FOMM is THE most popular/default tool used to order mods and launch Fo3 with its ability to add FOSE and simplify the mod-load order process, its integration with BOSS, its ability to handle FoMods, etc, etc. To me the next logical step is for FOMM to connect with Nexus in a way that super-simplifies the process of adding and playing mods. Your almost already there, your even checking for mod conflicts now. And while we are still in a day that requires mod de-confliction and merged/bashed patches to get our mod-rigs running smoothly, this would bring you a big leap closer to the day when mod users can click on the mods they want to download and play, and FOMM would automatically install them and rig them up for the player with minimal interaction (e.g. minimal smarts) on the part of the player.

There would be many difficulties and challenges to overcome to be sure, but I envision a day in which downloading, installing and managing mods is no more complex than Apps on an iPhone. We're not that far off today, and whomever gets to this nirvana first is going to OWN the modding space. I would like that to be Nexus, FOMM, Fo3Edit and the Wyre Tools myself, and can already see that one day the process of creating a merged-patch (or bashed-patch) will have enough smarts built-in for an Approximated solution to be created for any mod list. Yes we are not there now, and yes modders will always add stupid errors into our projects that make a perfect, conflict-free game impossible. BUT it is still possible to get Close to an automated solution, and for the vast majority of modders that have No idea how to de-conflict mods and will Never learn merged-patches or bashed-patches, that this approximated "best-guess" solution is a real winner for the tool that can do it. With no link between Nexus and the tools today, downloading and installing mods is a Very cumbersome process in which many modders fail and quit out of frustration. If the process were more automated with less need for players to understand the inner guts of the engine to get mods to work, then modding overall would be more successful.

An important first-step is the process of linking FOMM with Nexus via the web (SOAP is a safe, modern, sixy protocol - but there are others too). Starting with the simplest thing; uploading a new file to an existing project, would give you something that we mod authors WANT, and its a small-enough project that wouldn't be overwhelming to code. Given that DarkOne is a pretty nice guy, I GECKulate that he might even make the job easier for you by exposing a private web page that could simplify the inputs and process (which would also protect the main Nexus pages and give him a way to monitor your activity as only FOMM would hit that page). If you guys were successful, you would have a way to Greatly simplify the process of adding updates to existing mods on Nexus for us mod authors, and given that the Nexus upload is also a process we have to deal with, it would offer the modders a more concrete savings in time and convenience for going through the FoMod creation process. If your process also produces (or alternately produces) a self-extracting or zip archive version for those that don't use FOMM at home, your covering all the customer options.

This may all be too complicated for right now, but I see FOMM as a fantastic tool that I can't do without, and Nexus as a fantastic resource that I can't do without either. Your both positioned to dominate the modding scene if you can join forces (even in a non-formal, non-recognized way). Food for thought.

Cheers,

Miax

I'm going to be blatantly honest with you! I still feel I'm the new kid here, I've never modded any game other than HO!2! I've never worked with oblivion and, I'm afraid! I'm afraid I'll start to make mistakes if I keep adding more levels of complexity to my mod.

I'll be one of the first to jump on the bandwagon when it comes to a universally accepted format. I'm a professional photographer by trade, I feel that the DNG format should be accepted as the standard format. It is a free and open source, will always be available! It insures that imagery will never be lost do to some odd corporate decisions.

My real issues come up because, I have never packed my assets up into BSA's I don't know how easy it will be for me to update if I pack up into a FOMMod.

I know how to do things now but, change is always a frightening thing.

First, thanks for the awesome feedback, Miaximus.

I don't disagree that there is room for improvement, but I would like to highlight a couple of points and difficulties you may not have been aware of. The process for putting files into the FOMod is

• Drag source folders to the Source Files box.
  
• Optionally, create folders in the FOMod Files box. This can be done by Right Click->Create Folder.
  
• Drag files/folders from the Source Files box to the FOMod Files box.

So, to be specific to what you were doing:

• Drag Fallout's Data folder to the Source Files box.
  
• Create a textures folder in the FOMod Files box.
  
• Drag the Miax folder in the textures folder from the Source Files box to the FOMod Files box, dropping it in the newly created textures folder.

This avoids the need to create a staging folder, as you ended up doing.

The problem with automatically detecting the path to a folder dragged from the Data folder is that it may not be what the mod author wants. For example, what if you have multiple texture options for an item you've added to the game? You may, while building the mod, have kept them all in Data\Textures\MyMod, and called them tex1.dds, text2.dds and so on, with the current texture that shows up in the game called tex.dds. You may wish to drag the optional textures to an Options folder in the FOMod, rather that FOMM autodetecting the path.

The steps I outlined above remove the need for a staging folder, as I mentioned, however it may not be an ideal process. Your thoughts on the matter are welcome.


I put a disclaimer in that section, but it isn't very clear. I didn't mention it as the Download Locations are not used when creating a FOMod, only when creating a PFP. The best description (so far) of what a PFP is is likely http://www.gamesas.com/index.php?/topic/1118082-why-are-there-so-few-fomods/page__view__findpost__p__16430759. You are right, FOMM doesn't make it even remotely clear what a PFP is.


I'm still working on how such a button would work. The issue is that for mods that require a script, or have had substantial file structure changes, such a button would as often just mess things up as do what you would want. What happens, for example, if you start using a second folder in textures called Miax2? How would FOMM know it's supposed to include it? Obviously you would have to rebuild the FOMod, but the presence of a one-click button invites forgetfulness. I'm sure there is a safe way to include an "Update" button, but I'm still working it out.


Self-install packages can't run FOMod scripts, so that option couldn't be universally available. As for the self-extractor simplying user install, well, that's the point of a FOMod.


Main window, Help->Check for update in the menu bar.


I've already written such an API. I use it in another tool I have that helps me maintain my http://www.fallout3nexus.com/downloads/file.php?id=11200, and is already incorporated into FOMM, though it's full functionality is not available (it's this API that checks the Nexus for newer version of mods, for example). The API currently allows file uploads to existing mod projects, editing of uploaded files, and deletion of uploaded files. I plan to add editing of project attributes at some point. If there would be benefit, I would leverage this API to upload FOMods for authors.

As to creating a full-on client for the Nexus, this was something I have already considered. For example, PFPs include URLs pointing to the files they need to build a FOMod, so I have briefly considered having FOMM automatically download the required files and build the FOMod without any user interaction (apart from selecting the FOMod). This could even be extended further: FOMM could grab a list of PFPs from my PFP project, the user would check the ones he/she wants, FOMM would download the select PFPs, the files each PFP needs, build the FOMods and install them for the user.

The problem with this is that the user would (virtually) never have to visit the Nexus again. This is an issue because the Nexus relies on it's ad revenue to survive: if no one visits, no revenue is generated. Thus, I don't want to create a tool that means people won't have to visit the Nexus. Yes, it may make things a little less simple, but I think it only fair to give DarkOne a chance to make the money he deserves for providing such a service.

Again, thoughts and feedback about this are welcomed.


Creating a FOMod is no harder than creating a folder called fomod in your mod, and putting in an info files describing your mod (download URL, version, description). You then zip up your files as normal (or 7z or whatever you normally do), and upload to your preferred distribution site.

The most complex part is creating the info file. The simplest way to do this is to use FOMM.

Interesting... So then from your responses I now understand that FOMM has pretty much all of the features that one might want in managing mods with a single exception; My Understanding. I stumbled alot on things that did not seem intuitive without a tutorial or being told by you/someone in the forums.

I didn't Know much about this tool though I have used it a zillion times for its basic functions, yet I have not yet found any comprehensive tutorials (video or document) that would walk me through FOMM step-by-step and show me Exactly how to use these features. I don't mean giant blobs of text that put most of us puny humans to sleep, but something comprehensive in document form with images or thorough in YouTube form. Perhaps I just didn't know about these as well; I woul definitely take the time to learn from them if they exist. If they don't exist, then perhaps expanding FOMM in the areas of documentation and tutorial (either in-tool help or outside) might be just the thing. Perhaps alot of folks Real reason for not using Fomods to package everything is because the bulk of us new/mid-experienced modders is that we really don't understand the tool beyond the basic functions.

In any respect, I love FOMM and think you have a fabulous job with it! :goodjob: I penned all this feedback in the hopes of helping you understand what I didn't understand as an average FOMM users and modder. I thank you for your efforts, and look forward to using FOMM with New Vegas for many years to come.

Cheers,

Miax