Add modl:// support

[eddoursul]

Following the commit, adding support for https:// download links, adds support for a new link schema to nxmhandler.exe:
modl://MO_GAME_ID/?url=URL

URLs are expected to be encoded using RFC 3986 (for example, with rawurlencode in PHP).

Available game IDs can be found in HandlerStorage::knownGames().

Test:
start "" "modl://falloutnv/?url=https://eddoursul.win/Cyberware%20TTW%20Patch.7z"

[Silarn]

My only comment is that we may be able to consolidate some of the code since there's a fair amount of repetition.

But I think this works for a v1.

[qudix]

Any reason to keep the chrome fix? I'd imagine that problem would have been fixed years ago at this point back when chrome versions were double digits.

[Silarn]

True, I doubt that's still necessary, though not really within the scope of this change. I'm not even sure if I've seen that message pop up.

[eddoursul]

I reverted automatic hijacking of the nxm association, enabling it only for modl://
More flexible association with modl requires full rewrite of main.cpp.

[Silarn]

I'm confused, isn't this change now preventing NXM links from being registered by the launch arg?

There's also one other issue, which is that we're assuming NXM and MODL links should be handled the same. But that's not a good assumption. If people have a custom setup that passes some games to Vortex, we probably don't want to pass those MODL downloads.

So, I'd recommend extending the assignment display and having a secondary game assignment list depending on the schema.

[eddoursul]

I'm confused, isn't this change now preventing NXM links from being registered by the launch arg?

No, it was me who added registerProxy to the autoReg block here 2077b5e#diff-34d21af3c614ea3cee120df276c9c4ae95053830d7f1d3deaf009a4625409ad2R249
And I reverted this change, because MO2 manages nxm association through adding handlers to nxmhandler.ini and only if there are no handlers, it offers to create the association.

[Silarn]

I see, thanks.

[eddoursul]

There's also one other issue, which is that we're assuming NXM and MODL links should be handled the same. But that's not a good assumption. If people have a custom setup that passes some games to Vortex, we probably don't want to pass those MODL downloads.

modl:// calls are not directed to a current nxm handler automatically, protocol associations do not depend on each other at all.

[Silarn]

No, this is not what I mean at all.

          QStringList handlerVals = storage->getHandler(url.host());
          QString executable = handlerVals.front();

This gets the target executable based on the game slug. This can technically be any executable, including Vortex. As Vortex, AFAIK, can't handle direct download links this way this would be an invalid setup. (Now, people probably shouldn't click MODL links if they use Vortex, but you never know.)

What I'm saying is we should have two lists to associate game slugs with either scheme so that MODL links are not arbitrarily sent to a non-MO2 executable.

[eddoursul]

I can't find how Vortex would appear in nxmhandler.ini, unless user added it manually.

[Silarn]

I can't find how Vortex would appear in nxmhandler.ini, unless user added it manually.

I mean yes. They would have to do it intentionally. But I've done it before and it works. You can also just use the nxmhandler interface, you don't have to edit the INI.

[Silarn]

There are a lot of games Vortex manages which MO2 doesn't so allowing users to associate those games with NXM Handler is something we should support.

[eddoursul]

A proper solution to this is a separate tool, managing a new INI like modlhandler.ini.
Alternatively, I can add a check if the handler is ModOrganizer.exe and show a message box, notifying user that modl is supported only by MO2.

[Silarn]

I think it's absolutely doable within NXMHandler with slightly more extensive changes. But a warning is fine as a stopgap solution.

[AnyOldName3]

If the protocol's not a stupid idea, a message box saying it only works with MO2 is bad as other mod managers might want to support it (side note: it might be worth tagging people like mgamerz, who work on other mod managers and might want a stay in the matter so the protocol actually ends up good).

If the protocol is a stupid idea, then supporting it is a bad idea, so it having a popup is a bad idea.

Either way, the this only works with MO2 popup is a bad idea.

[eddoursul]

I'm pretty sure Vortex or any other client would show a human-readable warning about unsupported link.

[Twinki14]

Bumping this.

While @Silarn has expressed their desire to do this differently, I think it's important to have modpub support as soon as possible. ModPub is quickly becoming quite popular, and some mods are even exclusive to modpub (TTW specifically)