-
Notifications
You must be signed in to change notification settings - Fork 3
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
Sekiro framerate fix requires working framelock feature #6
Comments
Thanks for writing this up.
I think you might've misread the comment a tiny bit, it's the other way around as far as I could tell when I looked into how sekirofpsunlock did it. It looks like it (sekirofpsunlock) is reading/writing at different locations, tuxtrain doesn't really have any feature to do this yet unfortunately. I'd need to fully look into it to find a good way to solve it because I think I saw the writing pos is based on something found at the reading pos making it more complicated than a simple search/replace. |
You are right, then I indeed misread that part, thanks for clarifying :) I do see that they are using some sort of matrix to determine the closest valid value, around half the framerate, but I don't know really how that works and how to derive the hex value from the result. Otherwise we could have a few hardcoded values to play around with before doing structural changes. |
No worries, now adding a way to write at a specific pos would be easy enough, something like: put = [5421699608, "OF 59"] Could also add a way to get specific values for put to write like so: pattern = "F3 0F 58 __ 0F C6 __"
# Get all with ** based on pattern and combine
# Value would become "OF C6" here
get = "__ ** __ __ __ ** __"
# Put using get value (due to missing second value)
put = [5421699608] Maybe even use regex in some form with support for grouping. But if we need a generic way of yanking and converting/modifying/using values found for put to use, it gets a lot more complicated because it starts getting into having almost actual code in toml format. So it all really depends on what's required for this feature to work, and I've not yet looked closely enough. |
@SvdB-nonp I just want to provide a (late) update on this, I'm in the midst of finding a place to move to and some other stuff. I will try to look at this after some personal life issues are dealt with. Hopefully you were able to use sekirofpsunlock to play in the meantime.
This in particular wasn't the issue I found, I think we could workaround that as you said, but to me it looked like the actual writing position was based on something found in memory. I'll get back on this eventually. Also for more complex issues as I mentioned in the previous comment, do you think calling scripts would be a good idea? As in copy from memory -> pass to and run script -> get back output and position of which to write, I think it could alleviate from making tuxtrain too complicated, while allowing extreme customization for rare cases. |
Without considering rust-specifics, yes this sounds like a solid plan. The toml can stay relatively simple, and hence readable by users, with a reference to a rust script elsewhere doing the lookup needed. It sounds it could also be a nice basis if other games use the same mechanic later on. |
Not really a new issue, just a confirmation of the issue already mentioned in the Sekiro trainer.
Issue:
The feature Fix game speed for framelock is currently broken as the game crashes when enabled. According to the comments in the file this is due to tuxtrain actually writing past the region that is specified:
Effect
So I got into some Sekiro lately just to see how important this feature is and I noticed that past 120 FPS the game really does require the fix for the framelock.
Trial and error
I have tried playing around with the region and reading a bit in the other projects (see also them mentioned in issue #4 ). However I cannot prevent the game crashes and hence I assume the program always will keep writing more than it should. Probably there is little options working around the issue through the toml file and it requires a code change. Although I am clueless where this is going wrong.
Log does not give a clue, looks correct:
Last attempt was to literally use the values from the log to try to force a more specific location, as shown below, but that has no other effect unfortunately.
(I am not sure where the value
00 00 A8 42
came from, but I just kept using that)The text was updated successfully, but these errors were encountered: