Jump to content

Fomm - Custom Build - 0.14.11.13


Recommended Posts

Guest carywinton

If the installer allows for choice of directory, etc. then this is a fine method. As to being able to place FOMM in it's own custom location (Loose files install), one possible explanation for this method would be if you wanted to run independent FOMMS, one for FO3, and one for FNV, etc. but I see no real purpose for this.

Link to comment

 

I prefer the loose files. I have grown to like placing it where I want it to be and not having an installer etc.

Ok... why?

 

You can place it wherever you want it via the installer, too.

 

True however in the past this meant that it was also registered in the windows registry as well. Loose files aren't ..  have had some issues with registries and windows recently..

If the installer allows for choice of directory, etc. then this is a fine method. As to being able to place FOMM in it's own custom location (Loose files install), one possible explanation for this method would be if you wanted to run independent FOMMS, one for FO3, and one for FNV, etc. but I see no real purpose for this.

Which without a registry entry one can have different versions and even different installs of the FOMM so long as you don't activate them at the same time.. in theory.. of course.

 

It isn't necessary of course. As I stated a installer would likely cut down on noob installation errors.

Link to comment

... in the past this meant that it was also registered in the windows registry as well. Loose files aren't ..  have had some issues with registries and windows recently...

 

Any program you run is going to get entered in the registry the first time you run it. That's how the registry works.

Link to comment

All the installer puts there is the list of DLLs the program uses (it does this so they can be shared), and the uninstall information. If your registry is corrupt though, you're going to have much bigger problems.. ;)

 

You can still use the installer to install different versions to different places, at least, I think you should be able to.

Link to comment

All the installer puts there is the list of DLLs the program uses (it does this so they can be shared), and the uninstall information. If your registry is corrupt though, you're going to have much bigger problems.. ;)

 

You can still use the installer to install different versions to different places, at least, I think you should be able to.

 

I had memory problems which I found out because of strange program errors. It is entirely possible that the registry is corrupt. It seems like it is working correctly.. for the time being.. However recently it screwed up my Steam install again and gave me strange issues. ( yes I have checked for virus and malware with some heavy tools just to be safe)  I will likely just reload the OS from scratch as I can't even be sure that my image was from a good install. Memory being so important for the processing of files and all. It is entirely possible that there were memory errors from the beginning just slowly getting worse as time went on.

 

Cool I could use that installer to install different versions to different places. However it isn't really necessary as far as I can tell so long as it can managed both FO3 and FNV files where it is installed still and you haven't' removed that feature. I might want to run a clean FO3 modded game by itself.. ;)

 

@Pride

Yes Pride.. you are probably thinking why is the crazy alien so interested in FOMM and its installation and such if he is using MO... Well.. It is simple. I want to do some modding even if it is personal. Look at scripts and the such.

 

I have three computers other than my gaming rig that I can choose. (They may be older but should still be good enough to play FO3/FNV enough to test and mod on. When I do install the OS and configure I won't be using MO on them. I need a direct, dead simple reliable way to install mods and uninstall them.. I need them in the Data folder viewable by all programs all the time without any issues.

 

FOMM is the only reliable tool that I know of that can work with all the other tools correctly and reliably. It is also extremely well supported and dead simple. There is simply no other choice hands down.

Link to comment

If you suspect memory issues, I suggest membest86+. It can take a long time to run, but it's the most thorough tester there is to find subtle defects in memory modules or CPU cache.

 

The FOMM installer doesn't do anything different from the loose files version when it comes to FONV vs FO3. The main differences for a user are just providing an uninstaller, and also doing a check for .Net 4.0. You can still manage FO3 and FONV just like before, in whatever directories you like. If you use FOMM alongside MO, that should work too, though you'll have to change the FOMM directories for each MO profile or whatever they may be called. I'm going to check and see if MO has an API I could call into. If it does (or if the author can add one) it would let me automatically switch FOMM installlog files depending on the active MO profile.

 

From my perspective as a developer, the installer is much better, since it can automatically ensure that the right DLLs are included in the installer and things like that. Sometimes I forget to copy new ones when making the loose file zip download, or I forget which files are actually needed, which ones FOMM creates itself, and which are just visual studio "junk" files.

Link to comment

I used Memtest... I found errors.. talked to a person I know.. Manager of a computer tech shop. Showed him the screen shot photo of the errors.. He laughed.. I got new memory a few weeks ago.. I have been using the computer and even re-tested the system, hard drives and such and all come up great ( hardware wise) and so there don't seem to be any more problems however the OS and sometimes weird issues have come up.. This is likely due to some corruption of the programs etc. Dont' know how long that memory was bad or how deeply it effected the computer.. I had literally 100s of errors. So many that manager was surprised my computer still worked. I decided to test the hard ware and such to be sure there wasn't some other hardware issues so that I wouldn't end up having to replace something else before I reinstalled my OS again.

 

Cool on the installer.. I can use it for FO3 and FNV at the same time, well not exactly at the same time ;) but you get the idea.. lol.

 

