wrong shader cache used on updated games

[emko]

BOTW is 488181bf but after update it becomes dcac9927 Budford keeps creating the 488181bf shader file instead of the dcac9927

[emko]

yes this is a Budford bug, so whats happening is that CEMU always uses the hash of the opening .rpx for the shader cache name looks like Budford is reading the mlc01 folder for updates/dlc etc and using the hash of that .rpx instead.

fixing this should also fix all the issues with not knowing what shader cache belongs to what game now it should all match up correctly

[emko]

no it does not, CEMU hashes only the opening rpx you opened in CEMU so it wont change the cache name if you have installed game updates, anyways easy to see if you read the code and you can even do the hash your self Budford hash is coming from the updated rpx the hash of the update in my cases is 488181bf and this is exactly what Budford is showing instead it should be showing the hash of the opening rpx dcac9927

simply stop budford from using the hash of the dlc/update file and it works just like CEMU i did this and now its working correct

again this has nothing to do with CEMU this is a bug with Budford

if (gd.Value.SaveDir.StartsWith("??") || gd.Value.SaveDir.Contains(".")) { if (!gd.Value.Image) { gd.Value.SaveDir = Tools.HashGenerator.GetHash(gd.Value.LaunchFile).ToString("x8"); } else { gd.Value.SaveDir = Tools.HashGenerator.GetHash(gd.Value.RpxFile).ToString("x8"); } }

see how if you have DLC/UPDATE it uses that for the hash????? instead of the LaunchFile ???

[emko]

yes your done because dcac9927 is correct........

[emko]

@SteveLeafo can you look into this? i don't know much about coding but i manage to fix this and build it after installing visual studio, i would make a PR but i just basically removed the else check

else { gd.Value.SaveDir = Tools.HashGenerator.GetHash(gd.Value.RpxFile).ToString("x8"); } }

i am sure there is a reason you are getting the DLC/UPDATE rpx hash but i am not sure for what

[SteveLeafo]

Hi, sorry I haven't replied earlier...

OK, just to make sure I understand correctly: Cemu is expecting dcac9927 GetHash(gd.Value.RpxFile) = 488181bf GetHash(gd.Value.LaunchFile) = dcac9927

And it is the fact that Budford is using 488181bf that is causing the problems?

The code inside that else statement should only run if you are using .WUD or .WUX files. When using these files, Budford will extract the .RPX file from the WUD / WUX image to something like C:\ProgramData\Budford\WudData.

So, I guess the question is, are you using WUD or WUX files?

I have checked in a small change that may help in the interim while I search for the source of the problem.

If you have time and could update to the latest code and let me know if it helps, that would be awesome.

[emko]

yes that is correct Budford is reading the hash of the rpx in the mcl01 folders instead of the launch rpx, no i dont have wud or wux when i compiled with that commented out i get correct hash dcac9927, removing the mcl01 folder also show correct hash so it does record it from the update/dlc rpx of the individual games.

https://i.gyazo.com/a2589d45ecce77cfa34e487facd1b0fb.png

ok thanks i will test out the latest version

[emko]

okay i figured it out your right the problem was that i had my update and dlc and game folder in the same place i told Budford to scan the games, i then noticed it only showed the update .rpx for the game that hash is 488181bf so i moved my update and dlc folders out and rescanned that fixes the paths to the game .rpx but it does not rehash the hash so you end up with the 488181bf instead of the new paths .rpx dcac9927

my Wii U games folders was like game x game x update game x dlc
etc

i guess i thought my change fixed anything because i started from scratch with the build version and since my folders didn't change the correct .rpx was scanned in. I thought it was reading the mcl01 folder :( i feel stupid now

maybe on rescan do a hash again? or is that bad? or maybe if possible detect update/dlc files and show what version etc you have for the game but only show hash for main game .rpx

[SteveLeafo]

Hi, I think your idea to update the hashes is a good one.

Also, I think Budford really was to blame here, as it was naively assuming that the search folders would only contain the original game files.

From V1.0.72, Budford now also checks the Title Version for all the games it finds. If it finds multiple .rpx instances of the same game, it will use the .rpx files from the folder with the lowest (earliest) title version.

When this occurs, the SaveDir Hash is recalculated based on the lowest title version to ensure the correct value is used.

I believe that this should stop this issue from occurring again in the future.

Thank you for raising this issue and especially for all you help in tracing down the problem.

Cheers, SteveLeafo