SexoutNG fomod ready to fomod

[prideslayer]

The next release of SexoutNG will be delivered as an actual (basic) FOMOD, and not just a "FOMOD ready" archive, as it currently is. This isn't as big a change as it may seem, and it can be used as-is by those that don't use FOMM for whatever reason. I just want to get the heads-up out there, and explain just what a FOMOD "is" an why I'm making the change.

 

What is a FOMOD?

.fomod is the native mod format for FOMM. Under a microscope, it's nothing more than a .7z file renamed to .fomod, with an additional directory inside. The additional directory is called, strangely enough, 'fomod.' In that directory are a few files.

 

info.xml : This is the info file for fomods. It has extremely simple information in it like the version number, author, mod name, description, and so on.

 

screenshot.jpg : The mod screenshot that shows up in FOMM.

 

script.cs : A file that contains instructions on how to use the mod.

 

For those of you not using FOMM, first shame on you. Second, you can install this exactly as you already are, just rename the file from "SexoutNG.fomod" to "SexoutNG.7z", open it, and copy everything inside to the data directory -- except the 'fomod' directory of course.

 

Why are you doing this?

To make you miserable.

 

just kidding. I'm doing this for a few different reasons.

 

1. This allows me to give you the option, during installation, of which version to install. For a while now, SexoutNG has come with the last 5 or so previous ESM versions as backup files, in case I break something with a release. This will let you simply deactivate and reactivate the mod, choosing a different version, if you need to.
   
2. I will also be able to choose which plugins I want to be activated in FOMM by default. I will use that to activate the main ESM, but leave Notify and LevelUp inactive -- or even give the option of not installing them at all.
   
3. Reduces the number of downloads in the thread. There is a limit of four attachments to a post, and the sexout core takes three. When you add the fourth, you can no longer 'update' any of the others, unless you delete one first.
   
4. Eventually we will have voice packs, alternate textures, and who knows what else. I want to prepare for that now, by making it easy to select which ones you want to install and which you don't.
   

 

I don't want to download the whole thing just to get the plugin updates!

You won't have to. I will also be releasing a standalone FOMOD that only has the plugins. This will still have the option to install different old versions of NG, and install/activate the included ESPs.

 

Initially you will want to download just the main FOMOD, so you can get FOMM "cleaned up" by getting rid of the three existing packages: plugins, animations, and datapack. After that, subsequent updates will only require you to download the plugins FOMOD, unless new animations etc. are added. When updates to the animations or other datafiles do occur and result in a release, I will start raising the "minor" version number : Meaning the next release that has animations will be 2.4.something. This is your sign that you need to download the full install and not just the plugins update.

 

If this proves too cumbersome, I will split the main FOMOD into two: the datapack, and the plugins. The future datapack in this case will have all the files from the current animations *and* the current datapack. I think we've reached reasonable stability here though, so I'm not worried about it.

 

But seriously, again, why?

I want to do things that the FOMOD format lets me do, it's that simple. I want to provide options during installation. I want to reduce the number of downloads in the main thread, so I can add other attachments. I want to always have a spot available for the beta release as a bare ESM. The list goes on.

 

Also, if I haven't made it clear, I want to encourage using FOMM. I want to make it cumbersome on people who don't have FOMM. I want to make it more difficult for newbies to "screw up" the install, and thus less likely to make threads about sexout being "broken" when really it's their ability to follow instructions that's broken.

 

The pros among you who insist on not using FOMM already know: when you download the file, if you just save it as .7z instead of .fomod initially, nothing really changes for you. I will do my best to keep the directory structure totally vanilla, so copy/paste from 7zip will just work, but no promises.

 

If you come at me with the torches and pitchforks before this gets too far along, I may be convinced to drop the idea, but you better come prepared. It won't be an easy fight.

[DoctaSax]

 

Also' date=' if I haven't made it clear, I want to encourage using FOMM. I want to make it cumbersome on people who don't have FOMM. I want to make it more difficult for newbies to "screw up" the install, and thus less likely to make threads about sexout being "broken" when really it's their ability to follow instructions that's broken.

...