For the record I fully understand why the installer has been chosen. It is better for the end user. I hadn't however realized how much of an aid it was for the developer and keeping it clean.

Link to comment

 

I'm going to check and see if MO has an API I could call into. If it does (or if the author can add one) it would let me automatically switch FOMM installlog files depending on the active MO profile.

A member here named AweFullArchdemon is in contact with the dev of MO regularly. He might be able to help you get in contact for info exchange. Who knows maybe some compatibility might be able to be made?

 

Who knows.. maybe you might look and like the Profiles that MO has? :D.. Maybe create your own options? Change Profile and install log files on the fly?

 

If you do decide to rewrite the entire manager... there are lots of new tech that can be taken advantage of and so long as it is compatible with the old system / scripts .. win/win With a clean base that you understand .. the sky is the limit.. ;)

 

Link to comment

I already sent him a PM on nexus explaining what I'd like to do -- basically have FOMM determine if/when MO is managing a game, so it can automagically switch profiles itself. I've thought about moving the FOMM files into the game dir so that MO can manage them along with everything else, but that's just more potential pollution and 'junk' in that directory. It might be ok if I limited it to just an FOMM dir.

 

I have thought about the profile thing, and I intend something similar to FOMM, I just need to get on with the archiver rewrite. It's a daunting task.

Link to comment

 

I've thought about moving the FOMM files into the game dir so that MO can manage them along with everything else,

Perhaps instead of the Game directory.. moved into MO itself.  The clutter would instead be inside a folder of MO.. Much like NMM is. With it available there .. Then perhaps a switch in FOMM that MO can activate as opposed to FOMM realizing that something has changed. As I understand it .. FOMM is switched on through MO. It likely wont' see any changes as it wouldn't be running otherwise.

 

I had thought of this when I started playing FNV again. (one reason I was interested in the loose files, I thought it would be easier to manage those files this way) I would install those HUD mods and such that I needed and get the info I needed then uninstall them but keep FOMM and files intact in case I needed them again. I could even use that same process to create compilation of Sexout mods etc as well.

 

 

I have thought about the profile thing, and I intend something similar to FOMM, I just need to get on with the archiver rewrite. It's a daunting task.

Yippiee.. you made my day just by considering this.. It is the main reason most people have started using MO. Being able to play a character and not have to retire him/her to play another one is incredible. People get attached to their character. I really miss some of my old characters I had in FNV. I wish I still had them and what I did to develop them.

 

I can only imagine the amount of work the archive needs for this.

Link to comment

 

I've thought about moving the FOMM files into the game dir so that MO can manage them along with everything else,

Perhaps instead of the Game directory.. moved into MO itself.  The clutter would instead be inside a folder of MO.. Much like NMM is. With it available there .. Then perhaps a switch in FOMM that MO can activate as opposed to FOMM realizing that something has changed. As I understand it .. FOMM is switched on through MO. It likely wont' see any changes as it wouldn't be running otherwise.

 

