-
Notifications
You must be signed in to change notification settings - Fork 72
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
Special K compat search needs improvement #580
Comments
As a side note, I can get the game to work with |
I don't use SpecialK and reduced the time I spend on the project, |
Thanks for the insight into this! I agree with Frostwrox that contributing improvements upstream is probably the solution generally, that is for games that do work with the newer SpecialK release. I'm wondering as I can't find that HTML file, does SpecialK normally check for multiple game names? That is, is it "normal" for them to look for additional game names such as
Maybe it's just me that's misunderstanding here so apologies, but could you explain this in a bit more detail?
Perhaps the way we could do this is to have a checkbox called "Use Older SpecialK Repo" (or probably a better name that is more clear 😄). Then perhaps we can get the available versions on GitHub and show these in a dropdown box where the user can select a different version. Not sure how easy/hard this is to do with Bash 😅 But if we can't display the versions, we could always just have an input box. Improving STL SpecialK support would be excellent, so thank you for all the information provided here. We can get a discussion going so that you or someone else could potentially find a way to implement this. Having an issue with the details needed to improve SpecialK support is only beneficial 😄 |
A problem I just realised: If NieR:Automata needs an older version of SpecialK (the "FAR" mod I suppose), then we can't rely on upstream to translate the name, since NieR:Automata is supported with newer releases of SpecialK? If that's the case, I think it might be ok for STL to manage a translation directory, kind of like how we have for Vortex. Then, we can have a checkbox for the SpecialK setting to use an old release. @WhittlesJr Could you outline the process of using the older SpecialK release to install the likes of FAR for NieR:Automata? I believe this is the actual release for the newest release of that old SpecialK version: https://github.com/Kaldaien/SpecialK/releases/tag/sk_0_8_50 However how would one install FAR without having to use the SKIM installer? Basically, how do we get this old version of SpecialK to automatically install for a game? Ideally we'd just need a checkbox with "Use Older SpecialK Releases", and a tooltip that says some older games need this (it should be up to the user to know how to mod their game imo, but we could have a note and additional info on the wiki 😄). Then we would have an additional box where the user can input/select their desired version, with a default "latest" or something. From a frontend perspective this should be straightforward enough, but on the technical side of actually installing SKIM I'm not sure. Maybe it would be fine to just open the SKIM installer program but I'm not even sure if SKIM would be able to find games. It would be much more ideal if this was automated for the user. Btw, correct me if I'm wrong, but older games need the older SpecialK release because they had specific mods, right? Like NieR:Automata had FAR and I think Trials of Cold Steel had its own mod. Now newer games seem to just be all under SpecialK, but I guess not all of them for some reason. My earlier point about wanting to better understand what you mean by your second point still stands. I would love to see this get added to STL and I'd be willing to help out if I could have some further understanding. |
most mods are built into specialk now and afaik they get loaded when specialk detects that specific game. FAR should be built in now |
Ah, so could the issue with NieR:Automata be the name mismatch? |
Like I said, even if you resolved the name mismatch, that would only inform steamtinkerlaunch of which API to use, since it's not looking for pinned versions in that html mapping file. I tried installing several modern versions SpecialK manually, and the only thing I've gotten to work with this game is a legacy, pre-SpecialK version of FAR. I would be happy to try getting a SpecialK version to work with this game if we could at least give steamtinkerlaunch the ability to target older versions of SpecialK. Then the next step would be making the version selection happen out-of-the-box by respecting the version mapping in that html file. |
Not to worry, everything is hard to do with Bash! |
Thanks for the response.
Yes, I think having a checkbox with something like "Use Older SpecialK" and then have STL, by default, download the latest version of the older SpecialK releases.
SteamTinkerLaunch is written entirely in Bash, so this is not very helpful 😦 I am not too familiar with SpecialK but thank you for the elaboration nonetheless. You're free to try and contribute this yourself, unfortunately I don't think I have the understanding of SpecialK necessary to try and implement this. |
thanks, that says pretty much all. It is an upstream problem to be compatible, no steamtinkerlaunch problem. |
I disagree that it's not an issue with steamtinkerlaunch. Only one of the three problems I cited in my first post can be fixed upstream. I or someone else may well write a PR to solve the other two, but this issue should remain open as an invitation to do so. |
I disagree |
Can you elaborate on your reasoning? |
Sorry, I'd just like to chime in a little 😅 I think support for games that rely on an older SpecialK is something that should be sorted upstream. I also think the naming scheme is better handled upstream as well. Could you point out where this file with the names for games is stored? I'd like to compare what STL stores vs. what SpecialK stores. If there's a pattern or something maybe we could find some way to programmatically resolve the name mismatching and store it in the STL meta file with a value like I'm not sure about your second point though, this maybe this is something STL needs to manage but I don't fully understand what the problem is so I cannot say for sure. Just quoting it here for clarity:
If we really did want to go the route of supporting older SpecialK versions I don't know how we would install them.
Even if SteamTinkerLaunch targets this older version, doesn't it rely on a GUI installer called SKIM? If you could outline the process used to install manually, that would be very helpful in understanding what SteamTinkerLaunch is meant to do if it targets an older version. From what I looked into before sadly I don't think it's as straightforward as just changing where we download from. I realise before you used NieR:Automata in your tests with installing manually, but ideally if we allow targetting of older SpecialK versions we would have a solution for all the games that rely on it. |
Everything was already said above. Won't spend more time on it. |
I'm trying to get the game NieR:Automata to run Special K. It seems that others have tried without success, and I think I know why:
First of all, it tries to find the game name
NieRAutomata
in the compat.html file, and can't find it. I believe this is because it's calledNieR: Automata
in that file. So, issue 1 here could be a need to have a translation dictionary of Steam game names to how they appear in that file.Second, unless I'm mistaken, I don't think that steamtinkerlaunch inspects the compat version listed in that file, only the render API. This version information is critical to getting these games to work out of the box. Some of those table cells have more than one version, so you would have to only grab the first one.
Third, this game and many others require older versions which aren't on the
SpecialKO
github repo, but are instead here: https://github.com/Kaldaien/SpecialK/releases. If it's too much effort to automate the first two features, if you could at least pull from this repo to allow manually setting an older version, that would be an acceptable workaround.(By the way, I am packaging steamtinkerlaunch for NixOS, and I marvel at how well steamtinkerlaunch works even on such a non-standard OS. I'm very impressed!)
The text was updated successfully, but these errors were encountered: