Slipstream Mod Manager v1.9.1 (2018-01-07)

[BlackParagon]

Okay, I have to apologize for the lack of clarity in my post, it was late and I was quite annoyed after hours of failures.

So, yes I used WinRar to repack the files into a .rar file and then renamed it to .ftl and fed it to SMM. That worked fine, although I wasn't completely sure if .ftl files needed to have some special setting for compression, I just used default compression settings (I changed nothing, just right-click "Add to xyz archive .rar")

I then indeed tried it with one of the original .ftl files from CEPM. That worked. But I can verify I did no mistake when packing the mods together into one file as I spend 3 hours of making sure I a) would not copy the same files multiple times over and b) I tried packaging 2 skins from the CEPM collection into one and that also worked.

For reference, I later tried patching only 2 or 3 small mods and one skin in and that also worked.
So I really am not sure what happened. I am at the moment manually repacking the data.dat and resource.dat files with all the mods I want to try and see if they work (I already tried patching in all the skins and other img files and that worked brilliantly).
But patching manually is a pain in the a** regarding .xml merging... I really hate it -.-

modman-log.txt is quite empty, it only says it patched succesfully, but returns no errors whatsoever.
I am really sorry I can't provide anymore information... if there were at least errors I could probably fix it myself, I understand enough of xml to see were I did mistakes.

All I can say is that if I press validate, SMM tells me: This mod doesn't append. It clobbers.
But SMM says that even if I only load up a single skin, which works.

[agigabyte]

Okay, I have to apologize for the lack of clarity in my post, it was late and I was quite annoyed after hours of failures.

So, yes I used WinRar to repack the files into a .rar file and then renamed it to .ftl and fed it to SMM. That worked fine, although I wasn't completely sure if .ftl files needed to have some special setting for compression, I just used default compression settings (I changed nothing, just right-click "Add to xyz archive .rar")

I then indeed tried it with one of the original .ftl files from CEPM. That worked. But I can verify I did no mistake when packing the mods together into one file as I spend 3 hours of making sure I a) would not copy the same files multiple times over and b) I tried packaging 2 skins from the CEPM collection into one and that also worked.

For reference, I later tried patching only 2 or 3 small mods and one skin in and that also worked.
So I really am not sure what happened. I am at the moment manually repacking the data.dat and resource.dat files with all the mods I want to try and see if they work (I already tried patching in all the skins and other img files and that worked brilliantly).
But patching manually is a pain in the a** regarding .xml merging... I really hate it -.-

modman-log.txt is quite empty, it only says it patched succesfully, but returns no errors whatsoever.
I am really sorry I can't provide anymore information... if there were at least errors I could probably fix it myself, I understand enough of xml to see were I did mistakes.

All I can say is that if I press validate, SMM tells me: This mod doesn't append. It clobbers.
But SMM says that even if I only load up a single skin, which works.

A .ftl is a renamed .zip

[BlackParagon]

Jajaja... so
SMM is able to read renamed .rar files but obviously does not use them, meanwhile not throwing an error.
After I using the standard .zip format and renamed to .ftl, I now get an "unexpected inner path" error, which I cannot believe to be true as the inner filestructure is consistent with the filestructure used in the original .dat files...
I will continue trying to find the source of this error.

[kartoFlane]

All I can say is that if I press validate, SMM tells me: This mod doesn't append. It clobbers.
But SMM says that even if I only load up a single skin, which works.

That's nothing unusual, graphical mods have to clobber previous entries, as there's no way to "append" images.

SMM is able to read renamed .rar files but obviously does not use them, meanwhile not throwing an error.
After I using the standard .zip format and renamed to .ftl, I now get an "unexpected inner path" error

That's odd, I was fairly certain SMM would output an error to the console if you tried to patch in a renamed .rar...
Either way, please upload the file that caused the "unexpected inner path" error and link it here, the manager rarely makes mistakes in this regard, if ever.

@DavidCG
When you open SMM, it should print out what it considers to be FTL's installation path ("using FTL dats..."). Make sure it points to the correct directory -- it may have gotten confused, for whatever reason.
You can change it by going to the File menu in SMM, selecting Preferences, scrolling down until you find ftl_dats_path entry, and clicking on the button with ellipsis/three dots (...). That'll allow you to manually browse to your FTL installation path.
Then restart SMM and try again.

@EvilJell0
Huh, odd. Try the default approach when dealing with corrupt archives:

1. Go to SMM/backups, delete data.dat.bak and resource.dat.bak
2. 
   
   1. Steam users:
      Steam -> Library -> right-click on FTL -> Properties -> Local Files -> Verify Integrity of Game Cache
   2. DRM-free version users:
      Reinstall FTL (remember to back up your profile!)
3. Launch SMM to create new backups

[agigabyte]

So, I do not have a modman-log.txt file.

EDIT: I got it to work, but no mods are showing up.

[kartoFlane]

@agigabyte
SMM looks for a folder named mods in its own directory. That's where you put the .ftl files.
If no mods are being displayed, then the folder doesn't exist / is not being detected by SMM, or is empty.

[agigabyte]

@agigabyte
SMM looks for a folder named mods in its own directory. That's where you put the .ftl files.
If no mods are being displayed, then the folder doesn't exist / is not being detected by SMM, or is empty.

I figured it out, it seems that deleting GMM deleted the folder too.

[DavidCG]

@DavidCG
When you open SMM, it should print out what it considers to be FTL's installation path ("using FTL dats..."). Make sure it points to the correct directory -- it may have gotten confused, for whatever reason.
You can change it by going to the File menu in SMM, selecting Preferences, scrolling down until you find ftl_dats_path entry, and clicking on the button with ellipsis/three dots (...). That'll allow you to manually browse to your FTL installation path.
Then restart SMM and try again.

Well, it appears to be the correct directory. It is C:\Program Files\FTL\resources, and I've double-checked it. It even says it correctly patches, but when I start up FTL nothing's changed.

[Vhati]

Well, it appears to be the correct directory. It is C:\Program Files\FTL\resources, and I've double-checked it. It even says it correctly patches, but when I start up FTL nothing's changed.

I've occasionally wondered about this... Do you have the following folder?

"C:\Users\[YourUsernameHere]\AppData\Local\VirtualStore\Program Files\FTL\resources"

In an attempt to be 'helpful', VirtualStore is something Windows Vista/7 sometimes creates when an app, run as a regular user (instead of an admin), tries to write to a system folder. Windows can redirect the write to the location above and pretend the write was successful. Then to maintain the illusion, any further read attempts would be tricked into reading from there instead of the normal C:\Program Files.

But then weirdness happens when an admin modifies the real protected file. A user-run app then continues to see the VirtualStore copy instead... I think. I haven't had to deal with that situation often enough or recently enough to remember how that plays out exactly.

If you do see that phantom FTL\resources folder, delete it.

[DavidCG]

@Vhati

Yup, that did it! I will make sure to check VirtualStore again if it gives me more issues.