The only way MO could tell FOMM something has changed and have it be meaningful is if it modifies FOMMs files, which isn't "safe" while FOMM is running -- not right now anyway. I think you're overthinking my goal here though. It will be "easy" for the two to interact as long as only FOMM is used to manage what packages (fomods/fomodready), and MO is used to manage the FOMM modfiles.

 

I would have to tl;dr explain just how FOMM does its package management for you to understand why this is, if you already don't, but the two should play very nicely together if you just use FOMM for the mod installs/activations, and change the FOMM mod directories in the settings page to directories that MO is managing -- which I assume is the entire 'game dir' for a specific game, not just data.

 

If MO is managing "c:\Program Files...\Fallout New Vegas" then make a new FOMM dir there and move the two FOMM configured directories inside it.

 

I had thought of this when I started playing FNV again. (one reason I was interested in the loose files, I thought it would be easier to manage those files this way) I would install those HUD mods and such that I needed and get the info I needed then uninstall them but keep FOMM and files intact in case I needed them again. I could even use that same process to create compilation of Sexout mods etc as well.

I think you are really mixing up the FOMM install directory, and the FOMM mod management directories. The former should not be managed by MO. The only reason to try that is if you wanted to use different versions of FOMM for different games like one version for FO3 and one for FONV. There's no reason to do that, that I can imagine, except if I introduce a bug in FOMM that breaks it managing one game and not the other. I think those days are behind me.

 

 

I have thought about the profile thing, and I intend something similar to FOMM, I just need to get on with the archiver rewrite. It's a daunting task.

Yippiee.. you made my day just by considering this.. It is the main reason most people have started using MO. Being able to play a character and not have to retire him/her to play another one is incredible. People get attached to their character. I really miss some of my old characters I had in FNV. I wish I still had them and what I did to develop them.

 

I can only imagine the amount of work the archive needs for this.

 

The archive system needs completely rewritten, that is my plan. It's just too big of an error prone mess to continue with, and does too many stupid things during package activation/install.

 

One of my goals in future versions of FOMM is for them to even detect (to the extent possible) manually installed files, and give the option to wrap all of them it finds up into a FOMOD right then and there. It also needs to do some signature checking (CRC32, md5, whatever) on the files it *thinks* are installed, so it can alert you if they've been replaced by something else.

 

Big dreams.. big dreams. Not sure how long this is all going to take. Got lots on my plate. :)

Link to comment

 

It will be "easy" for the two to interact as long as only FOMM is used to manage what packages (fomods/fomodready), and MO is used to manage the FOMM modfiles.

Yes you are correct from my understanding with the above statement. If FOMM is in control of it's files and MO manages the mods installed. However .. MO users wouldn't have the same features available to them for those FOMM installed files. As I understand it there will be limits on the conflict resolutions with this process. To get the best benefit of MO a user needs to have all files controlled and essentially installed by MO except of course the main game files.. ;)

 

One example is shown in Gophers SKSE ( Somewhere around 17:00) installation video for MO. If SKSE is installed manually with the data / scripts into the game all is good. However any mods that are in conflict with any script from SKSE isn't easily noticed as the main panels don't show those conflicts currently. If FOMM installs mods this way it will be installed directly into the Data directory like the script fles from SKSE and the user will likely experience the same hidden conflicts that Gopher's example shown. Except with potentially 100's of mods installed through FOMM hidden conflicts will be greatly increased.

Link to comment

Well obviously the "right way" is to only use one of them at a time. IF you want to use both together though, my recommendation is:

 

1. Install and setup MO first.

2. Setup FOMM, and in its configuration settings, change the "Mod Directory" and "Install Info" settings (under settings in the game tab) to directories under the directory managed by MO -- that is to say, for example, set those two paths to "c:\program.....\Fallout New Vegas\FOMM\mods" and "c:\program...\Fallout New Vegas\FOMM\Install Info"

3. Use FOMM (and only FOMM) to manage the actual fomods installed.

4. Use MO to manage things not installed by FOMM, like NVSE, ENB, etc.

 

All the FOMM managed stuff will be 'hidden' from MO, however, the MO profile switching should work -- and (if you remember to exit FOMM first), it will even switch between different FOMM "installs" as long as MO is managing the whole game directory. In step 2 you may have to do something in MO to tell it to 'manage' that FOMM directory with the profile.

 

The problem in the video doesn't seem related. He installed SKSE with the installer (did not install it with MO) and then installed (with MO) files that conflict with SKSE and wasn't warned. That's normal for MO and FOMM too for that matter. Conflicts with "vanilla" are suppressed, and those SKSE scripts are considered "vanilla" if they came from some place other than the mod manager.

Link to comment

Wait.. I now understand what you were trying to do when contacting MO's creator..lol.. It is clear now.. Yes.. the best is to have one manager manage it. You were trying to set something else up outside of MO for those that wished to use MO for some select mods. so that FOMM would be able to switch.. Oh.. I see now.. I am a bit slow today it seems.  I am on the same page now.. It would be a cool option for those users that feel the need to use FOMM for those mods like HUD mods and the such in a compatible way with MO without having to go through that god awful install process for those mods that need FOMM..

 

 

basically have FOMM determine if/when MO is managing a game, so it can automagically switch profiles itself.

 

2 Thumbs up.. especially the "automagically" process. :)

Link to comment

Wait.. I now understand what you were trying to do when contacting MO's creator..lol.. It is clear now.. Yes.. the best is to have one manager manage it. You were trying to set something else up outside of MO for those that wished to use MO for some select mods. so that FOMM would be able to switch.. Oh.. I see now.. I am a bit slow today it seems.  I am on the same page now.. It would be a cool option for those users that feel the need to use FOMM for those mods like HUD mods and the such in a compatible way with MO without having to go through that god awful install process for those mods that need FOMM..

 

basically have FOMM determine if/when MO is managing a game, so it can automagically switch profiles itself.

 

2 Thumbs up.. especially the "automagically" process. :)

 

I still think you're being a bit.. slow. That doesn't sound right. Let me try to explain in a sort of step by step, how it would work for the users.

 

The current (manual) way:

1. You install MO as normal.

2. You install FOMM as normal.

3. Set FOMMs install info directory (but not its 'mods' directory) to somewhere inside the game directory, managed by MOs profile stuff.

4. Proceed to install mods with FOMM..

 

So now when you switch to a new profile, MO "should" remove/hide the FOMM directory you setup in step 3. When you run FOMM again in the new profile, it will not have any active mods in it. It should still have all the mods available for activation though. You can activate a whole new (different) set of mods now.

 

Now quit FOMM and switch profiles in MO again, then start FOMM.

 

You should now have no active mods in FOMM, or the mods you previously setup with FOMM while that MO profile was active.

 

----------------

 

That's a sort of long winded way of doing things, and requires manual intervention by the user, at least to change the FOMM directory setting and ensure MO is managing that directory properly.

 

So what I'd like to do instead is have FOMM 'hook' into MO, if it is available. FOMM could then keep its install info files where they already are, and switch them to its own version of a "profile" when MO tells it the profile has changed. This would keep the FOMM mod file junk out of the game directory, and allow FOMM to 'notice' when the MO profile changes without you having to quit FOMM and start it again.

Link to comment

 

I still think you're being a bit.. slow. That doesn't sound right.

You are correct again. I am not a coder, programer or even a modder so I don't fully understand all the processes. That being said I was working on a very large explanation of various aspects of MO and where and what might go wrong. As I stated I am not a programer. So instead I am responding that I would strongly encourage you to install and use MO for testing purposes. You have Skyrim. MO is really highly supported in Skyrim and shouldn't mess with your other development and gaming in FNV.;) I believe you stated that you had it and hated it . You shouldn't need anything but some basic mods .. Sexlab, supported body, FNIS, SKSE etc and a few basic texture and quest mods to round out the install. 30 mods or so to get your feet wet and see how this manager works. Then you will see what might be, or might not be problems r/t FOMM integration and be better able to address those issues.

 

On a plus side.. you might start to like Skyrim again.. lol. If it wasn't for MO I wouldn't have gone back and given Skyrim the time of day after my horrible experience with it and NMM. Oh also Ashal and some skyrim modders use MO as well. They can be a valuable resource for configuration etc. MO is more complex manager than FOMM or NMM.

 

Link to comment

I have it and do 'hate' it (I hate the instability and stupid hoops, mostly), but I've been playing with it lately anyway with just NMM -- it gets me by for skyrim. I'll have to back up the entire data directory before I even think about doing that -- My Skyrim install is unstable enough as it is, it's finally to the point where it's actually more common for a save to load correctly than to instantly CTD me -- I feel like I've made progress!

 

I intend to test MO and I have no problem doing it with FONV. I have a backup FONV data dir that is pristine (no active mods) and a similar backup of my FOMM dirs. When I need to test stuff like that I just rename the current ones to '.live', copy/paste the backups, and rename them to their correct names.

 

In other words, I (more or less) do the MO thing manually -- or the thing about MO that seems the most appealing to me. The dragging/ordering stuff and the rest of it, I don't have much use for, but I'm already "old hat" at getting my stuff ordered and installed in the right order -- and FOMM works great for me here. At least, it does since I added that "Yes/No to Mod" option. ;)

Link to comment

The dragging/ordering stuff does great in resolving the issues r/t crashes. Also check into the "conflicts" where you can hide any files that are causing problems. You can easily reactivate them later if needed. Those two systems have improved my experience in Skyrim to a point where crashes or instability almost never happens.

 

It is good that you will test MO. However testing with Skyrim is probably the easiest for newcommers to MO however your experience with FNV and the mods you are using will give you a great benefit in  setting it up and conflict resolution. Also you already know the install order by heart. ( left side of MO.)  Normally I would advise people to use Skyrim/MO. ( mostly because FOMM isn't used for Skyrim.. yet :))

 

I was like you.. When I first started using Sexout mods I had a hell of a time. I finally created a folder and numbered the install order so that when I reinstalled the mods they would be in proper order to avoid the conflicts. However that being said.. it is so much cooler to be able to install what ever you want and "drag/order' the files and then hide anything that can't be resolved with that.. NO more .. oh crap I should have installed that before this.. Dam..

 

 

Link to comment

The problems I run into in skyrim with NMM generally fall into two categories..

 

1. Things like those stupid fucking script 'assets' like JContainers and papyrusutil. There are standalone installs, some are included with mods and may be older/newer versions, some are included in sexlab and same thing. The problem is that they aren't backwards compatible, especially JContainers I've noticed. If some mod needs v1.2.3, it will NOT work with v2.3.4, even though some other mod you have requires that one. There is no mod order/load order that can fix this.

 

2. The bullshit in savefiles from disabled mods. Every time I disable any mod now, first thing the savegame gets is a trip to the scalpel to delete all the old crap left laying around.

 

There's.. nothing MO can do to make my skyrim experience any better I don't think. NMM "works" ok enough for me with that game, for now, and I've become all too familiar with the savegame scalpel and "mod explorer for nmm".

 

Angry ranting protips for Skrim modders.

 

 

1. Stop including these libs, and others like them, in your mod install files. All it does is raise questions about which ones is the right one to use.

 

2. If you're the author of one of these libs, FFS, make the new version backwards compatible -- or just don't make a new version. You don't see me breaking every fucking mod that uses NX every time I release a new version of it. I know it's work to make it compatible. It's not impossible.

 

3. If your mod is going to include scripts that can break the goddamn game if they remain in the savefile after your mod is gone, do us all a favor. Put a tiny little check in each one of those scripts that looks for your mod with GetModByName or something, and if your mod is no longer there, clean up and die! You can put this in a function and call it at the start of every one of your script blocks, at the start of every loop, etc.

 

4. Just about every one of you assholes is putting "put my mod last to avoid problems!" and "use only on a save you don't care about!" in your instructions? Do you really think everyone is going to run with ONLY your mod active (to meet requirement #1) and/or start an entirely new game (to meet requirement #2)?? How about you do some testing and fix your goddamn bugs so you don't need such unrealistic instructions/warnings.

 

ok.. ok.. deep breath.. not gonna hulk rage over this shit *again*.. ;)

 

 

Link to comment

 

1. Things like those stupid fucking script 'assets' like JContainers and papyrusutil. There are standalone installs, some are included with mods and may be older/newer versions, some are included in sexlab and same thing. The problem is that they aren't backwards compatible, especially JContainers I've noticed. If some mod needs v1.2.3, it will NOT work with v2.3.4, even though some other mod you have requires that one. There is no mod order/load order that can fix this.

Several  solutions depending on your end result and desire.

 

Already installed mods in MO:

  1. drag to organize.. Optimum install order is my advise don't worry about  the conflicts you mention above this is for those mods that just need to have proper "install order" that is file properly overwriting the files above it. Normal process. May or may not solve the problem you are experiencing above. Worked for the Sexlab/SOS full paperus utility issue that recently occurred. There are other fixes below that will help solve any sticky or problematic file issues
  2. Open the conflicts and use the "Hide" option either in the conflicts tab or find the file in the file tree tab and delete it or hide depending on your needs. Find the object and right click .. You have various options including "hide'
  3. Open the mod and copy over the scripts or any other assets needed into another folder and create a mod using proper folder structure, create archive and install into MO. Now you can activate that mod as needed for whatever combination of mods you have. Most flexible. With this you can have 100 different versions of that script etc and just click on the one you need for the combination of mods you are using in that Profile. If you install this created mod after the mod(s) in question it will simpley overwrite .. done.

Install or re-install options:

  1. During installation or re-installation find that file and unclick it during the process and that file will never even be loaded into the game in the first place.
  2. Need a version of a script from a new mod but not the rest of the mod.. unlclick everything else and make sure you have changed the name the mod will be installed under.

I am sure that there are many other tricks that can be used to resolve that problem. All are only a few seconds of effort involving either editing the file installed or reinstalling the mod and making sure it isn't installed in the first place.

 

So Pride with a few minutes of effort .. find those random scripts and such that are pissing you off.. Install the best one that you need selecting only that during the install process.

Now those issues with items that have to be installed into the main folder.. That is another story all together. No manager can handle those anyway. I am sure you have ways of handling those files.. :D.

 

For those without understanding of this.. Install the files into the main folder again. Same files for example SKSE. While it is still highlighted click delete. Those files will go bye bye.. ;). Then you can install the new copy. Not really necessary if the files are the same and just being replaced but useful if it is an ENB mod and you need / desire to install another one and there are files in the main folder ( where the Skyrim.exe is located at)

 

2. The bullshit in savefiles from disabled mods. Every time I disable any mod now, first thing the savegame gets is a trip to the scalpel to delete all the old crap left laying around.

That I agree with you on. The only thing I can tell you is profiles is my friend here. If I have any question there might be a problem I copy that profile and play/experiment. I haven't really lost anything if it goes bad except the time invested on that profile. Fix.. no. However it isn't a MO thing. it is a Skyrim engine/ modding thing and is experienced by everyone regardless of how they install those mods..

Link to comment

I am sure that there are many other tricks that can be used to resolve that problem.

I didn't really explain it well. There is no "trick" to solve the problem. modA requires version 2.1 of some lib. Not 2.0, not 2.2, but 2.1. modB requires version 2.2. Not 2.1, not 2.3, but exactly 2.2. The two mods simply cannot coexist in a single load order.

 

