-
-
Notifications
You must be signed in to change notification settings - Fork 3
Control hints for 2025 patch #58
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
base: main
Are you sure you want to change the base?
Conversation
|
Do older game versions have access to the new methods? If not, then we would want to use reflection or similar to choose the best of what's available, as I would like to continue supporting older game versions. I also notice you didn't find a suitable replacement for |
|
Also, your second commit seems unrelated to the PR. |
|
Ah yes, made a mess with GitHub since I'm not used to making PRs. Sorry! |
|
I'm not sure why GetDisplayTextForBinding was there? Utils.KeyCode.ToString(keyCode) already returns the string for the enum and in-game it works. I have no idea what it was like in 2023 as I don't have the old assembly with me. I'd have to check. Same for the GameInput one. |
|
I'm not sure how to split the PR now, but the 2nd fix was to something I saw in the logs after trying the extended build distance: |
The game had a method to format the string nicely for users, so instead of "Mouse0" it would be "Left Mouse Button", for example. Since users often don't know what control the KeyCode relates to, and they're definitely not used to zero-based indexing lol. Would really want it still to be used if there is something available. What is the game itself doing when it's showing hints on screen? How is it formatting the controls for display? It could just be that the equivalent method is no longer needed going forward, but should still be used when on old versions. For the separate fix you'd need to revert the commit and add it in a separate branch. Tbh, I could fix this myself with just throwing a .ToList() on the end of the .Where() (no need to store in a variable, I know some people might think it's harder to read that way, but for me it taking up less vertical space makes it easier to fit it all in my brain's context window lol). It's just kind of a convention with git that you keep a PR down to just the one thing it is attempting to fix. Separate fixes would be separate PRs. So that if you ever have to revert the PR for some reason, you don't end up losing a bunch of unrelated bugfixes at the same time. If you just leave as-is I can handle the revert and whatnot when I have time to go over this anyways. It does seem like it would still need more investigation from myself at this point for me to be happy with it, at least for users still on old versions. Feel free to compile whatever you have for your own personal use though :) |
|
I'll let you handle it then! And yeah, the conversion to a readable KeyCode makes sense, I completely forgot about that. |
|
It might be the case that it would be better for SnapBuilder to move to the new input system if that's what the game is using now, but again would prefer to make use of reflection or similar to determine which we should use. And that might be opening a whole can of worms that would be best left to a future enhancement PR 😅 |
Update key display (Utils.KeyCode.ToString(keyCode) suffices) and button formatting to work with new input system. Worked fine in-game and the hints now show again.