Nm088 Posted May 30 Author Posted May 30 @Ratinira1 I can confirm the culprit on my side by setting my vpn to japan: the fetch can be blocked depending on your provider, location, vpn server region, and IP range. In short, whether the MO2 fetch works depends on what Cloudflare or LoversLab accepts from your IP. Using a vpn region/server that works is still the simplest workaround, but I worked on an alternative fallback. I made a pre-release test update for MO2 + Firefox users. If Cloudflare blocks the direct MO2 request, automatic update checking cannot reliably work through MO2 alone. However, the plugin can now use the browser extension as a fallback. Expected behavior when fetch is blocked: 1. Fetch fails. 2. The manager shows a Cache button for the blocked row. 3. Cache opens the LoversLab download page in your browser. 4. The Firefox extension scans the available LoversLab archives on that page. 5. MO2 shows a “Choose LoversLab Archive” window. 6. You select the archive you want. 7. The extension starts the browser download and sends the archive to MO2’s Downloads folder with LL Integration metadata. 8. Once detected, the manager should offer Install when the archive matches the row well enough. Otherwise, the archive should still be available in MO2’s Downloads tab for manual install. There are still edge cases I do not handle perfectly. This is an experimental build, mainly to confirm whether this fallback works outside my own environment. I have not updated the Chromium or Vortex versions yet, because this is a lot of work. For Vortex, I will wait and see if there is demand for this fallback first, since it requires a big logic change with a lot of extra case handling. I also have not ported the Voice Manager changes to MO2 yet. You can install this over your current installation. The "Assist Fetch Current Page" button in the extension is mostly a debug helper for me, so you can ignore it for now. You are not required to test this. It is totally optional. If this version has issues and you have access to a vpn , you can always fall back to the previous version and use a vpn region or server that works. Small note (if you test it) : after selecting an archive, give the manager a few seconds while the native helper pushes it into MO2. The button should become Install or Reinstall once the archive is ready. The experimental build archive: LL-Integration-Experimental-Build.zip
Ratinira1 Posted May 31 Posted May 31 (edited) @Nm088 So, I installed new build, updated cookies through Firefox, and now I dont have any errors) Now my window looks like that. (I pressed intall button for first 3 to test) Spoiler Or like that when I first open window, before pressing fetch updates Spoiler Edited May 31 by Ratinira1
Nm088 Posted May 31 Author Posted May 31 @Ratinira1 Ty for testing the build! This looks normal in a first view, The green Install buttons mean LL Integration found matching archives already present in MO2’s Downloads folder. This can happen if the archive was downloaded before, or if the new Firefox fallback pushed it into MO2 successfully. The manager uses the file name / metadata / match score to decide whether the archive is likely the right one. If you press Install, MO2 should open its normal install window for that archive. The Cache button means the normal direct fetch was blocked or could not be completed. In that case, click Cache. It should open the LoversLab download page in Firefox, let the extension scan the available files, then MO2 should ask you which archive you want to download. So the rough flow is: 1. Fetch = try normal update check. 2. Cache = use Firefox fallback when direct fetch is blocked. 3. Install = matching archive already exists in MO2 downloads and can be installed. If an Install button appears for the wrong archive, please tell me which row and archive name. I do not have a blacklist button yet, but that is probably the next safety feature: a "wrong archive / ignore this match" action so the manager stops offering that archive for that row. If you find other bugs or have question like editing your meta, fixing versions, just ask me.
Ratinira1 Posted June 1 Posted June 1 Great, then now I need something to update to check updates) One little questions, if you dont mind: what does "not checked" in info means? Oh, and thank you very much for doing all that fixes for me🙂
Nm088 Posted June 1 Author Posted June 1 @Ratinira1 Not checked only means the manager has not checked that row yet in the current manager session. It does not necessarily mean an error. When you first open the manager, rows can show not checked until you press Fetch Updates or Fetch on that row. If your IP is blocked by Cloudflare, the normal Fetch may fail for that row. In that case the button should change to Cache. Then when you click Cache it opens the LoversLab download page through Firefox, lets the extension read the available archives, and then you can compare and select the archive from the list. So the usual flow is: 1. Open manager. 2. Press Fetch Updates or Fetch. 3. If direct fetch works, the manager compares versions normally. 4. If direct fetch is blocked, use Cache. 5. Cache lets Firefox extension read the download page and show the available archives. So not checked is just the initial state, you can ignore it.
Ratinira1 Posted June 1 Posted June 1 @Nm088 for me "not cheked" is it always state. It doesnt mater if I just opened MO2 or pressed Fetch Updates there awlays been "not cheked". Is that a problem?
Nm088 Posted June 1 Author Posted June 1 (edited) @Ratinira1 It depends a little on the Status column, If the row says Ready / Manual / Downloaded / Installed through registry and the info says (not checked), that usually only means LL Integration has not performed a fresh version check for that row yet. It is not automatically a problem. But if you press Fetch Updates and every row still stays “not checked”, then something is stopping the update pass before those rows are reached. For example, if Cloudflare blocks one row, the manager may stop and ask you to use Cache on that blocked row first. To force-check one mod, try pressing Fetch on that specific row. If the row changes to Cache, direct fetch is blocked and you should use Cache. If it changes to OK / Update / Downloaded, it worked. If it stays exactly “not checked” after pressing Fetch on the row, please send me a screenshot of that row including Status, Info, and the button text. Thks for the feedback, btw. This is very helpful for me. Edited June 1 by Nm088
Ratinira1 Posted June 1 Posted June 1 Well, they all say "not checked", no matter what I press, both Fetch updetes or fetch on single raw... Spoiler
Nm088 Posted June 1 Author Posted June 1 @Ratinira1 Thanks, this screenshot helps. I think the wording is confusing here. "Installed through LL Integration registry; not checked" means LL Integration remembers that this archive was already installed through the manager, so it suppresses the repeated Install/Reinstall state for that archive. It does not clearly tell us whether Fetch succeeded or failed, and that is probably something I need to improve in the UI. To test the update check itself, pick one row and press Fetch on that row. 1. If it changes to OK / Update, the direct fetch worked and LL Integration could compare the versions. 2. If it changes to Cache, direct fetch was blocked and you should use Cache. 3. If the fetch works but the mod has no current version, or LL Integration cannot detect the version from the archive name, you may need to click Edit and set or fix the Current version and File pattern for that mod. 4. If it stays exactly "Installed through registry; not checked", then the registry state may be hiding the useful fetch result, and I need to improve that wording and behaviour. Some LoversLab archives do not have clean version names, or the archive name is different from the mod page name.. In those cases the tool cannot always guess the right version automatically. The Edit window is there so you can fix the metadata or pattern for that specific mod. For now, if you want to force a fresh test, you can use Install Registry and remove one entry, then try Fetch again on that row. The main goal of the tool was to speed up the LoversLab mod workflow: quickly open pages, check updates, download archives, install them, and edit metadata when needed. Another big issue I had with LoversLab mods is that it is easy to forget where an archive came from, especially when the archive name is unclear or different from the mod page name. So the tool also tries to keep the LoversLab link and metadata attached to the archive/mod, instead of relying only on memory or file names. Some labels are still based on how I debug/use the tool internally. They may be technically accurate, but not clear enough for users. I think (not checked) is one of those cases, so I will rework the wording for the UI to make it easier to understand.
Celticwolf369 Posted June 4 Posted June 4 I did a search for this in the thread and nothing was found for "Trojan:Win32/Tecabans.STV!cl" I get this every time I try and D/L 0.8 ver. Please explain, thnx.
Nm088 Posted June 4 Author Posted June 4 (edited) @Celticwolf369 If the detected file is from my official upload, it is very likely a false positive. LL Integration is open source, and the release is built from this repository. The tool also includes a native helper executable and browser/native messaging behavior, which can trigger LL Integration is open source, so you can inspect the code and build it manually yourself if you prefer. The release includes a native helper executable and browser/native messaging behavior, so Microsoft Defender cloud heuristics may flag it in experimental builds. If the detection is on my official release file, it is very likely a false positive, but I still need the exact file/path from Windows Security to confirm what was flagged. The experimental build didn't got pushed yet, i have a main mod in build and it's my main focus : if you want it pushed for building the experimental build yourself (because you have a fetch problem), then i will push it. Ty for your feedback. Edited June 4 by Nm088 1
Celticwolf369 Posted June 4 Posted June 4 5 minutes ago, Nm088 said: @Celticwolf369 If the detected file is from my official upload, it is very likely a false positive. LL Integration is open source, and the release is built from this repository. The tool also includes a native helper executable and browser/native messaging behavior, which can trigger Microsoft Defender cloud heuristics in experimental builds. That said, I still need the exact detected file/path to confirm it is my official build and not a modified/corrupted download. Please send the Windows Security detection details, especially the affected file path. If it is my release file, I will submit it to Microsoft as a false positive. LL Integration is open source, so you can inspect the code and build it manually yourself if you prefer. The release includes a native helper executable and browser/native messaging behavior, so Microsoft Defender cloud heuristics may flag it in experimental builds. If the detection is on my official release file, it is very likely a false positive, but I still need the exact file/path from Windows Security to confirm what was flagged. The experimental build didn't got pushed yet, i have a main mod in build and it's my main focus : if you want it pushed for building the experimental build yourself (because you have a fetch problem), then i will push it. Ty for your feedback. Thnx for the quick reply! HYG: Detected: Trojan:Win32/Tecabans.STV!cl Removed This program is dangerous and executes commands from an attacker. file: C:\Users\ME(;P)\LL\LLIntegration-0.8.zip webfile:C:\Users\ME(;P)\LL\LLIntegration-0.8.zip|https://www.loverslab.com/files/file/48614-ll-integration/?do=download&r=2154536&confirm=1&t=1&csrfKey=203d23ff599fdab1db5c44ba497e6a4b|pid:28668,ProcessStart:134250762371934330 I hope this helps
Celticwolf369 Posted June 4 Posted June 4 2 minutes ago, Celticwolf369 said: Thnx for the quick reply! HYG: Detected: Trojan:Win32/Tecabans.STV!cl Removed This program is dangerous and executes commands from an attacker. file: C:\Users\ME(;P)\LL\LLIntegration-0.8.zip webfile:C:\Users\ME(;P)\LL\LLIntegration-0.8.zip|https://www.loverslab.com/files/file/48614-ll-integration/?do=download&r=2154536&confirm=1&t=1&csrfKey=203d23ff599fdab1db5c44ba497e6a4b|pid:28668,ProcessStart:134250762371934330 I hope this helps I just D/L'd the LL-Integration-Experimental-Build.zip and did not get the error
Nm088 Posted June 4 Author Posted June 4 @Celticwolf369 Thanks, that helps a lot. Since the detected file is the official `LLIntegration-0.8.zip` downloaded from my LoversLab page, this is very likely a Microsoft Defender false positive. The zip contains the native helper executable used for browser/native messaging, and that kind of behavior can trigger Defender cloud heuristics, especially on small/open-source tools that are not code-signed. I will submit the release zip to Microsoft as a false positive. For now, if you do not trust the binary release, the safest option is to wait, or inspect/build the project manually from source once I push the current version. Do not whitelist it unless you are comfortable with that. Small note: you may want to avoid posting full download URLs with csrfKey in public screenshots and posts if you can edit that and remove it for your security. It is probably expired or low risk, but better to avoid sharing session like tokens. I did a check on my side: PS C:\Users\myuser\Downloads> Get-FileHash "$env:USERPROFILE\Downloads\LLIntegration-0.8_LoversLab.zip" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 E46E41A26308938E213FCD4E4A0DDF048DFDB716EBD30020F7E64B160FBC23ED C:\Users\nm088\Downloads\LLIn... PS C:\Users\myuser\Downloads> Get-FileHash "$env:USERPROFILE\Downloads\LLIntegration-0.8)_github.zip" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 E46E41A26308938E213FCD4E4A0DDF048DFDB716EBD30020F7E64B160FBC23ED C:\Users\nm088\Downloads\LLIn... I have not submitted the Microsoft false-positive report yet because the form asks for the Microsoft security product/version used for the detection. Can you tell me: 1. Are you on Windows 10 or Windows 11? 2. Are you using Microsoft Defender only, or another antivirus too? I already verified the file hash on my side. The LoversLab download and my local GitHub release copy have the same SHA256, so the flagged file is my official upload. 1
Nm088 Posted June 4 Author Posted June 4 (edited) @Celticwolf369 Sorry, I did not see your new comment before editing my previous reply. If LL-Integration-Experimental-Build.zip does not get flagged for you, you can use that one. It includes the same base tool as 0.8, plus the new experimental Firefox/MO2 fallback for blocked fetch requests. That is still useful information, thanks. It means Defender is flagging the 0.8 zip specifically, but not the experimental build. That is weird, but also a good sign. I will still submit the 0.8 zip to Microsoft as a false positive, since I verified that the LoversLab download matches my official release hash. Edited June 4 by Nm088 1
Celticwolf369 Posted June 4 Posted June 4 (edited) 44 minutes ago, Nm088 said: @Celticwolf369 Thanks, that helps a lot. Since the detected file is the official `LLIntegration-0.8.zip` downloaded from my LoversLab page, this is very likely a Microsoft Defender false positive. The zip contains the native helper executable used for browser/native messaging, and that kind of behavior can trigger Defender cloud heuristics, especially on small/open-source tools that are not code-signed. I will submit the release zip to Microsoft as a false positive. For now, if you do not trust the binary release, the safest option is to wait, or inspect/build the project manually from source once I push the current version. Do not whitelist it unless you are comfortable with that. Small note: you may want to avoid posting full download URLs with csrfKey in public screenshots and posts if you can edit that and remove it for your security. It is probably expired or low risk, but better to avoid sharing session like tokens. I did a check on my side: PS C:\Users\myuser\Downloads> Get-FileHash "$env:USERPROFILE\Downloads\LLIntegration-0.8_LoversLab.zip" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 E46E41A26308938E213FCD4E4A0DDF048DFDB716EBD30020F7E64B160FBC23ED C:\Users\nm088\Downloads\LLIn... PS C:\Users\myuser\Downloads> Get-FileHash "$env:USERPROFILE\Downloads\LLIntegration-0.8)_github.zip" -Algorithm SHA256 Algorithm Hash Path --------- ---- ---- SHA256 E46E41A26308938E213FCD4E4A0DDF048DFDB716EBD30020F7E64B160FBC23ED C:\Users\nm088\Downloads\LLIn... I have not submitted the Microsoft false-positive report yet because the form asks for the Microsoft security product/version used for the detection. Can you tell me: 1. Are you on Windows 10 or Windows 11? 2. Are you using Microsoft Defender only, or another antivirus too? I already verified the file hash on my side. The LoversLab download and my local GitHub release copy have the same SHA256, so the flagged file is my official upload. 1. Windows 11 2. Microsoft Defender only Edited June 4 by Celticwolf369 1
Psyq Posted June 19 Posted June 19 Hey, works great on edge. Just a question: Will you release the browser extension at some point to for example the chrome extensions webstore? Like it works with the developer mode, but I always get like notifications that I should disable this extension, which is kind of annoying. So I was just wondering if you are planning to release this via the webstore at some point.
Nm088 Posted June 21 Author Posted June 21 @Psyq Yes, that’s planned. It’s already pending on Opera and Firefox, and I’ll submit it to the Chrome Web Store today as well. The only downside is that approval can take a while, sometimes weeks. If there’s another browser you’d like me to support, just let me know and I’ll try to push it there too.
Psyq Posted June 25 Posted June 25 (edited) On 6/21/2026 at 10:07 AM, Nm088 said: @Psyq Yes, that’s planned. It’s already pending on Opera and Firefox, and I’ll submit it to the Chrome Web Store today as well. The only downside is that approval can take a while, sometimes weeks. If there’s another browser you’d like me to support, just let me know and I’ll try to push it there too. Thats awesome. Cant think of any other browser, like most browsers are compatible with the chrome webstore. Since many are chromium based (just like Edge, which I use). So the most majority should work I suppose. Edited June 25 by Psyq
Grinko Scallywag Posted June 30 Posted June 30 (edited) I'm having an issue. My cookies file won't generate? The extension is returning that its completing the action, and that everything is good, but the file doesn't exist. Even more confusing, the config file generated and linked with mo2 just fine, so I'm not sure what's up. I've tried hitting the export cookies button many times now, after refreshing, on different pages, but nothing worked. My only hint is that the file paths for 'MO2 plugin install' & 'Active MO2 target' are set to a '.' Its returning a green flag though, so I'm not sure what to take from that. I'm running off of Firefox portable on Linux Mint and running mo2 through steam on proton experimental (Sorry if my os being linux over complicates this)) Edited June 30 by Grinko Scallywag Clarification
Deliah Blue Posted July 3 Posted July 3 If you aren't aware, ModPub has a modl:// schema and MO2 plugin for handling it that might be useful for this project. https://mod.pub/news/2-mo2-downloads-from-modpub-and-anywhere-else
Nm088 Posted Sunday at 01:34 AM Author Posted Sunday at 01:34 AM @Grinko Scallywag Sorry for the delay, I got very busy irl. Linux / Proton is not officially supported/tested yet. From your info, it looks like the native helper can run, but the paths for MO2 plugin install and Active MO2 target are empty/invalid (`:`), so the native app probably does not know where to write the cookies/config files or how to link them correctly with MO2 under Proton. LL Integration was mainly build on Windows with normal MO2 paths. For Linux + Proton, I would probably need to emulate/test Mint myself and add proper path translation between Linux paths and the Proton/Windows paths used by MO2. So for now: it may not work correctly on Linux. My hope is : it's just a question of path fixing in the code. I'll push the last build to my git in case if you want to looking into it and fixing it, but I'll have free time soon so I'll check that. @Deliah Blue Thanks, that is useful and interesting info but I looked at it and from what I understand, ModPubs "modl://" support is mostly a protocol for sending a direct download url to MO2. That is great for sites that expose direct downloadable files. My project is solving a different problem, LoversLab and similar sites do not expose a clean public API for update checks or download metadata, and some downloads require login cookies, Cloudflare browser handling, or parsing the page itself. The ModPub article also mentions that update checks need a site API plus specific manager support. So "modl://" could be useful for simple direct-download integration, but it does not replace the LL Integration logic for LoversLab style update checking/cookie/browser-assisted fallback.
Grinko Scallywag Posted Sunday at 04:04 AM Posted Sunday at 04:04 AM (edited) 2 hours ago, Nm088 said: From your info, it looks like the native helper can run, but the paths for MO2 plugin install and Active MO2 target are empty/invalid (`:`), so the native app probably does not know where to write the cookies/config files or how to link them correctly with MO2 under Proton. Based on this statement, and the fact that I'm running off of Firefox portable (Which stores information locally within a directory, unlike a regular browser or normal Firefox, hence it being "portable"), I would definitely agree that it sounds like a pathing issue. What was odd to me was why it was so insistent that the files were generating though. Perhaps the issue could be solved by allowing a custom location to be set, but of course, I have no idea how difficult that might be to implement, and either way, that is WAY out of my league. Quote I'll push the last build to my git in case if you want to looking into it and fixing it If I had the faintest clue what I was doing, I'd love to, but that is still far outside my comfort zone, as I'm still trying to learn Linux in general lol (first month on it) It also falls far out of my knowledge as far as the basics of this type of programming. (my meager knowledge lies more in simple shell code and basic queries) I appreciate your time to comment! It feels nice to have a more clear cut guess as opposed to my shaky theorizing, so thank you for that! Edited Sunday at 04:07 AM by Grinko Scallywag gratitude 1
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now