Modfusion! a new FONV mod installer.

[pippinstrano]

I hate to be a b****, but I think an option for a fomod creation would be awesome. Two executables, ModFusion.exe (current version) and ModFusion2fomod.exe. The fomod version copies the content to a work subfolder, add the fomod xml (yes, I know you hate xml) and then zip the work subfolder, creating the fomod. Users then use NMM / FOMM / their mom / whatever to install the new fomod file. And before you say you can't do that, remember that I know you're brilliant and won't believe you. ;-)

[Cyberlazy]

Well, The other thing is I don't really want people to try and redistribute mod fusion esps. I want them to redistribute the settings designed to create them, so that the authors will get credit/downloads, users can reconfigure/tweak at will and the patching/merging function will actualy work.

 

Modfusion is designed to be run every time you install a new mod, be it via FOMM/NMM or a manual install, since thats how it detects newly installed/removed mods and installs the correct patches, preventing the dreaded crash to desktop on startup, or lack of proper patches being installed.

 

Also I don't see how adding another step in the install process (using fomm to install the result) helps anything, it just slows the process down 2 fold since everything will need to be copyed twice. Modfusion can install texture packs/etc too, so that could result in a lot of copying.

[pippinstrano]

And that's an example of my trouble with out of the box thinking......I hadn't considered people redistibuting the fomods created by ModFusion. However, I completely agree that it would be a very bad thing. Grumble, grumble......I really like NMMs ability to keep track of which mods have overwritten each other. It sucks monkey nuts that NMM development hasn't encouraged projects like ModFusion to connect to NMM in some manner. Grumble, grumble. All the pieces to awesomeness are available, but somehow seem just slightly out of reach.

[Cyberlazy]

Its really not difficult to keep track of what overwrites what. Honestly, after dealing with ESP record mergers, its simple.

 

BTW: Modfusion's merge functionality now supports 31 record types:

"LVLI", LeveledListRecord

"WEAP", weaponrecord

"ARMO", armorrecord

"ACTI", ActivatorRecord

"REFR", PlacedObjectRecord

"ACRE", PlacedCreatureRecord

"ACHR", PlacedCreatureRecord

"SCPT", ScriptRecord

"MISC", MiscItemRecord

"FLST", FormListRecord

"WRLD", WorldRecord

"LAND", LandRecord

"CELL", CellRecord

"RCPE", RecipeRecord

"CONT", ContainerRecord

"PERK", PerkRecord

"AMMO", AmmoRecord

"AMEF", Record has no refs!

"EXPL", ExplosionRecord

"ENCH", EnchantmentRecord

"ALCH", AidRecord

"GMST", GameSettingRecord

"PROJ", ProjectileRecord

"BPTD", BodyDataRecord

"IMAD", ImageSpaceModRecord

"NPC_", NPCRecord

"SPEL", ActorEffectRecord

"DIAL", DialogRecord

"NAVM", NavMeshRecord

"SOUN", SoundRecord

"RACE", RaceRecord

 

If your mod or patch only consists of override records of the above type, it is likey fully compatible to be merged away by modfusion.

 

 

PS: I would rather make modfusion able to read fmods/nmm files then export them. I have also considered making an 'automated' install script maker that would make a best guess install script based on the contents of each ESP and looking at the basic folder structure (ie: only include this ESP if the masters it relies on are detected in load order, warn user if a master all files need is not included (mod usless), etc)

Edited June 18, 2012 by Cyberlazy

[pippinstrano]

Ok, here is the scenario, which happens often enough -

 

1) I install mod A, which installs meshes and textures

2) I install mod B, which overwrites some of mod A's meshes and textures. NMM tracks which files have been overwritten

3) I run ModFusion, which overwrites some of mod A's meshes and textures. NMM isn't aware of this

4) I uninstall mod A using NMM. It won't remove the files updates by mod B, but it will remove the meshes and textures that ModFusion had overwritten from mod A

 

The mods you have written will probably not be largely effected by this sort of thing, because you usually add files rather than replace existing ones (maintaining compatibility). However, since the objective is to have ModFusion used by other mods (I'm planning on fussing at other mod authors to support it so I can get a super short load order), this problem needs to be addressed.

[Cyberlazy]

I wonder if I can get modfusion to work with NMM's install tracking data. Right now im just working on getting modfusion to be able to uninstall mods..

[pippinstrano]

I was thinking and the requirement that Modfusion be run after each mod addition or deletion in NMM / FOMM is reasonable enough (uHUD is similar). It also should provide an opportunity to correct any problems caused by the seperation between NMM / FOMM and Modfusion. At some point being able to use NMM's tracking data would be excellent, but yes, one step at a time. Thank you for all your hard work on this!

[Odyseus77]

Hello, people.

 

And that's why I suggested not to waste time with the implementation of installers. ModFusion have to consider the installation cache of NMM/FOMM, either by creating its own cache or by creating complex scripts/bat files. And even doing so, all that is destroyed by the CRC check that Wrye Flash does. Furthermore users who already use a mod installer/manager have no desire to try a third mod installer/manager. And 90 percent of authors do not even take the trouble to make its mods compatible with the two existing installers/managers. I even think that the title of this post drives away potential readers. IMHO Too many headaches to no avail.

 

My initial intention with this post was to report any bugs that I have found using ModFusion. But as I have not found any bug, I will briefly describe a situation that ModFusion helped me to solve very quickly. I was observing that a lot of my weapons were firing invisible projectiles. On top of that, I was having crashes at a specific point on the map. Every time I walked into that cell, a NPC who spawn there produced an instant ctd. Long story short. I was able to narrow the problem to a plugin created by myself, in which I had "fused" a bunch of patches manually. This plugin screwed by me, contained a lot of leveled lists with lots of <Error could not be resolved> records. My first thought was. "Oh, no!! I have to reinstall all those patches, and merge them manually again!! Not this time!!" So I used ModFusion to create a single patch. I just had to run ModFusion and I got a patch created on the fly based on my load order. Simple, without installing anything nor merging plugins manually*.

 

After doing all this I wanted to know why this plugin had all those <Error could not be resolved>. The problem turned out that I had changed the load order of one of the masters. *sigth*

 

*I use FNVEdit to merge plugins manually, because when using FNV Plugin Utility to merge plugins automatically, sometimes I've found duplicates FormIDs inside the merged plugin.

 

@ JeremySargent: From what I said above, you better not take my load order very religiously!! LOL I'm like you, my knowledge is based on good documentation. And yes, I have to admit that the Wrye Bash documentation is a bit esoteric and above that is based on another game (Oblivion). But I also have to admit that if they had entered into more detail on what they have written, that documentation would be kilometric!! LOL

 

About patches. People seem to only see black or white. When they read that a mod has conflicts with another mod, it seems that they think "Oh, no! My computer is going to explode!!" LOL 50 percent of the conflicts that I have are with NPCs who end up having different hair styles, eyes, etc. I do not even bother to fix those conflicts anymore. And 90 percent of the patches that I use are to extend the functionality of one mod to other mods that I use. It's really very simple. What complicates everything is the amount of patches and the fact that everything has to play nicely with everything. Here is where I hope ModFusion will solve the problem.

 

:thumbsup:

Edited June 18, 2012 by Odyseus77

[pippinstrano]

As an aside, I hadn't noticed this in your post earlier "I just want 'Run program. Run game'. Any simpler would require me to visit the users house to do it for them." LOL!

[Cyberlazy]

So, My planed uninstall process is like this:

when installing a mod, it will record the install log in a file in a subfolder, ie installs\Craft Pack.log

Apon detecting that mod is no longer installed (enable set to false, or mod missing) it will uninstall it and reinstall any files it overrided. Mod can be uninstalled by renaming its configuration.ini to .bak or anything else, by deleting it or by draging and droping its ini onto modfusion.

 

I would store the install info in the folder of the mod itself, but I wanted users to be able to outright delete a mod or its configuration.ini and still have my program uninstall it correctly, as opposed to needing to uninstall it before deleting it.

 

I also could put all the install info into one file, although that carrys a slightly higher risk of getting corrupt, but I guess the chance of corruption should be low.

 

PS: Fnvplugin merges leveled lists incorrectly, it removes duplicate entrys that are often used to bias the list chances. ie if something has 2 varmint rifles and a service rifle, after fnvplugin it will have 1 varmint rifle and 1 service rifle.

Fnvedit merges formlists incorrectly: it sorts them, this will totaly ruin weapons and make them unable to shoot anything using the default projectile if an ammo with a non default projectile is 1st in the ammo formlist.

Edited June 18, 2012 by Cyberlazy