The problem is that such libs like JContainers (or JContainer? I forget) exist in the first place with such bad backwards compatibility. Installing 3.0 will break every mod that requires 2.0, there's no way around it, they simply cannot coexist.

 

Only the lib author (by making the lib backwards compatible) or the mod authors (by including a renamed lib and using it instead) can address this. It's basically like these guys have reinvented DLLhell from scratch.

 

 

2. The bullshit in savefiles from disabled mods. Every time I disable any mod now, first thing the savegame gets is a trip to the scalpel to delete all the old crap left laying around.

That I agree with you on. The only thing I can tell you is profiles is my friend here. If I have any question there might be a problem I copy that profile and play/experiment. I haven't really lost anything if it goes bad except the time invested on that profile. Fix.. no. However it isn't a MO thing. it is a Skyrim engine/ modding thing and is experienced by everyone regardless of how they install those mods..

 

I know. My point was the major issues I have with skyrim can't be addressed by a mod manager. I'm not one of the unwashed masses that is constantly screwing up the load order, installing the wrong skeleton over the top of the right one, or the many other issues that mod managers try to help with. ;)

Link to comment

The bullshit in savefiles from disabled mods.

BETHESDA EMPLOYEE: The single person we have doing QA says the dragons are flying upside-down and backwards...

GAME DIRECTOR: Meh.

BETHESDA EMPLOYEE: ...the save system on PS3 is completely broken...

GAME DIRECTOR: Pfft. We're developing for PC, who cares?

BETHESDA EMPLOYEE: ...the PC user interface is awful...

GAME DIRECTOR: Bah. We're developing for consoles, who cares?

BETEHSDA EMPLOYEE: ...but at least the bookshelves work right.

GAME DIRECTOR: We'll have to fix that issue in one of the patches.

BETHESDA EMPLOYER: Sir, shouldn't we fix some of these bugs?

GAME DIRECTOR: Nah, the modders will fix them for us. We only recorded two lines for guards, what makes you think we have time to fix bugs? Instead, I want you and your team to copy all running scripts into the savefile so players will have to restart their game every time they change mods, have the game crash if more than ten hairstyles are available during character creation, and make sure the engine does things in a completely random order to make debugging more difficult.

BETHESDA EMPLOYEE: But... why?

GAME DIRECTOR: Because Bethesda, that's why.

Link to comment

I'm going to check and see if MO has an API I could call into. If it does (or if the author can add one) it would let me automatically switch FOMM installlog files depending on the active MO profile.

 

This would be very cool.

Temporarily removing fomm's install log files helped me sidestep a few issues there trying get get different hud combos needing uHUD under different MO profiles. New profile: back up & clear out the install info folder, install the hud mods, & run uHUD through MO-ified fomm, pack up the merge files into a "uHUD for this profile" mod. Works fine, no more griping from fomm about not finding files that were never added under that profile, or thinking mods are active that aren't.

 

I ran into a separate issue though. oHUD's install script of all things, run under MO-ified fomm, decided to directly overwrite an xml file from Flashlight NVSE. The original was removed from Flashlight's MO mod folder in doing so, and parked in Fomm's install info folder under 'overwrites', presumably for safekeeping if oHud is uninstalled and the original needs restored. (oHUD does this for a few other HUD mods too that it feels it can 'ihudify'.)

 

Removing the original and keeping it safe in that folder makes perfect sense in a non-MO environment, where files are dropped in and removed from the actual game's data folder. In MO this target folder is a virtual combination of files pulled in from the game data folder and the mod folders of the activated mods, depending on however you manipulate the install order. But MO's mod folder for Flashlight is now one file short and won't work if I activate it under a different profile, where the oHUD with the overwrite may not be installed. And if I did install oHUD anew the install script wouldn't detect the original file and so won't replace it with its own version either.

 

So if along with 'profilizing' the install log folder maybe this behavior could be changed to not do anything if the overwritten file was in an MO mod folder, you could be looking at complete compatibility.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. For more information, see our Privacy Policy & Terms of Use