In the beta, any read me since renaming to dxgi.dll doesnt seem to work

[The Glow]

Mainly trying FF15. I got a beta key and trying to mess around with it and so far its not working as I expected. I tried renaming specialk64.dll and putting it into the FF15 folder. The game launches but no visuals, just a gray screen.
I tried launching Skif, went to game management and clicked FF15. This sadly forced it to update from 1.25 to 1.29 so I will need to undo that later. I thought since it launched it it would have SpecialK going, but that wasnt the case. I tried Manual injection tab and not seeing anything there. I tried running the service and then the game and this seems to work. Sadly closing FF15 and reopning wouldnt work, Steam said it was still running. Task manager didnt have any entries for it.
I had to fully close steam and reopen it to get the game to run.
It also seems to ignore the Reshade I have in Documents\My Mods\SpecialK\PlugIns\ThirdParty\ReShade
So it seems I'm doing a few things wrong.
is there a way to pop the dll in so it always runs as needed when the game launches or will I need to keep toggling the service on?
Edit: I saw another post mention launching via Skif with ctrl-shift would offer to copy the dll locally. I did this and it looks like it did the same thing, used the Specialk64.dll and renamed to dxgi.dll but again it launches with a totally gray screen. I removed existing dxgi.ini in case of conflict, no change.

[The Glow]

Oof, I dont know whats going on. So it appears to work only with Global injection. I guess thats ok for the time being. I saw I could install Reshade as usual, dxgi.dll in the game folder since I dont have special K there and that appears to load fine as well.
It seems I've lost the rivatuner osd and cannot get it up.
However the biggest issue by far is it's as if I'm in read only mode. everytime I launch my display and graphics settings are back to default. I can change, back out, see it says saving settings. Go to the savestorage/GraphicsConfig.ini and see its changed. Close game, relaunch, back to default graphics settings.
Also exiting from in game always seems to leave the exe running in Task manager and trying to relaunch shows its still active until I kill it in taskmanager.
Edit: The hits dont stop. I have a redirected documents folder for windows. So I have H:\users\mydoc\ etc which is where the game was saving to fine, or at least when it was 1.25.
Now its ignoring my windows settings and running from c:\users\mydoc\ etc. On top of that its running backups from c:\programfiles\steam\userdata. So if a file doesnt exist in the C users section its defaulting to the steam directory ones. If I manually create/copy from the H folder to the c users, then it saves my settings.
Wow. This is a cluster.
If I use the older SpecialK from the FFXV thread, then it honors my windows redirect to the the H drive.
Ok wow, this took some figuring out. So if I use the newer SpecialK with the Global injection it will LOAD the saves from the C mydoc folder however any changes I make to graphics SAVES to the H mydoc save folder.
And no specialk it loads and saves from C mydoc.

So,
Old Special K: Loads from and saves to redirected H:\mydoc
New Special K w/ global injection: Loads from C:\mydoc, Saves to H:\mydoc
No special K: Loads from and saves to incorrect C:\mydoc
And out of nowhere rivatuner osd popped back up.
It seems like only FF15 is not honoring my redirecting user doc folder as I just went into the parent directory and the only entry is my games, ff15, steam, my steam id, and then ff15's save data.

Edit2: Ok, I made a symbolic link in the c doc folder to the h and now it appears to save and load properly, so I'll give this a whirl for a bit and see if its any better. Back to 1.25 and works good. Ill confirm SpecialK works there, then upgrade back to 1.29 to compare.

[Aemony]

Final Fantasy XV has a bug that causes it to load and save game data to %USERPROFILE%\Documents\My Games\FINAL FANTASY XV, and does not respect a relocated Documents folder.

Special K received a game-specific fix/override for that behavior a few years ago that, as you noticed with the old Special K, loads and saves to the correct redirected folder.

As for why that doesn't seem to work properly on the newer version, I'm not sure.

[The Glow]

Originally posted by Aemony:

Final Fantasy XV has a bug that causes it to load and save game data to %USERPROFILE%\Documents\My Games\FINAL FANTASY XV, and does not respect a relocated Documents folder.

Special K received a game-specific fix/override for that behavior a few years ago that, as you noticed with the old Special K, loads and saves to the correct redirected folder.

As for why that doesn't seem to work properly on the newer version, I'm not sure.

Ok thanks, for a moment there I thought I was going crazy. So there were 3 potential spots. Earlier it was as bad as even making a new save, would show, exit, go back in and it was showing the previous saves. Odd it wouldnt create the config files in the new location etc.
But as mentioned it seems a symbolic link addressed that.
So my only question would be SpecialK itself now. Any idea why the specialk64.dll renamed to dxgi just gave me a blank/gray screen? And what service is Special K running? I didn't see anything under services.msc so I guess its just some exe's via task scheduler if I enable at logon?

