Update for 1.10.40?

[Baddest-Juju]

Would really appreciate it. 😊

[TheRealBix]

Yep, not working with latest patch :/

[Cube-13]

Yes please, we love you long time!!

[StochasticTinkr]

For the record, its not as simple as "recompiling". It's necessary to find the correct memory addresses of several things that fallout 4 uses. It appears they've rearranged memory a little bit.

[Baddest-Juju]

Well shit

[Mortercotic]

Damn, hope this can be updated. Really helped my game performance.

[StochasticTinkr]

I've done the legwork to find the new addresses. I have my own fork of this project (reworked significantly). It's not quite ready for release yet though.

If xwise is interested in updating this, the addresses I found are:

        const unsigned __int64 offset_fShadowDirDistance = 0x676BA1C;
	const unsigned __int64 offset_iVolumetricQuality = 0x3903FD8;
	const unsigned __int64 offset_bGameUpdatePaused = 0x5AA50E4;
	const unsigned __int64 offset_bIsMainMenu = 0x5B473A8;
	const unsigned __int64 offset_bIsLoading = 0x5A9D300;

I couldn't find one that is pip-boy specific, but the "GameUpdatePaused" address includes pipboy, menu, console, etc...

shadowDistance hasn't been used in the past, so I removed it.

If I have time, I might make my fork "ready for release". I'll update here if I do.

[StochasticTinkr]

I've gone ahead and updated my own version of this here: https://github.com/StochasticTinkr/PerformanceTuner/releases/tag/0.9.0

It is slightly different than xwise's, but functions similarly.

[Cube-13]

Gravy, will give it a try :)

[Zzyxz]

@StochasticTinkr how can i read those adresses from the memory?
-nvm just found, that Cheat Engine was used... sigh how could i forget about that...

[Baddest-Juju]

Awesome, thanks. Does the dxgi_linked functionality still work?

[StochasticTinkr]

@Baddest-Juju: I didn't touch that code, but didn't test it either. So maybe?

[Zzyxz]

@StochasticTinkr Question regarding the functionality. Did you remove the fEmergencyDropFPS&fEmergencyDropRate?

Also, fIncreaseRate&fDecreaseRate is now only hardcoded as it seems, but why removing them?

Thanks for updating the project and reworking it.
I'm also now looking into this topic, but forgive me, i'm a java/web programmer. so c++ is kinda new to me.(Only had basic instructions at the university.)

[StochasticTinkr]

I'm using a completely different algorithm than xwise.
The way it works now:
There is a "momentum" value.
If it is going in the wrong direction, we set it to +1 or -1 depending on the direction it should be going.
If it is going in the right direction, we accelerate it (multiply it by 1.025).
The momentum value is then capped between -500 and 500.

After the new momentum is calculated, we add it to the current shadow dir distance.
We then use the new shadow dir distance to calculate the GR quality (if you have that feature enabled).

[Zzyxz]

Is it normal that the TargetFPS caps the FPS? I'm running normally at 60 fps and i set targetFPS to 48 and it caps it at 48 all the time.
As i want the shadows to reduce only, when i fall under 48 FPS.

At some places, even with shadowdistance 2000 im at 55 fps and with 8000 im at 52 fps. So i'd like to keep my 8000 distance at 52 FPS.(which runs fine)

[StochasticTinkr]

@Zzyxz Yes, TargetFPS is the "cap". I'm not quite sure what you want is really possible. Either way, if you want it to work differently, please start an issue on my repo. The algorithm used to determine shadow distance is a different issue than working for 1.10.40.

[Baddest-Juju]

Zzyxz means it's literally capping the framerate of the game, so it can't render any faster than the TargetFPS that is set in the ini.

[StochasticTinkr]

@Zzyxz, @Baddest-Juju Yes, that is by design. My algorithm is in a few ways similar to xwise's "Advanced" controller. It has the added benefit that it works like the old Load Accelerator did, in that it uncaps during "load" screens.

[Baddest-Juju]

The advanced controller had a simple mode toggle that toggled off the cap, as well as an emergency drop. xwize was still incorporating feedback when all the drama happened and it got taken off of NexusMods.

Would it be possible to separate the cap from the target? i.e. The programming just considering every bit of fps above the target to be functionally the same.

[StochasticTinkr]

@Baddest-Juju Please start an issue in my repo.

[StochasticTinkr]

@Zzyxz Just realized, you might be able to get the desired result if you set "fTargetLoad=120"

[xwize]

Hey StochasticTinker, thanks for doing the legwork finding those addresses. I'll get around to updating the source and put a link to your fork on the main page. I've moved on to other games at the moment so I'm not actively updating the mod. If you've made significant enough changes, which I feel you have then I haven't put any license on the code so you could release your version up on the nexus if you haven't done so already. I'm sure lots of people would appreciate it and I can't see my association being a problem if you've gone through all that effort yourself.

EDIT: Just trying out these new addresses now, nice! I have them working except for the loading status, any ideas?

[Cube-13]

xwize and StochasticTinkr, thank you both for all the work you are putting into this. Those of us with older video cards appreciate it more than you know :D

[thericeking]

I was about to comment but the I saw @xwize comment :( Thank you fro stating this project. @StochasticTinkr Thank you brother for re-building from scratch. I used something similar but developer stopped updating it. This mod is essential to playing FO4. Thank you both for your hard work.

[Baddest-Juju]

TIME FOR EVERYTHING TO BE BROKEN AGAIN, THANKS BETHESDA

https://bethesda.net/community/topic/149/fallout-4-game-updates/6

IT DOES NOTHING HAHAHAHA