-
-
Notifications
You must be signed in to change notification settings - Fork 243
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
Add technic modpacks #1399
Add technic modpacks #1399
Conversation
src/common/api.js
Outdated
@@ -26,6 +27,8 @@ const axioInstance = axios.create({ | |||
} | |||
}); | |||
|
|||
let technicClientBuild = '757'; // Requests to technic api need build id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could you move this in constants?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm afraid I can't. This is not a constant, only a placeholder valid at the time of writing this. The current build is subsequently fetched inside getTechnicClientBuild
, which serves only as a global variable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Global variable
Yeah you can put that into the constants
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have added a constant with the '757' value but the variable is still needed for keeping the updated client build.
The Hexxit II unable to start can be fixed by choosing the symlink option, I have already detailed this in #1133. In the case of Tekkit, this is caused by some Minecraft libraries not being available as described in the Open Questions and Pre-Merge TODOs section and issue #1398. |
141ebf2
to
b028ba8
Compare
I would open some kind o modals to explain that in case they fail then, or when you start the instance |
I completely agree with this, but shouldn't such feature be implemented in another PR? I feel like creating these kinds of pull requests that change a lot of functionality can lead to unexpected issues and a potential lack of clear regression. I would be more than happy to fix both issues were they specific to technic modpacks, but both of them occur for other modpacks as well (I will provide a detailed example later). I can, however, mark the default modpacks as either requiring the symlink option to be enabled or completely broken due to missing dependencies, since it does not affect other functionality. |
Stale. Please reopen when the issues are fixed. |
These issues are the same issues as #1459 |
Purpose
This PR adds support for technicpack (both legacy and solder API) modpacks. I completely forgot about the original PR (#1136) since it took a while to review so now I'm creating a new one.
Linked issue: #109
Approach
I have added API calls to technic and solder for fetching modpack information and created modpack views + actions for solder and technic modpacks.
Unfortunately, legacy API only supports the latest version and some releases do not any timestamps to use as release dates.
Open Questions and Pre-Merge TODOs
Learning