Fomm - Custom Build - 0.14.11.13

[ritualclarity]

It seemed to perform more reliably and consistent the test that I recently done. Better than before, at least according to my memory. It might be a little slow but I am more confident that it will do the job now than I was before.

[ritualclarity]

I have bad news. Please don't shoot the messenger.

 

It appears that there is an issue with getting the male bodies to properly install with this FOMM. (Towards the bottom it is mentioned.)

 

I have replicated the same issue with the current version of FOMM (0.14.9.3) and it crashes during the installation of the Breezes body. Tested with Roberts as well. It asked if I wanted to overwrite the T6 body. I stated yes and another crash. This is the Sexout Version 2.6.80 Data

 

As you can see it is clean and pure load. I have nothing in the mods except Fallout NV and the DLC's.

 

The error code I got from windows was

AppData\Local\Temp\WER1571.tmp.WERInternalMetadata.xml
AppData\Local\Temp\WER5C70.tmp.mdmp

 

(Hope that helps)

 

Are you talking about this with this post in the OP?

 

Fixed installs done with XML that I broke with archive changes.

If so I am so embarrassed. Didn't realized or connect it with the problem until after I posted the issue.

[BruceWayne]

Edit: ninja'd

 

Anyway, I took the liberty to sticky this thread.

[ritualclarity]

:ph34r: Alien ninjas taking over :ph34r:

 

Take a look at the OP. Pride states that he has to fix some xml issues that was broken. Perhaps this issue is related?

 

 

[prideslayer]

That was a *did fix* not a *need to fix* but really? I broke it for sexout now? DERP.

[prideslayer]

Ahh just a permissions thing. Will be fixed in a minute.

Thank for the sticky, Mr Wayne.

[prideslayer]

Going a bit crazy trying to figure out why this is happening. Know what is going on (permissions error in 7zip extraction thread), just don't know *why*.

I put 0.14.9(.0) back in the OP as a stopgap for now. Too much headache to continue trying to figure this out right now.

All I think I know right now is that this is relate to the oddball system FOMM uses to handle 7zip stuff. The library (SevenZipSharp) was abandoned 2-3 years ago. The extraction routine is not threadsafe, so every time FOMM needs to extract a file, it creates a special 7zip handling thread for the given fomod (if one does not exist) and uses that for all calls. Something in there is blowing up.

The whole system is somewhat confusion. I don't understand how/why FOMM could be in a situation where it has two threads trying to work on the same fomod at the same time in the first place. For that matter, I don't know why it's threaded at all in the first place either.

A boilerplate archive system rewrite may be coming sooner rather than later as I'm getting tired of trying to figure out what the hell this thing is doing.

[KainsChylde]

If it makes a difference, I just did a reinstall of everything Sexout without a hitch. Had trouble with the tryout fomod for a moment, but then I quit getting impatient and actually read the error message. Went to the main window and checked all of the sexout masters (why do they install unchecked?) and tryout installed just fine.

[ritualclarity]

If it makes a difference, I just did a reinstall of everything Sexout without a hitch. Had trouble with the tryout fomod for a moment, but then I quit getting impatient and actually read the error message. Went to the main window and checked all of the sexout masters (why do they install unchecked?) and tryout installed just fine.

 

I noticed that as well. It confused me for a moment but was easy enough to follow. The prompt that comes up is clear.  It is just that us old timers aren't use to that.

[ritualclarity]

Second confirmation that the Sexout Data works on the recent fix uploaded.

 

A second question, however might be more proper in the Sexout Thread.

Why is it when you load the male bodies the prompt ask if you want to overwrite the T6 body? It was already installed? Before when I tested it for the individual on the other thread and uninstalled the mods (again) the T6 body remained and wasn't removed. This time I said no to the overwrite installed the bodies. When I removed them (again) the Sexout - T6.bsa still remained. It isn't getting removed when the mods is removed. A minor issue no really harm considering that it is a bsa and any body mod installed later would overwrite the files. Mostley an FYI

[prideslayer]

That BSA overwrite thing is due to a bug in .3 I'm just going to remove that download now, sorry I forgot.

It actually installed the BSA but said the mod install failed. It's one of the weird cases where you can have FOMM fail to install but still manage to leave a file laying around.

Deactivate sexout, then just delete the sexout T6M BSA.

[prideslayer]

I'm probably going to abandon the code from .1 to .3. I've revisited the .0 branch and am going to make a more methodical and careful approach to fixing the > 2GB issue (which is the same as the >4GB and/or LAA issue) and make that .4.

[ritualclarity]

That BSA overwrite thing is due to a bug in .3 I'm just going to remove that download now, sorry I forgot.

It actually installed the BSA but said the mod install failed. It's one of the weird cases where you can have FOMM fail to install but still manage to leave a file laying around.

Deactivate sexout, then just delete the sexout T6M BSA.

No problem. I know how to fix it. Just bringing it to your attention since you are working so hard on this. With all that was going on figured that something just got lost in the shuffle.

 

Edit:

Checked the previous / current FOMM with the basic mods I have been using before for testing and all works. At least for me installation wise. All is working as well on the bsa front as well. I am really liking the color coded mods list.

[prideslayer]

v0.14.10.0 in OP.

This is a fresh attempt to get the large archive support working properly.

I abandoned all changes in the previous releases (0.14.9.1, .2, and .3) and reimplemented them after chasing down the large file issues with a new approach.

Tested with:

SO Core

SO Data

Tryouts

TTW Main

*seemed* to do everything properly this time.

Note there are *still* some spots in the code where it's doing this stupid in-memory handling, which will blow up when presented with large files. I believe the "create fomod" as well as the BSA extractor/handling functions are still subject to large file concerns.

I will look into those once normal fomod installation is more fully tested.

[prideslayer]

69 downloads of v10.. nothing to report? Last time this happened it was buggier than a atlantic city hookers vajayjay.

[DoctaSax]

buggier than a atlantic city hookers vajayjay.

 

a technical term, is it?

[prideslayer]

buggier than a atlantic city hookers vajayjay.

 

a technical term, is it?

Well.. dunno if it's technical or not, but it's an industry term, certainly.

[ChianasGeek]

Tested with TTW Main, fine. Tryouts latest, fine too

[Shadee13]

Hi, I get this error when I click on "Yes to mod"
I'm using the latest version (0.14.10.0)

[nyaalich]

I got that too this morning, but I was thinking that maybe I didn't understand what "No to Mod" meant.  I was installing a 7z that just has meshes and textures, some of which already existed from an updated patch file (clothes modified for Breeze's).

[prideslayer]

I'll check it out. Looks like I just missed something silly when I rolled back to .9.0.

The code to update installog to 5.0.0.0 (NMM format) is complete. Next stop: teaching it how to read that format.

[prideslayer]

10.1 in OP.

Should fix that yes/no to mod issue.

Apologies in advance -- this is another case where any mods you installed and clicked 'yes' to that, the mod files got scattered around in the data directory even though the mod was not installed according to FOMM. This means that unless you manually delete those files, they will forever appear in DATA even after uninstalling the mod, and you'll be prompted to overwrite them as though they were/are vanilla files.

[zippy57]

Running 0.14.10.1 and getting a misleading error message:

"Error loading 'Data (5).fomod'

Extension 'fomod' is not a supported archive file name extension."

The archive in question is in fact a corrupt archive file, but not an incorrect file extension as the message indicates.

[prideslayer]

There are some really lame catachall exception handlers like that in the code. Try/catch blocks that just throw up the same error message no matter what actually went wrong. I'm going to try to take care of them all at some point, but the ones in the archive/package handling aren't a high priority since I'm going to be replacing all of that anyway.

My attempt to get NMM compatible InstallLog.xml handling in FOMM hit a minor stumbling block that turned into a major roadblock. Stuff goes that way sometimes, without going down the garden path for a while I wouldn't understand the madness in FOMMs archive handling as well as I do now, so still hopeful to have an alpha/beta release out this weekend that can be used alongside NMM.

[prideslayer]

Ok a bit more hacking and I'm basically back to where I was before.

- Upgrading installog to 0.5.0.0 (current NMM format) : OK

- Reading installlog 0.5.0.0 format : OK

- Installing new mods using 0.5.0.0 format : OK

I'm having problems with two (mis-?)features of FOMM right now that I want to axe for the time being. I don't think they're terribly important, but before I proceed, feedback is welcome. Both features revolve around the 'upgrade' functionality. There are some different approaches I can take.

1. Continue trying to get InstallLog.xml compatibility with NMM. Disable "mod upgrades":

When you activate a mod, FOMM checks to see if the mod name matches an already installed mod. If it does it asks if you want to perform an upgrade or not. If you say 'no', it just does a normal install, overwriting the older versions files (and any other files -- per normal rules and asking permission). Both packages list as active in the package manager. If you say 'yes', it tries to do some clever stuff by changing ownership of the old mods files to the new mod, and marking the old mod inactive.

I want to completely remove this check and just get rid of any idea of upgrading, at least for the time being. This would result in for example "some mod" 1.0 and 2.0 both showing as installed and active. It is safe for you (the user) to deactivate the 1.0 mod at that point unless the upgrade is really an update that does not have all the mods required files.

There is another mod upgrade 'path' that FOMM can take that I think is only (reasonably) used if you download new mod versions directly to the FOMM mods directory -- by default, c:\games\<game>\mods\.

When it first starts up FOMM checks that directory for new fomod versions of already installed mods. If it finds any, it gives you the same "wanna upgrade?" type question as item #1, and does the same thing if you say yes.

I want to completely remove this functionality and just ignore the new file. If you download directly to this directory (or if other tools place new fomods there), then they will show up in the package manager as inactive. You can manually activate them whenever you like.

Objections / suggestions to doing both of these? I can't just do one and not the other. If I can't do both then, right now, I can't get the InstallLog.xml NMM compatibility.

The reasons why are complex and difficult to explain. It all boils down to the fact that NMM can install files to the game dir -- it's not restricted to just installing to the data dir. That means the path including the data dir must be recorded in the XML. The way FOMM comes up with this path is rather simplistic but is widespread in the code, I can't "just change it" because doing that would break support for every fomod-ready archive that already exists.

I don't have time to figure out the right way to treat fomods different from fomod-ready archives, to preserve compatibility with all those existing mods. I don't want to spend the time doing that either since I still plan to completely replace the way FOMM handles archives anyway, so all that work will end up being thrown away.

OR

2. Forget updating to the new xml format entirely. To be honest, it buys us (FOMM users) nothing. The whole point of it is to allow peaceful coexistance of FOMM and NMM in managing the same game. I have no idea why people want to do this. It would be nice if FOMM could install to the game directory and be used for things like installing NVSE, ENB, etc. I can make that happen in the new archiver in the future, and intend to. It really has nothing to do with the XML format.

OR

3. Instead of FOMM bombing out when encountering an NMM upgraded file, it could simply downgrade it back to it's version (0.2.0.0) for you. It will be able to do this without breaking anything as long as all the FOMM installed files were installed to the data directory. If it sees any that weren't, it can prompt you to deactivate them in NMM first and then try again. This will only work until NMM updates the installlog.xml version again, at which point it will have to bomb out until I can teach it to downgrade whatever the new format is.

I'm really leaning towards #2 or #3 now despite the effort I've put into #1. #3 is more work obviously but does strike me as sort of poetic justice, and would likely allow everyone to use both FOMM and NMM to manage FO3/FONV as long as only one was running at the same time.