Simulation speed not adjusted to match framerate (without rebooting?)

[PeterTh]

I just gave version 1.0 a try, and the simulation speed adjustment doesn't seem to do anything on my system. (That is, the game runs at 60 FPS but also at double speed, both in battle and on the field)

Looking through the log file produced, there's nothing that sticks out to me as not working, but I could still paste it if you think that helps.

Generally, I think it would be a good idea to

• Check for the expected values before any in-memory modification (to make sure you are overwriting what you think you are overwriting).
• Search for addresses dynamically based on some binary signature. This one might not be that important for Zestiria, since there probably won't be too many patches in the future, just throwing it out there. (It's what the later versions of dsfix do to maintain compatibility)

[PeterTh]

After reading user reports elsewhere, I tried rebooting, and that fixed the issue.

Now you know and I know that this shouldn't happen. There are very few things which should change across reboots but not across rerunning the same process without rebooting. I'll look through the code and see if I find anything.

[drdaxxy]

Thanks. We've had a number of these reports and are trying to narrow down the issue.

Paging @Kaldaien @Andon13 but I don't think he reads here much, the thread on Steam's forums is currently our support thread.

If I remember Kaldaien's post correctly, the driver profile change that sets the hardware framerate limiter options for NVIDIA GPUs doesn't apply immediately for everyone. So that should be the place to look. It's set at https://github.com/Kaldaien/FO4W/blob/master/BMF/nvapi.cpp#L503.

Regarding your enhancement suggestions: agreed, we should be signature scanning and verifying what we're trying to write over.

[Kaldaien]

Just so you know, Kaldaien and Andon13 are the same person =P I have Visual C++ configured on my workstation as Andon13 and I never bothered to fix that. Most of the code checked-in appears to be from that username, while all the releases are from this one. I've really got to start using GitHub the correct way.

I agree about the memory scanning as well. I started this project with every intention to solve as much as possible by hooking API calls, but we're at the point now where the stuff happening can no longer be done that way. So, rather than watching for certain runtime behavior I'll have to figure out some patterns in the executable's memory -- not something I've got much experience with to be honest.

---

Framerate limiting was done using NvAPI, and I'll be damned if the driver refuses to cooperate on a lot of systems when a game profile is setup for the first time. After a reboot though, you can generally make changes on-the-fly and the only requirement is that you restart a running program (which I do automatically).

[drdaxxy]

I'm well aware, I was just unsure which one you received notifications from.

Finding signatures is easier than you think, just copy as many bytes as necessary until you've got a byte array that's unique (at least in the module's code), preferably replacing addresses/offsets/immediate values with wildcards. I believe some RE tools can even do that for you.

I'm happy to do that for you, if you provide me with a signature scanner (since you're the expert on writing new features for your codebase here). Or I could write the latter too, if you're okay with having a major feature written by someone who would have to look up how to write hello world in C++ :stuck_out_tongue:

[Kaldaien]

This has been resolved - the framerate limiting part - is integrated into the current test build of 1.0.4. Signature scanning is still near the top of a TODO list, but with no indication that a patch is imminent I'm delaying any work on that.