Fomm - Custom Build - 0.14.11.13

[blisst]

sorry I thought I was being clear about the past issues i'd experienced in earlier builds.. but when I started reading your replies It became clear that wasn't the case.. my bad

 

[RitualClarity]

My thoughts on the next gen archive management are here.

 

The tl;dr version is I want FOMM to stop digging around in the archives so much (it's slow) and use file CRCs/hashes for most of it's work, while also rolling up unknown and vanilla assets so it's always sure to be able to recover them. It has some other cool features as well.

 

It looks good... from what I can understand of it that is....

Keep this up it won't be FOMM anymore....

 

I know you are still working on the back end but have you looked at MO? I like the profiles that can be created in that manager. One can run a load order, import that same load order saves if needed and install new and improved mods. If they don't like it just change back to the old profile and delete the old on.  A gamer can have different load orders for different play through. Conflict mods, no problem just don't have them active in the same profile. You can still use them in different profiles without having to install and uninstall or mess or worry about save corruption.

 

If FO4 is going in the same direction as Skyrim is. The saves data will needed to be addressed. Currently MO is the best option for Skyrim (barring possibly Wyrebash)

 

Just some thoughts .. and some redirection back to what this thread really is all about...

[prideslayer]

I haven't looked at it yet, but I remember the earlier discussion about it. I want to avoid the junction point etc. fiasco for now, but you're right; the stupid skyrim engine script dirty save gibberish is going to have to be addressed, if beth doesn't address it, and it's doubtful that they will.

 

MO can handle that. The new system I'm thinking of for FOMM can as well, though it wouldn't be quite as elegant. The other stuff, basically the same. MO will be faster at switching between two package configurations thanks to the junction point stuff, but otherwise, they should have the same capabilities. If the OS poll keeps going as it is, I may revisit using them or something similar / combination.

[RitualClarity]

I don't think speed would be an issue with switching. So long as it is stable and easy to use for the noobs it should be just fine. Glad to see you have considered those issues.. Who was I to even think that you hadn't...

 

Currently the one issue with MO is the overwrite folder keeping stuff there. This confuses those users and causes problems. Not as many as would be without the manager but still a few anyway. I imagine you would have that cleaned up at the end of configuration...

[niveuseverto]

MO can't install mods like Unified Hud (that strictly depends and checking if any other mod is installed)...

[ChianasGeek]

 

@KainsChylde

 

That's a feature, not a bug

You sure you aren't thinking of a certain sexout plugin?

 

 

I was about to go to bed - thinking wasn't how you could describe my neural state at that point, lol

[RitualClarity]

MO can't install mods like Unified Hud (that strictly depends and checking if any other mod is installed)...

 

http://forum.step-project.com/showthread.php?tid=3578

 

It can be installed using FOMM through MO.

 

 

Save all mods that rely on Unified HUD until last and install them with FOMM. These mods will be written to the overwrite folder in one big mod, which will allow Unified HUD to see the Hud menu xml files.

I have done just that in FNV. I later went back and removed (uninstalled the files using FOMM through MO again) after creating the mod. It was tedious but could be done and in the end it worked fine.

[niveuseverto]

IMHO it's a bit complicated...

[RitualClarity]

Yes it is quite complicated. Doable but complicated. This is where newer users... to modding that is. Have difficulty setting up their game folder. Similar to Wyre Bash users fully using bash to its full potential. Simple mods installations are easy to deal with in MO or Bash. Complex or other task show the difficulty.

 

The only real allure MO has for me is the fact that I can load multiple versions and configurations of mods and click and run them into profiles at a moments notice. Once a mod as been *prepped* it is ready for use from that time on with just a click. There are other advantages like prioritization of  files texture /meshes files etc over others inside the mods. Not a big deal. I can spend a few minutes extracting and drag and drop the preferred files to my suiting without that feature. This just makes that easier.

 

All other managers basically only run one set of active mods and one series of saves. Simpler but requires you to have to uninstall the mod, install the changed or updated mods, configure the load order, and start new ( in skyrim because of the persistence save issue) All while being concerned with what s overwriting what. MO you can change the files as needed until you get the correct files regardless of if they are in BSA or loose. Oh, it doesn't seem to have a performance  benefit having BSA over Loose fles in MO as opposed to other managers. might be how MO presents each set / mod to the game.

 

FOMM is generally just dead simple to operate use and create mods with. Has the tools needed all self contained and ready to go. Both have their pluses. I only mentioned that manager because it is getting quite a bit of use particularly in Skyrim and it might have some idea/ features that might be desirable if Pride Slayer and/or yourself decide to completely rewrite the entire mod manager .....

[prideslayer]

I'm not surprised it's taking off for Skyrim. The script debacle they introduced with that engine makes something like that all but a requirement. I'm hopeful the new archive design can solve the problem as well, and also integrate the ease-of-use in switching you mention. As I said, it'll be slower if I don't use junctions -- because they're lightning fast, at the cost of using a lot of disk space.

[blisst]

re: Pride's thoughts..

 

1)... Invisible packages:

I'm sure the TTW team has plenty of info on these the 6 different versions of Fo3 excluding localizations and users over there might be a good resource for building the default HASHes for the various versions or you to pre-supply.. Personally I can supply the steam eng-us hashes for skyrim, FNV and fo3..  I might even have access to the GFWL disc for Fo3 through a friend but no guarantees if he's still got it.

 

2)... I really like the idea of the (re)build list.

 

 

New feature requests:

1).. "Unify" .fomod filenames with mod metadata

there's a number of mods out there with really bad filenames but great metadata in the fomod script.. it'd be nice if there were a way to rename the filename of the fomod archive to #Desc_#Ver.fomod within FOMM. Additionally I like to edit metadata sometimes but there's no convenient way to change the archive name when you do so.

 

2).. "Upgade" Fomod archives.

Some kind of feature that would allow you to permanently add on a patch or hotfix archive into a main install archive. I do this manually all the time but I sometimes forget to rename the archive to reflect the patches applied, would be nice if the mod Manager could manage mods in this fashion. Output archive: #desc_#ver-Patched_#ver.fomod. An d a background highlight of those would be epic.

[prideslayer]

re: Pride's thoughts..

 

1)... Invisible packages:

I'm sure the TTW team has plenty of info on these the 6 different versions of Fo3 excluding localizations and users over there might be a good resource for building the default HASHes for the various versions or you to pre-supply.. Personally I can supply the steam eng-us hashes for skyrim, FNV and fo3..  I might even have access to the GFWL disc for Fo3 through a friend but no guarantees if he's still got it.

What I'd need are hashes of the files from non-english and/or nogore versions. I don't have those. Of course I can put a button in there that says "regenerate vanilla hashes" and just let the first batch of beta testers submit them back to me. That will probably be easiest.

 

New feature requests:

1).. "Unify" .fomod filenames with mod metadata

there's a number of mods out there with really bad filenames but great metadata in the fomod script.. it'd be nice if there were a way to rename the filename of the fomod archive to #Desc_#Ver.fomod within FOMM. Additionally I like to edit metadata sometimes but there's no convenient way to change the archive name when you do so.

I can't rename the fomod file in any meaningful way, since the archive FOMM operates on is not the one you downloaded, but a copy. The filename won't show up in the manager unless there is no fomod information to display.

 

2).. "Upgade" Fomod archives.

Some kind of feature that would allow you to permanently add on a patch or hotfix archive into a main install archive. I do this manually all the time but I sometimes forget to rename the archive to reflect the patches applied, would be nice if the mod Manager could manage mods in this fashion. Output archive: #desc_#ver-Patched_#ver.fomod. An d a background highlight of those would be epic.

There will be something like this, but the naming will be internal to FOMM. If you want to take everything that's installed and wrap it up into a standalone fomod to store elsewhere, it'll be able to do that on demand, and you can name the file anything you like. Some kind of default filename can be provided.

[RitualClarity]

I'm not surprised it's taking off for Skyrim. The script debacle they introduced with that engine makes something like that all but a requirement. I'm hopeful the new archive design can solve the problem as well, and also integrate the ease-of-use in switching you mention. As I said, it'll be slower if I don't use junctions -- because they're lightning fast, at the cost of using a lot of disk space.

 

That is the reason I mentioned that. Especially since it is highly likely that FO4 or any other edition of TES created will follow on that engine or one very much like it. Doubt they will remove those issues for us modders convience. Sometimes I imagine them dreaming up ways to make modding harder for users.

 

Perhaps when you reach that level to try working on this new feature you mention ask around the forum if people would prefer speed over hard drive space use. Many might just prefer speed. Me it don't matter one way or the other. I just want something that is reliable. The rest can be worked around.

 

[zippy57]

 

I'm not surprised it's taking off for Skyrim. The script debacle they introduced with that engine makes something like that all but a requirement.

That is the reason I mentioned that. Especially since it is highly likely that FO4 or any other edition of TES created will follow on that engine or one very much like it.

 

Maybe it's just me, but I can't see the script thing as anything other than quietly but strongly discouraging modding. What possible advantage does doing that give to how the game performs? It even makes the fancy Steam Workshop integration useless.

 

I've also been curious if there's a way to remove the scripts from the saves, kind of like how Wrye Bash could do certain things to clean up Oblivion saves.

[RitualClarity]

 

Maybe it's just me, but I can't see the script thing as anything other than quietly but strongly discouraging modding.

Wouldn't surprise me if they didn't release the tools to modify the next game the release.

 

 

[Thenryb]

What is the utility of having FOMM remain open during a game session? The answer may be self-evident to all but me.

[prideslayer]

What is the utility of having FOMM remain open during a game session? The answer may be self-evident to all but me.

Those of you that don't benefit from it have to click one extra thing when you're done. "Close." Those of us that do benefit, it saves us hundreds of clicks and the time involved. We modders don't get to "play" much. We jump into the game for a few seconds or a minute to test something, then we're back out and back into the GECK.

 

Having to start FOMM every time to fix the load order or test the package reinstall gets annoying fast.

[ChianasGeek]

And further to Pride's answer... I'm sure that FOMM has such a small memory/resource footprint that it has no impact on actually playing the game, by leaving it there in the background.

[Thenryb]

Thanks. I really was not complaining-just curious. I can see that it would be useful to players as well as modders troubleshooting to determine which mod might be causing a problem.

[prideslayer]

If enough people think it's a problem, I can add a setting to change the behavior. On a completely philosophical side, I hate it when any program violates the principle of least surprise. A program closing when you didn't ask it to is surprising.

[maybenexttime]

You must get this version of FOMM over the nexus one.

[Thenryb]

I have been using this version and its not closing is not a problem -seems to be working as intended. If I find that leaving it open causes too big a footprint on my old lame-ass computer I will close it.

[niveuseverto]

You must get this version of FOMM over the nexus one.

 

Soon nexus one and this one will be same =)

Just need to finish with main work and complete merge and few features.

[jaam]

The original only closed for Fallout NV, not FO3

[Thenryb]

I downloaded and installed this in a separate folder. It launches the game just fine, but clicking on the esp files listed in the load order does nothing. Do I need to install this in the same directory as the Nexus FOMM and overwrite?