Provide custom launcher API

[rockisch]

I recently managed to reverse engineer the MHF's original launcher (mhf.exe + mhl.dll), and created a simple CMD custom launcher: https://github.com/rockisch/mhf-iel

I plan to expand it into an actual GUI, but currently the project uses hardcoded variables, which ideally would come from the server.

I'd like to know if there's any interest in providing a set of endpoints to handle custom launcher operations. Besides the benefits mentioned on the repo, that would also mean the current launcherserver and signserver could be disabled by default. Launcher files (the ones under www/) would also not be needed anymore.

As for what's required of those endpoints, the only information that's needed to boot the game is a login token and a specific character ID. The rest would be based on what the launcher interface wants to display as information.

[rockisch]

Here's what a simple implementation of the server + a login endpoint could look like: https://github.com/ZeruLight/Erupe/compare/main...rockisch:Erupe-1:newsign

[sekaiwish]

I'm very interested in this, never mind the game runs on Deck already. Wasn't able to get mhf-iel to boot up the game so far myself though, but I am all for having a sign-v2 API to handle custom requests like this.

[rockisch]

Wasn't able to get mhf-iel to boot up the game so far myself though

Interesting... even if you provided a valid character ID and session token? Since we can't communicate with the server without a custom API, you would need to manually insert the token into the database before using it to load the game, and it also needs to be 16 bytes. What I was doing to test was running a query like this:

INSERT INTO sign_sessions (user_id, token) VALUES (<user_id>, '0123456789abcdef');

and then booting the game like this:

.\mhf-iel.exe <char_id> 0 0123456789abcdef

I uploaded a new build to the repo with some additional logging, if it still fails it should at least spit something out on the terminal so I can investigate.

[sekaiwish]

Tried a couple different combinations of the DLL files but I'm guessing the hardcoded offsets are specific to whichever one you have. Everything up to the handing off works as intended though, character selection, token generation and such.

[rockisch]

Hmm, I don't think having different versions of mhfo-hd.dll should change anything, since the structure mhf.exe and mhl.dll (which are responsible for the launcher) allocate only has internal pointers. The commented offsets were only used to help myself while I was reverse engineering.

That said, I was using an unmodified copy of it, I'll try getting one with the 'client updates' later to try it on again.

[rockisch]

Did a lot of testing with different DLLs AND different machines (including the deck), and I managed to run the game just fine with mhf-iel... so not sure what's going on on your end. Did you run it through the command line directly (without the python script)? Didn't it log something, like an error code?

[sekaiwish]

I did actually get it to work on my desktop! It just fails to start on my laptop for some reason, no error output or anything, may or may not have something to do with Windows 11 since my desktop runs 10.

[rockisch]

Oh yeah, I only tested on Win10. I'll grab an 11 version this weekend to check what's going on on 11.

Will also try to give the final touches to the base of the 'new' sign API and get a non-python simple client running.

[rockisch]

So, regarding Win11, my PC can't run it lol. Not sure why, guess my processor isn't supported. That said, I'm porting that project to Rust to make it easier to add stuff and integrate with other platforms, so maybe whatever I'm doing wrong for Win11 will get fixed in that version.

I also finished a draft of the 'new sign' server. All of the operations the current launcher supports are there, plus another endpoint to get metadata for the server to send announcements, patch data (if implemented in the future), images, etc. For now I only added some hardcoded announcements there for testing. Ideally they'd be stored in a table, but I'm not sure how you're handling the creation of those after the old migration system got nuked.

[sekaiwish]

Merged as SignV2 though the API will still need to be properly supported through this issue thread probably

[Tsugami]

So, regarding Win11, my PC can't run it lol. Not sure why, guess my processor isn't supported. That said, I'm porting that project to Rust to make it easier to add stuff and integrate with other platforms, so maybe whatever I'm doing wrong for Win11 will get fixed in that version.

I also finished a draft of the 'new sign' server. All of the operations the current launcher supports are there, plus another endpoint to get metadata for the server to send announcements, patch data (if implemented in the future), images, etc. For now I only added some hardcoded announcements there for testing. Ideally they'd be stored in a table, but I'm not sure how you're handling the creation of those after the old migration system got nuked.

I tried to run on windows 11 and had the same problem, on windows 10 it worked!

[sekaiwish]

Very interesting

[stratic-dev]

I was able to run on windows 11. ive started writing a launcher in rust to interop with iel.

Comments on the api

/login is probably missing the following fields "returning" to indicate whether the character is eligible for the return world "course" to indicate what course is active for the character

/server/status would be a new api which would give a status of the server indicating what events are active and what week and maybe even the current status for a given team? { "featured_weapon":0
"diva": {"week":0), "mezfez":0 "FestaEvent": {"week":0), "TournamentEvent" {"week":0),}, }