[Aemony]

Let's see...

* Local injection, that being dxgi.dll, runs within the game process itself. It's possible that the back screen game from having both methods enabled at the same time, perhaps? Otherwise I'm not sure -- you can rename it to d3d11.dll though and see if that works better.

* Global injection through the new SKIF tool uses three rundll32.exe processes. Technically only two is necessary, but the third one is used by Windows to proxy the 32-bit DLL file from the 64-bit rundll32.exe file (which SK calls) to the 32-bit rundll32.exe file instead.

You can spot and terminate these from the Task Manager, although adding the command line column might be desired so you can separate these from possibly other rundll32.exe processes: https://images.aemony.se/sharex/Taskmgr_2020-05-19_12-37-24.png

The reason for these rundll32.exe processes are because that's how you can run a standalone DLL file the easiest in Windows, and since all of the code is contained in the DLL files we don't need to run anything else.

With the SKIF frontend tool on Steam, Kaldaien also wanted to prevent scenarios where "is playing Special K" would constantly be written in the friends list of Steam users. However to do so necessitated moving the 64-bit global injection (which in pre-Steam times where handled directly through the SKIM64.exe process) over to rundll32.exe as well, which is why both the 32-bit and 64-bit DLLs nowadays are being run that way.

In fact, apparently Steam is so good at tracking process launches and child processes and whatnot that what SKIF actually does to circumvent "playtime tracking" of Special K is to set up a single scheduled task in Windows that is then started, and that task is what runs the rundll32.exe processes. After it have launched, SKIF removes the task again since it has fulfilled its purpose.

Basically, it is surprising how hard it is on Steam when you want an application (or game as well, I guess) on Steam to _not_ track playtime among users nor require them to be constantly in "playing" state.

[The Glow]

Originally posted by Aemony:

Let's see...

* Local injection, that being dxgi.dll, runs within the game process itself. It's possible that the back screen game from having both methods enabled at the same time, perhaps? Otherwise I'm not sure -- you can rename it to d3d11.dll though and see if that works better.

* Global injection through the new SKIF tool uses three rundll32.exe processes. Technically only two is necessary, but the third one is used by Windows to proxy the 32-bit DLL file from the 64-bit rundll32.exe file (which SK calls) to the 32-bit rundll32.exe file instead.

You can spot and terminate these from the Task Manager, although adding the command line column might be desired so you can separate these from possibly other rundll32.exe processes: https://images.aemony.se/sharex/Taskmgr_2020-05-19_12-37-24.png

The reason for these rundll32.exe processes are because that's how you can run a standalone DLL file the easiest in Windows, and since all of the code is contained in the DLL files we don't need to run anything else.

With the SKIF frontend tool on Steam, Kaldaien also wanted to prevent scenarios where "is playing Special K" would constantly be written in the friends list of Steam users. However to do so necessitated moving the 64-bit global injection (which in pre-Steam times where handled directly through the SKIM64.exe process) over to rundll32.exe as well, which is why both the 32-bit and 64-bit DLLs nowadays are being run that way.

In fact, apparently Steam is so good at tracking process launches and child processes and whatnot that what SKIF actually does to circumvent "playtime tracking" of Special K is to set up a single scheduled task in Windows that is then started, and that task is what runs the rundll32.exe processes. After it have launched, SKIF removes the task again since it has fulfilled its purpose.

Basically, it is surprising how hard it is on Steam when you want an application (or game as well, I guess) on Steam to _not_ track playtime among users nor require them to be constantly in "playing" state.

Thanks. Ill look up about possible dll options. When I initially tried I didnt have skif running at all. Its just gray, and it would create a dxgi.ini so it was processing it, just not properly.
So I'll try that again and if not I guess I can just add a manual toggle since I dont know how often Ill be play 15 since these headaches and I just had some friends jump back on FF14.

[Aemony]

By the way, note that the use of rundll32.exe and whatnot is specifically to allow global injection without having SKIF running, if that weren't clear :)

[The Glow]

Originally posted by Aemony:

By the way, note that the use of rundll32.exe and whatnot is specifically to allow global injection without having SKIF running, if that weren't clear :)

I came to that conclusion when I hit start service, closed it, reopened it and it said the services were still running.

[The Glow]

No dice on local. Specialk64 renamed dxgi.dll, d3d11.dll or dinput8.dll just gives a gray screen.
I guess I'll just stick to the global for now. I usually don't like stuff running if not in use.
I see the Servlet batch files so I could try and bake one into FF15 launching, but I'm not the best at batches and closing software when done.