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

[ULTIMATUM1638]

Oh yeah, it seems that my files were corrupted. Thanks! I must go and finish my ship

[Spelunkers]

Hello, having some problems with the Captain's Mod. It is the only mod that I have patched using Slipstream. Startup is good and the in-game text is a bit smaller but it is nothing terribly bad. However, my game crashes randomly when jumping beacons or attempting to leave a sector. This is the crash log that FTL gives when this happens:

Version = 1.03.3

Stack Trace:

1 - 0x0062b6e8
2 - 0x005a0ef8
3 - 0x0069415b
4 - 0x004010fd
5 - 0x774f9f72 RtlInitializeExceptionChain
6 - 0x774f9f45 RtlInitializeExceptionChain

Any ideas on what is going on? Thanks in advance.

[kartoFlane]

That's a problem caused by the mod, not the manager itself. You've probably downloaded a beta version of the mod, or Sleeper forgot to clean files up after testing...
You might have more luck by reporting exactly when the crashes occur in CE's thread. FTL's crash logs are relatively meaningless to modders.

As a general rule of thumb: game crashes = problem with a mod, manager crashes = problem with the manager.

[Spelunkers]

Thanks for the help. Will direct this to the CE thread then.

[ApexMods]

If I may make another suggestion?

Upon launch, SMM seems to first checksum all found mods, which can lead to a rather noticeable lack of application responsiveness, especially when many and/or larger mods are present. I believe this is partly due to the legacy development goal of keeping a centralized mod database in SMM, but now that the utility allows to include mod-specific metadata within individual .ftl archives (since SMM v1.3), and checksums are no longer required for mod information display, maybe the md5 process could be changed to make initial mod selection more responsive.

For example, how about loading md5 information only when no metadata can be found, or make it a user-adjustable preference e.g. when to load md5 info or not to load it at all, or only when manually triggered e.g. by a separate button or menu item, or during mod syntax validation?

[kartoFlane]

IIRC, SMM performs the hashing in a separate thread, so the application itself should not be affected.

*shrug* but I dunno...

[Vhati]

Upon launch, SMM seems to first checksum all found mods, which can lead to a rather noticeable lack of application responsiveness

kartoFlane is correct, hashing occurs in a separate thread and should have no impact on the GUI.

Embedded descriptions are also collected on startup in that separate thread (then stored together in a cache file, to avoid needlessly reopening zips, and the cache is updated when a mod file's hash is new or different).

To see if it's to blame, you can start that thread again manually via "File-Re-Scan mods/".


Loading settings and cache files, and connecting to the internet to check for updates, happens in another background thread on startup.


Can you provide more detail about when you're seeing that lack of responsiveness and what isn't responding?
I had no problems while 1 gig of mods were being processed in the background.


Edit: There is some lag whenever you click on a large mod that has no description at all. Because the zip's contents are read at that moment, in the GUI thread, to determine its age for the error message.

[ApexMods]

To see if it's to blame, you can start that thread again manually via "File-Re-Scan mods/".

Yep, that's the one.

Edit: There is some lag whenever you click on a large mod that has no description at all. Because the zip's contents are read at that moment, in the GUI thread, to determine its age for the error message.

And that's when the app is almost completely unresponsive for me. Although there actually is valid metadata present within the .zip file in question, initially the mod cannot be selected, and SMM slows to a crawl upon trying. When the mod ultimately becomes selectable but is clicked 'too early', its metadata will not be loaded at all, and the generic info for undocumented mods is displayed instead, with the only way to get to the metadata being the re-scan routine all over again.

As you may have guessed, this concerns a rather large new mod under active development, so naturally its md5 hash changes constantly. Due to the slowdown it can be a bit of a drag to repeatedly patch mod changes into the game via SMM, especially now that the mod's steadily growing size makes the delay ever more noticeable.

[Vhati]

Edit: There is some lag whenever you click on a large mod that has no description at all. Because the zip's contents are read at that moment, in the GUI thread, to determine its age for the error message.

And that's when the app is almost completely unresponsive for me. Although there actually is valid metadata present within the .zip file in question, initially the mod cannot be selected, and SMM slows to a crawl upon trying. When the mod ultimately becomes selectable but is clicked 'too early', its metadata will not be loaded at all, and the generic info for undocumented mods is displayed instead, with the only way to get to the metadata being the re-scan routine all over again.

If you're clicking on a mod *before* its embedded description has been collected (which is the slow part actually, not the hashing, but again they're both background tasks), the mod will have no description *at that moment*, and generating that error message will cause the lag (I do need to fix that message).
Clicking a description-less mod repeatedly might show the error message again and exacerbate that lag.

You should not need to Re-Scan however (it's only for when you change files in the mods/ dir while SMM's running).
Once the description is available, you'll see it just by clicking the mod again.

And the first time the mod is discovered on startup, it will be cached, so there *should* never be another delay thereafter, even if you click Re-Scan then click the mod quickly.

If you click Re-Scan and just drag the window or scroll bars, do they respond?

[ApexMods]

If you're clicking on a mod *before* its embedded description has been collected (which is the slow part actually, not the hashing, but again they're both background tasks), the mod will have no description *at that moment*, and generating that error message will cause the lag (I do need to fix that message).

Wait, so the fetching of metadata.xml contents is causing the lag? I don't understand; that's just a couple of bytes of data, how can that take so long?

Clicking a description-less mod repeatedly might show the error message again and exacerbate that lag.

You should not need to Re-Scan however (it's only for when you change files in the mods/ dir while SMM's running).
Once the description is available, you'll see it just by clicking the mod again.

I can click said mod again and again forever, SMM won't show the embedded description once it has resorted to the generic MD5 hashing thing. The only way out is to do the re-scan all over again.

And the first time the mod is discovered on startup, it will be cached, so there *should* never be another delay thereafter, even if you click Re-Scan then click the mod quickly.

The delay occurs every time, even when the .zip has not been altered at all (and nothing needs to be re-cached). Whenever I launch SMM with the mod present I have to wait several seconds (I usually count to 10, mississippilessly) before selecting the mod entry to be able to see the embedded description. The same goes for the re-scan routine: no metadata without waiting.

If you click Re-Scan and just drag the window or scroll bars, do they respond?

Yes, the UI remains fully responsive up until I try to select the large mod in question "too early". All other (smaller) mods are selectable and doing so won't cause any delay, whether they have embedded descriptions or not.

Hope I'm explaining this correctly?