I will do my best to keep the directory structure totally vanilla, so copy/paste from 7zip will just work, but no promises.

...

If you come at me with the torches and pitchforks before this gets too far along, I may be convinced to drop the idea, but you better come prepared. It won't be an easy fight.

[/quote']

 

Well, this is hardly an attempt to pick a fight. Just a little note. I'm all for making the install easy for people who think it's hard.

Just please don't go overboard with "I want to make it cumbersome on people who don't have FOMM." In my experience, the more scripted a fomod install is, the less clear its package structure (especially when files are auto-renamed and moved around during install). Which is a pain if you prefer Wrye, or like to tweak, mix and match.

 

This may sound a little more panicky than there's call for atm, but who knows, in time, how it'll all evolve. Especially when you mention alt texs and sounds, I myself would definitely prefer to let Wrye handle that.

 

So, the ideal option would be to let the fomod script draw from a wrye-ready package structure. The fomod users wouldn't notice a difference, the Wrye users could just rename to a .7z and tick their little boxes. Win-win

[prideslayer]

I was being a bit.. bombastic I guess.. haha.

 

The cumbersome bit is really just two things:

- renaming back to .7z (which you don't have to do anyway. 7zip can extract from a .fomod fine.)

- Not copy/pasting the 'fomod' dir in the archive when you extract it manually.

 

That's all that anyone not using FOMM should have to do. The "newbies" won't know this.. and so when told "you need FOMM", they will just download it, and we'll all be better off.

 

The Wrye thing sounds interesting, but I'm not really that familiar with it. I'll look into the suggestion though. If you're saying there's some archive format that both Wrye and FOMM can be happy with when it comes to installing options, and people who use neither can still easily do a manual install.. that does sound pretty good.

[deathparade]

Nice to see it goed Fomod... just that i liked putting time into installing the mod as developers putted time in making it i kinda got a finally that i should put some time and though in it myself!

 

And yes i really encourage using FOMM as it is easy and i keep a few backups on it just in case.

[DoctaSax]

I was being a bit.. bombastic I guess.. haha.

 

The cumbersome bit is really just two things:

- renaming back to .7z (which you don't have to do anyway. 7zip can extract from a .fomod fine.)

- Not copy/pasting the 'fomod' dir in the archive when you extract it manually.

 

That's all that anyone not using FOMM should have to do. The "newbies" won't know this.. and so when told "you need FOMM"' date=' they will just download it, and we'll all be better off.

 

The Wrye thing sounds interesting, but I'm not really that familiar with it. I'll look into the suggestion though. If you're saying there's some archive format that both Wrye and FOMM can be happy with when it comes to installing options, and people who use neither can still easily do a manual install.. that does sound pretty good.

[/quote']

 

Heh, well, like I said, I might've sounded a bit panicky, but the more install options, the more chance the fomod script handles everything for the regular user at the cost of control by a more finnicky user

For instance, I like to mix & match resources from different beauty packs - a hand mesh here, a face tex there - but if they only come in big fomod packs like BOG or desert succubus, a "pink.dds" in some subfolder can be anything, and you have no idea it should actually be renamed to handfemale.dds & placed under meshes/characters/etc.

 

This should help explain a wrye-ready structure:

http://cs.elderscrolls.com/index.php/Bain

an old page, but things haven't really changed for Flash

 

There's not much difference with a 'normal' package structure (down from 'data'), really, except that for more complex install options it uses numbered folders to mutually exclude certain choices (01 + 01 = no go), or allowing some extra stuff to overwrite a regular install (01 > 00). Each numbered folder that is ticked in wrye will be tracked from then on.

This type of structure has the added benefit that people going for a totally manual install also have a good overview of what's what and where it belongs.

 

So eg in this case you could eventually have

 

00 Core files (folder)

---- Docs folder (for readmes etc)

---- Meshes folder

---- Sounds folder

---- Textures folder

---- other stuff (your nvse plugin maybe)

01 Latest sexout esm (folder)

---- Sexout.esm

01 Previous sexout esm

---- Sexout.esm

01 Another previous sexout esm

---- Sexout.esm

...

02 Optional esps

---- LevelUp.esp, notify.esp etc , can be individually ticked if wanted

03 Some alternative doc penis texture

---- Textures\Creatures\...\dogpenis.dds

04 Voice pack A

---- Sounds\...

04 Voice pack B

---- Sounds\...

fomod

---- info.xml, screenshot.png, script.cs

 

Those using a fomod install will never have to look inside but it does make for clarity & control for those who want that.

[prideslayer]

Heh' date=' well, like I said, I might've sounded a bit panicky, but the more install options, the more chance the fomod script handles everything for the regular user at the cost of control by a more finnicky user

[/quote']

Yes, to an extent, but that's what the readme's are for. If there's a fomod script (I'm partial to the XML method instead, though I am still learning the structure) then there will be a detailed readme documenting what options do what with what files.

 

For instance, I like to mix & match resources from different beauty packs - a hand mesh here, a face tex there - but if they only come in big fomod packs like BOG or desert succubus, a "pink.dds" in some subfolder can be anything, and you have no idea it should actually be renamed to handfemale.dds & placed under meshes/characters/etc.

 

I do as well, and TBH, FOMM handles this beautifully. I never mix and match manually except in the case of my body -- but that was only after I was done playing with the install options normally. I'll go through the activate/deactivate cycle until I am happy with my options, overwriting (or not) files as I choose. FOMM does make this easy since it'll ask you if you want to overwrite (or not) every file. No guesswork about names.

 

That said, I don't intend to do that sort of BS with sexout. If I end up with three different versions of "handfemale.dds" in the thing, then they'll all be named "handfemale.dds" and just exist in different directories -- directories that won't cause any issues if copied directly to the data directory, like the existing readme/docs directory.

 

This should help explain a wrye-ready structure:

http://cs.elderscrolls.com/index.php/Bain

an old page, but things haven't really changed for Flash

 

Will check it out.

 

There's not much difference with a 'normal' package structure (down from 'data'), really, except that for more complex install options it uses numbered folders to mutually exclude certain choices (01 + 01 = no go), or allowing some extra stuff to overwrite a regular install (01 > 00). Each numbered folder that is ticked in wrye will be tracked from then on.

This type of structure has the added benefit that people going for a totally manual install also have a good overview of what's what and where it belongs.

 

I haven't looked yet, but do they have to be numbers? Can they be words instead?

 

This structure overall isn't something I'm keen on putting in place, in order to keep it easy for manual installers as already discussed. My preference would be to have the directory structure more like this.

 

This is all toplevel, in a "proper" fomod ready archive, there's no data folder; it's assumed that everything in the archive goes into the data folder.

 

Sexout.ESM
fomod\
 (fomod specific junk)
textures\
 (default stuff)\
meshes\
 (default stuff)\
Sexout options\
 textures\
   option A (or whatever)\
   option B (or whatever)\
 meshes\
   option C (or whatever)\

 

Does that make sense? Do you know offhand if wrye can support this?

 

If a user does manually and blindly copy the install into the data directory, I don't want to end up creating a bunch of (conflicting) directories like "01" and "02" within the data dir, I want everything self contained within just a few Sexout directories that quite obviously belong to sexout.

 

This is something I can do with the fomod structure pretty easily.

[prideslayer]

The first fomodded version is available for download. If there are problems with it, now's the time to suss them out.

 

This version does nothing special with the install, no options or anything, should work just like the previous versions.

 

I did have to write a custom install script, but that's just because (apparently) FOMM was seeing the esp files in a subdirectory and choosing to not install any esp, esm, etc. texture files. So I stole a little code snippet from project nevada to just iterate through the whole directory structure copying everything except the fomod directory itself. Seems to be working fine.

 

Let me know if wrye gives any issues.

 

Manual installs will still work fine as already described. Just open the .fomod file with 7zip, and drag n' drop everything (except the fomod dir) into your data directory or wherever else you want it.

[DoctaSax]

That said' date=' I don't intend to do that sort of BS with sexout. If I end up with three different versions of "handfemale.dds" in the thing, then they'll all be named "handfemale.dds" and just exist in different directories -- directories that won't cause any issues if copied directly to the data directory, like the existing readme/docs directory.

[/quote']

 

Well, that's good news in itself. If there's none of that renaming & repositioning, a wrye user can restructure things him/herself.

 

I haven't looked yet, but do they have to be numbers? Can they be words instead?

 

I'm not sure they're absolutely required, but it's the standard practice.

 

Does that make sense? Do you know offhand if wrye can support this?

 

If a user does manually and blindly copy the install into the data directory, I don't want to end up creating a bunch of (conflicting) directories like "01" and "02" within the data dir, I want everything self contained within just a few Sexout directories that quite obviously belong to sexout.

 

This is something I can do with the fomod structure pretty easily.

 

Nah, that structure wouldn't work with Wrye. Unless you go for BCFs (never liked them), Wrye has all choices happen at top level, with the numbered folders and you ticking what you want. Like here, where the number 3 is.

 

I hadn't thought of the possibility of people plunking in the numbered folders at data level - supposed that people going for a purely manual install over the fomod would at least take the time to have a look inside first. Of course, manual install isn't necessarily a blind install to me - quite the opposite. But I think we can dispense with 'blind' simply by having it standard in a fomod package, so people actually have to make the effort to rename & extract if they're going for manual/wrye.

 

Then again, the same problem of people plunking everything in there can also happen at sub-level, where you have

Textures\optionA\...

Textures\optionB\...

For a manual install that might even be a bit more tricksy because the choice is hidden some folders below. With the numbered folders at top-level, at least not seeing meshes/textures/sound folders right away should make you pause to think.

 

That said, as long as it's all correctly named and neatly divided, I don't have a lot of trouble with restucturing it for wrye use myself. So although what you suggest isn't wrye-ready, it can be made that way.

[prideslayer]

I will investigate more and see if I can't add direct Wrye support as soon as I have the time to do so. The install now is working (it seems) and as yet, there's nothing 'goofy' going on WRT naming, options, etc. It's all very vanilla, though I was able to add load order checking to the script, which will be in the next version.

 

Again, nothing fancy, it just checks to see if you have SCR and if so, ensures that sexout goes before it. If you don't, then you get a popup saying "You should probably get SCR as well."

 

The textures, again, I have no intention of doing anything like that.

 

My structure at the top level should not change at all from the way it is right now in the existing file. There are three directories at the top level (not counting meshes, sound, textures, and fomod):

 

SexoutNGBackups - this holds old versions of the ESM as .bak files.

SexoutNGDocs - TXT files

SexoutNGOptions - Right now, just the levelup and notify ESPs.

 

If/when I get to the point that I start adding options, all of them will go in the SexoutNGOptions directory, and be fully structured below that.. e.g.

SexoutNGOptions\Option 1\textures\...
SexoutNGOptions\Option 1\meshes\...
SexoutNGOptions\Option 2\textures\...
SexoutNGOptions\Option 2\meshes...

 

I think that makes it easy for manual installers and wrye users alike to quickly pick the things they want, with no question as to "what goes with what and where."

 

My plan is to leave it that way at least until I can get around to learning Wrye well enough to support all three methods cleanly.

[iron_jack]

For the record, in BAIN terms that could be done as

 

00 Core (mandatory files go here)

--meshes

--textures

--etc

 

01 Option 1

--meshes

--textures

smurfs.esp

 

01 Option 2

--meshes

--textures

smurfettes.esp

 

 

(That's if the two were mutually exclusive, otherwise the second 01 would be 02)

 

 

 

I do BAINify everything before I install, because (imo) Wrye Bash is superior to FOMM in almost every way. It looks confusing at first, but it's really very easy to use.

 

 

 

Here's your current package BAINified, if you want to see the structure. From this point you could write an install script so it'd be fomod-ready/newbie-friendly as well. Also, for the record, you can write wizards for BAIN installs, similar to fomod scripting.

 

 

 

edit: Also, I don't see much reason to include old versions in the main download. Just offer an archive of old versions as a separate download, if you ask me. It's just useless clutter for 99% of people.

[prideslayer]

Thanks jack, I'll take a look at that..

 

I do BAINify everything before I install' date=' because (imo) Wrye Bash is superior to FOMM in almost every way. It looks confusing at first, but it's really very easy to use.

[/quote']

 

I'm not about to switch now, I really like FOMM's interface. Work continues on my own replacement, heavily influenced by it, which is why I'm really not going to personally switch. No point in switching now when I'll just be switching to my own thing later anyway.

 

But, what makes it superior? I honestly haven't seen or heard of anything it can do that FOMM can't.

 

Here's your current package BAINified, if you want to see the structure. From this point you could write an install script so it'd be fomod-ready/newbie-friendly as well. Also, for the record, you can write wizards for BAIN installs, similar to fomod scripting.

 

I'm not really sure how that's possible.. FOMM can't run BAIN/whatever scripts, so the only way to make it a FOMOD is to.. make it a FOMOD. Of course the FOMM scripting is as powerful as you want it to be (it's just C#) so I can set the structure up however I want, including organizing it the way Wrye wants...

 

But the way Wrye want's isn't the way a "FOMOD ready" archive looks, which is simply a copy of the actual game directory structure.

 

It seems to me that, actually, FOMM is the more powerful tool here -- I can structure the directories any way I want, and the install script can handle it. What I'm hearing is that, with Wrye/BAIN, I have to structure the archive "their way" -- which is incompatible with the "FOMOD ready" drag n' drop "manual install" format.

 

 

edit: Also, I don't see much reason to include old versions in the main download. Just offer an archive of old versions as a separate download, if you ask me. It's just useless clutter for 99% of people.

 

Hah.. one of the points of this whole endeavor is me freeing up download slots in the OP to use for other things. The historic versions are there so if I make a release the breaks everything (as I've done about 4 times in the past), older versions are handy for people to revert to until I can come back and fix whatever I broke.

[iron_jack]

Load/install order control in Bash is just outstanding. In FOMM, install order can get to be a bit of a clusterfuck - did I install X first or Y first, and what's conflicting where?

 

In Wrye, I can look at an installer file and tell you exactly which files are installed (matching exactly), which files are missing, which files are there but mismatched (coming from another mod most likely), which files are conflicting with any other mod I have installed and which overrides which.

 

I can also reorder the install order - install, not just load, mind you - so that things install and override exactly how I want. Oh wait, I want Nessa's body mod to install before the Type3 skins I'm using - no problem, I'll just move Nessa's up in the install order and anneal.

 

That's not to mention Wrye's superior, intuitive error detection (makes spotting missing masters and such a breeze), its mod checker (this mod has dirty edits! This mod has an unrecognized header! etc), and of course the Bashed Patch, which as far as I can tell is superior to FNVEdit patching in almost every way - or at least more intuitive.

 

 

Yes, I'm a Wrye fanboy.

 

 

 

You are correct that with the scripting possibilities, FOMM is a little more flexible in that sense, which is why it would be possible to structure the archive in a BAIN-ready way, then turn it into a fomod. Then us BAIN users just need to rename it back to a 7z file.

 

 

 

Or, alternatively, not. But I do and always will use Wrye for this stuff.

[prideslayer]

Load/install order control in Bash is just outstanding. In FOMM' date=' install order can get to be a bit of a clusterfuck - did I install X first or Y first, and what's conflicting where?

[/quote']

 

It could be presented better, but it's all there, and I don't really find it a 'clusterfuck' If you haven't, click the "file manager" in the main FOMM screen -- though this presupposes you use it.

 

There's the entire data directory, along with every file installed by every mod, with the one you are currently using highlighted. You can change the order there for individual files.

 

An alternate view will let you start with a mod instead and see what files it installed, and if they are conflicting with any other installed mods, and again select which one you want to use from which mod really easily.

 

In Wrye, I can look at an installer file and tell you exactly which files are installed (matching exactly), which files are missing, which files are there but mismatched (coming from another mod most likely), which files are conflicting with any other mod I have installed and which overrides which.

 

FOMM has this capability, though the interface is different. It would be helpful to be able to tell just by clicking or hovering over a particular file or package what it's total status is, but that's just one reason I'm writing my own

 

I can also reorder the install order - install, not just load, mind you - so that things install and override exactly how I want. Oh wait, I want Nessa's body mod to install before the Type3 skins I'm using - no problem, I'll just move Nessa's up in the install order and anneal.

 

FOMM also provides something like this, though not as clean I admit. You can reactivate a mod (a package) at any time, and it will uninstall and reinstall it, giving you the option to overwrite files or not as it goes. The biggest pain in the neck here is simply that if you tell it to ask you about conflicts, it's going to ask you about every one of them.

 

If you want them installed in a certain order, and you know that order, just activate them in that order and allow it to overwrite everything. You can rename them, adding #s to the front, if that makes it easier to keep track of.

 

It's not perfect, but it works well enough for now.

 

That's not to mention Wrye's superior, intuitive error detection (makes spotting missing masters and such a breeze), its mod checker (this mod has dirty edits! This mod has an unrecognized header!

 

FOMM has a tiny bit of that (missing master) but you have to check for it manually. Overall this is an area that FOMM isn't very good at, but at the end of the day, it's hand holding I rarely need..

 

etc), and of course the Bashed Patch, which as far as I can tell is superior to FNVEdit patching in almost every way - or at least more intuitive.

 

This will require some justification, sir!

 

I've never had a need or desire to create one of these infamous 'bashed patches', but I use FOMM daily. It's not a patch creator, it's a resource editor that can also make patches, and it's unbelievably powerful.

 

All of the areas where FOMM falls down compared to Wrye are included in FNVEdit in spades. The conflict detector is absolutely outrageous in detail. It would help if some of these features were in FOMM itself, but even though they're not, they are available to use when you need them.

 

You are correct that with the scripting possibilities, FOMM is a little more flexible in that sense, which is why it would be possible to structure the archive in a BAIN-ready way, then turn it into a fomod. Then us BAIN users just need to rename it back to a 7z file.

 

You wouldn't even have to do that -- FOMM will install .7z (or any other archival extension) as a fomod without intervention. It doesn't care what the extension is, as long as it recognizes it. If there's a fomod directory inside, it treats it as a fomod. If not, it tries to treat it as fomod ready, and warns you if it isn't.

 

However, this is the one thing I just can't get around. I'm not going to change the layout of the archive to some asinine file structure (it's entirely backwards. I'm offended by it as a coder, not a modder, hah) just to support a tool I don't even use..

 

Or, alternatively, not. But I do and always will use Wrye for this stuff.

 

The UI is the most important piece of a tool to me, and FOMMs UI is so much better, overall, than Wryes. This is the only thing that's prevented me from switching -- Wrye is a busy ass mess. I've got enough stupid things to figure out when modding, the UI for another tool isn't one I want to add to that list.

 

So you'll tell me to try Wrye again, I'll tell you to try FOMM again, and nobody is going to get anywhere.. haha.

 

I will take a look at it's scripting options though. If I can get around that stupid directory structure issue, I will definitely add whatever other little knobs it needs in order to install through Wrye with a minimum of fuss.

 

It's somewhat moot right now as I don't have crazy options in sexout, and probably won't before my own tool is ready to go -- which may just settle this wrye vs. fomm thing once and for all with the answer : neither.

[DoctaSax]

It could be presented better' date=' but it's all there, and I don't really find it a 'clusterfuck' If you haven't, click the "file manager" in the main FOMM screen -- though this presupposes you use it.

[/quote']

 

Well, I agree FOMM is better in that regard than OBMM was. Still, it doesn't give you the at-a-glance overview of possible data file conflicts that Wrye's bain does.

 

FOMM has this capability, though the interface is different. It would be helpful to be able to tell just by clicking or hovering over a particular file or package what it's total status is, but that's just one reason I'm writing my own

 

See above

 

This will require some justification, sir!

I've never had a need or desire to create one of these infamous 'bashed patches', but I use FOMM daily.

...

All of the areas where FOMM falls down compared to Wrye are included in FNVEdit in spades. The conflict detector is absolutely outrageous in detail.

 

True, but I can't bring myself to using FNVEdit for every little thing - wrye's bashed patch does a good job of merging form & levelled lists automatically, so I run that, along with some tweaks, renaming and merging of cosmetic mods. Then I go over the whole load order in FNVEdit to resolve any remaining conflicts in one final personal patch.

That way, I run awop, nvinteriors, electrocity, EVE, nevada skies, warzones, project nevada, wmx, lings, all DLCs and all sexouts without a hitch, and without missing out on content. The bashed patch isn't the begin-all-end-all measure for plugin conflicts it was in Oblivion, but it still takes care of a lot of menial work that I wouldn't entrust to FNVEdit's auto-patch creation.

 

However, this is the one thing I just can't get around. I'm not going to change the layout of the archive to some asinine file structure (it's entirely backwards. I'm offended by it as a coder, not a modder, hah) just to support a tool I don't even use..

 

Well, backwards, forwards... it's what we're used to, I guess. I've always liked picking stuff apart, seeing what goes where and why, then messing around to fit my own preferences.

The typical BAIN file structure is good for that - options at top-level (avoiding the need for install scripts most of the time), everything under that named & placed where it should be.

As opposed to most complex fomods I peeked inside, which is what caused my dread to begin with. Never meant for the umpteenth wrye vs fomm discussion - just figured that if you were going for a scripted fomod install, that script might as well draw from a wrye-ready structure. I still think that would be good, but as long as there's no foolishness like I described in a previous post, you won't hear me complain.

 

I've got enough stupid things to figure out when modding, the UI for another tool isn't one I want to add to that list.

...

It's somewhat moot right now as I don't have crazy options in sexout, and probably won't before my own tool is ready to go -- which may just settle this wrye vs. fomm thing once and for all with the answer : neither.

 

Oh noes, I'm gonna have to learn the UI for yet another tool?

[KainsChylde]

I'll be blunt, Wrye confuses the everloving crap out of me. I loved FOMM, though ever since using NMM it won't work for me anymore. And FNVEdit is a godsend for a confused noob trying to figure out what the hell he did wrong.

 

Pride, if your installer utility combines FOMM and FNVEdit functionality, I will cheerfully burn all of the other utilities to a disc just so I can set them on fire.

[Halstrom]

Haven't used Wyre Flash myself, and not really interested in it if I can avoid it

FOMOD seems to be ok, I just click the file and it installs, not sue if it means anything different in GECK stuff.

[Dmouse52]

I personally would love to use FOMM if i could!! but the nexus mod manager screwed it up big time. even when I uninstall both of them and re-install FOMM i get nothing except error crash reports and as for the latest version of NMM, it will not accept any fomod that i have anymore so I'm using an old NMM and refusing to update it when asked. If anybody has any ideas how I can get FOMM back I'll be one very happy bunny

[KainsChylde]

I've had that same problem. Up until now I didn't make mods so I didn't miss FOMM that much, but since I am now trying my hand at making and tweaking mods of my own I'd like to regain those tools.

[ljacquard]

For whatever it is worth, I am fully supporting DoctaSax and Iron_Jack on this one.

 

I don't use OBMM/FOMM or their derivative (NMM). The reason is that I, as a user, can't keep control over what these tools do, contrary to WFlash.

 

Allow me take a quick example. If I use FOMM to :

 

• first install MOD_A
  
• next install MOD_B, which has overlapping resources with MOD_A (say, they both install a custom body mesh)
  
• finally remove MOD_B after some time (for whatever reason)

 

the custom body mesh will have been incorrectly removed from your game, while MOD_A still requires it. In other words, the user might think that since MOD_A is still installed, the custom body mesh that came with it should still be there too, while it's no longer the case.

 

As you can see, depending on the number of FOMODS installed, and in which order they have been installed, things can get messy *real* fast.

 

At this time, the only mods I keep as FOMODs are UI merging ones, like "One HUD", "MCM", "Radar HUD", "Unified HUD", etc.

 

The reason is that the scripts performing the merge, specifically written for FOMM, are fairly complex, and I didn't feel like porting them over to WFlash. Also, UI mods have a very low risk to conflict with other mods.

 

Now please don't get me wrong

 

I am not complaining. I don't wish to sound like a rabid "elitist" Wrye Flash freak either. I am *grateful* that you provide us with more user-friendly install options.

 

I would be *perfectly* happy with what DoctaSax suggested, and I think you should go with that option, since Fomod-ready mods can be built with almost no extra efforts to be WFlash/BAIN-ready at the same time. I am willing to help as much as I can to get "Sexout" there, if needed.

 

I just would like to point out that if you're looking for a way to provide your users with a way to prevent bugs during the setup of your mod, FOMM is not the right tool.

 

It might work, if your mod was the only one installed, or in some rare and specific cases like the UI one above. Otherwise, it's pretty much guaranteed it won't.

[KainsChylde]

For whatever it is worth' date=' I am fully supporting DoctaSax and Iron_Jack on this one.

 

I don't use OBMM/FOMM or their derivative (NMM). The reason is that I, as a user, can't keep control over what it does, contrary to WFlash.

 

Allow me take a quick example. If I use FOMM to :

 

[list'][*]first install MOD_A

[*]next install MOD_B, which has overlapping resources with MOD_A (say, they both install a custom body mesh)

[*]finally remove MOD_B after some time (for whatever reason)

 

the custom body mesh will have been incorrectly removed from your game, while MOD_A still requires it. In other words, the user might think that since MOD_A is still installed, the custom body mesh that came with it should still be there too, while it's no longer the case.

 

 

Actually, in NMM they have instituted a backup feature that saves any files overwritten by new mods, and restores them if the newer mod is removed. I have never encountered this problem, and I add and remove files frequently (I have zero tolerance for bad mods, and I've played the game too many times to passively play vanilla or old content).

[ljacquard]

I don't use NMM, but I am more than willing to believe you.

 

Thing is, it's only the obvious issue with FOMM, the easiest one to point out and explain if you prefer.

 

Seriously, I am fine with Sexout being both FOMM/BAIN ready

 

That way, people who can't stand WFlash will be able to do their thing, and vice versa.

 

It's actually how it's done nowadays for most serious ("professional"?) Oblivion mods.

 

 

Actually' date=' in NMM they have instituted a backup feature that saves any files overwritten by new mods, and restores them if the newer mod is removed. I have never encountered this problem, and I add and remove files frequently (I have zero tolerance for bad mods, and I've played the game too many times to passively play vanilla or old content).

[/quote']

[iron_jack]

I agree, a good solid mod should be both BAIN/Fomod-ready.

[prideslayer]

For whatever it is worth' date=' I am fully supporting DoctaSax and Iron_Jack on this one.

 

I don't use OBMM/FOMM or their derivative (NMM). The reason is that I, as a user, can't keep control over what it does, contrary to WFlash.

 

Allow me take a quick example. If I use FOMM to :

 

[list'][*]first install MOD_A

[*]next install MOD_B, which has overlapping resources with MOD_A (say, they both install a custom body mesh)

[*]finally remove MOD_B after some time (for whatever reason)

 

the custom body mesh will have been incorrectly removed from your game, while MOD_A still requires it. In other words, the user might think that since MOD_A is still installed, the custom body mesh that came with it should still be there too, while it's no longer the case.

 

 

Actually, in NMM they have instituted a backup feature that saves any files overwritten by new mods, and restores them if the newer mod is removed. I have never encountered this problem, and I add and remove files frequently (I have zero tolerance for bad mods, and I've played the game too many times to passively play vanilla or old content).

 

This was added to FOMM before the guys went off and created NMM. A long time ago FOMM had this bad behavior, but the newer versions don't.

 

If Mod A installs files, and Mod B overwrites them, uninstalling Mod B reverts you to Mod A's files.

[KainsChylde]

I jumped on NMM when it was in beta and haven't been able to use FOMM since. I either did not know or had forgotten that.

[prideslayer]

I really don't know what NMM has done to screw things up so badly, but everyone says the same thing, so my advice has been to not use it. I never tried it anyway since FOMM works fine, and nexus integration is something I decidedly don't want anyway.

 

One of these days i'll take a look at it though, just long enough to figure out what it's screwing up, so I can tell people how to fix it.