Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potentially Missing API Call After Boss Battle Wins #96

Open
brellorand opened this issue Aug 22, 2024 · 4 comments
Open

Potentially Missing API Call After Boss Battle Wins #96

brellorand opened this issue Aug 22, 2024 · 4 comments

Comments

@brellorand
Copy link
Contributor

Describe the bug
On many occasions, players who use MM Helper to beat several boss battles in a row do not have their clear parties appear in the game's clear history for the bosses on which they used Helper.

I performed a packet capture on a live session of the game running in BlueStacks, and found that there is an API call that the game performs after boss battle wins that is not performed by the Helper. I suspect this missing API call is what causes the clear party to not be recorded.

In Helper, the requests that are made in Funcs/Battle.cs:

  • NextQuestRequest (quest/getQuestInfo)
  • BossRequest (battle/boss)

The missing request is MapInfoRequest (quest/mapInfo) after wins.

The order of requests seems to be as follows:

  • MapInfoRequest upon first viewing the map
  • NextQuestRequest, followed by BossRequest
    • If successful, MapInfoRequest before the next NextQuestRequest
    • If unsuccessful, but you immediately retry, then no additional request is made

Some potentially correlating evidence that I have found is that after a single successful win via Helper, followed by exiting Helper, logging in to the game, and clicking the map, results in the animation for increasing the green/red orb rates being played, and in the winning party being recorded.

A high level summary of requests from my packet capture showing consecutive wins:

10.0.0.1:35192: POST https://15.197.139.185/api/quest/mapInfo HTTP/2.0
    << HTTP/2.0 200 OK 4.9k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/getQuestInfo HTTP/2.0
    << HTTP/2.0 200 OK 1.0k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/boss HTTP/2.0
    << HTTP/2.0 200 OK 68.1k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/mapInfo HTTP/2.0
    << HTTP/2.0 200 OK 5.0k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/nextQuest HTTP/2.0
    << HTTP/2.0 200 OK 44.1k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/getQuestInfo HTTP/2.0
    << HTTP/2.0 200 OK 1.0k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/boss HTTP/2.0
    << HTTP/2.0 200 OK 71.9k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/mapInfo HTTP/2.0
    << HTTP/2.0 200 OK 5.4k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/nextQuest HTTP/2.0
    << HTTP/2.0 200 OK 50.7k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/getQuestInfo HTTP/2.0
    << HTTP/2.0 200 OK 1.0k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/boss HTTP/2.0
    << HTTP/2.0 200 OK 71.6k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/mapInfo HTTP/2.0
    << HTTP/2.0 200 OK 5.0k

Note:

  • The 5.0k mapInfo requests POSTed {'IsUpdateOtherPlayerInfo': False}
  • The 5.4k mapInfo requests POSTed {'IsUpdateOtherPlayerInfo': True}
  • It seemed to go back and forth between True/False on each request

From my packet capture, consecutive losses:

10.0.0.1:35192: POST https://15.197.139.185/api/quest/getQuestInfo HTTP/2.0
    << HTTP/2.0 200 OK 1.0k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/boss HTTP/2.0
    << HTTP/2.0 200 OK 70.4k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/getQuestInfo HTTP/2.0
    << HTTP/2.0 200 OK 1.0k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/boss HTTP/2.0
    << HTTP/2.0 200 OK 60.9k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/getQuestInfo HTTP/2.0
    << HTTP/2.0 200 OK 1.0k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/boss HTTP/2.0
    << HTTP/2.0 200 OK 68.0k
10.0.0.1:35192: POST https://15.197.139.185/api/quest/getQuestInfo HTTP/2.0
    << HTTP/2.0 200 OK 1.0k
10.0.0.1:35192: POST https://15.197.139.185/api/battle/boss HTTP/2.0
    << HTTP/2.0 200 OK 85.8k

To Reproduce
Steps to reproduce the behavior:

  1. Use Helper to defeat multiple boss battles in a row
  2. Look at the clear history from another account
  3. Fail to find clear parties that used Helper

Expected behavior
Many people would expect to see their clear history, regardless of whether they used Helper or played the game manually.

Screenshots
N/A

Desktop (please complete the following information):

  • OS: Windows
  • Browser: Firefox

Additional context
n/a

@moonheart
Copy link
Owner

Thanks for your detailed report, issue will be fixed in next release.

@brellorand
Copy link
Contributor Author

Happy to help; thank you!

@brellorand
Copy link
Contributor Author

Oh, I just realized that I had a mismatch in Request class names, and I missed one more request, but it's there in the packet capture I pasted in my original message.

The quest/getQuestInfo request is GetQuestInfoRequest in the decompiled code (which does not currently appear to be in Helper). The NextQuestRequest class is for battle/nextQuest.

So, to amend that request order I initially suggested:

  • MapInfoRequest upon first viewing the map
  • GetQuestInfoRequest, followed by BossRequest
    • If successful, MapInfoRequest, followed by NextQuestRequest, before the next GetQuestInfoRequest
    • If unsuccessful, but you immediately retry, then no additional request is made

@brellorand
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants