@sjaak327 Yeah, moving these files to AppData or Documents is generally a good idea to bypass this and similar write protections. My fix can be especially helpful for scripts that no longer get updated (or the author simply can't/won't do it). And who knows, maybe R* will actually change this behavior to be not as aggressive in a future update, resolving this issue. Kind of ridiculous to permanently register every single file with DirectStorage.

Regarding the "DirectStorage not enabled" warning: do you still have -forcewin32 in your command line?

@alloc8or no, as i run the game from the launcher directly, not from a shortcut

@sjaak327 Try this one please: https://aka.alloc8or.re/2G3Jm5h4 Debug logging is enabled in this build, which should help figuring out what's wrong.

[01:38:28.884] [debug] [GetIsWindows11OrGreater] winBuildNumber: 0
[01:38:28.885] [debug] [IsDirectStorageEnabled] Returning false due to not running on Windows 11
[01:38:28.885] [warning] DirectStorage not enabled. Stopping.

my computer is running 25h2 26200.7462.

@sjaak327 Made a stupid mistake due to an incorrect assumption about a parameter (Microsoft's annotation can be confusing sometimes). Will be fixed shortly.

@alloc8or such is life :)

@alloc8or I see, there's a lot of misinformation being spread that it's auto-enabled on Windows 10 as well if the requirements are met. I have no plans to enable it, so in other words I don't need this until I upgrade to Win11, at least until Rockstar decides to force Direct Storage for everyone.

Anyway, thanks.

@alloc8or your latest version is now indeed working .

@Unsearchably It's not working on win10 as far as I know, however, I see massive faster loading times on win11. Even on legacy, where this locking nonsense isn't a problem.

@alloc8or On the topic of moving stuff outside the root folder, I don't know if that makes it easier for the coder to work or if there's some other benefit I'm not seeing there, but from the user's perspective that's a bad decision, for 2 reasons:

1. If you run multiple installs that means you need to swap out the .ini every time you run a different installation if, say, you have cars saved in Simple Trainer that are on a map which exists only in one install. Just one example, there's many reasons why one might want to use different .ini for different installations and using the appdata folder for that makes it a hassle.

2. Loading stuff outside the root game folder can cause massive slowdowns, I've experienced this last night when testing Sjaak's appdata version of the trainer. When writing the .ini in the root folder everything saves almost instantly, but when using the appdata folder suddenly saving a car takes like 7 seconds, which can be incredibly frustrating if you're like me and you have over 300 cars saved.

If by any chance you agree with any of this maybe you can convince Sjaak too, I've had no luck.

@Unsearchably that makes no sense, if you have multiple installs, you need to duplicate the ini in any case unless you make a symblink which has the same performance issue you complained about. The discussion here is this: R is messing with permission every time they update the game, leading to people complaining, by moving the ini to appdata, that problem goes away, and I don't have to explain users how to fix those permissions. Technically, moving it out of the game folder and into a single directory in %appdata% would mean you have one ini. I personally don't like that approach because there are technically two games, legacy and enhanced, so I went for the approach of separting those two games. yet if you happen to have two copies of legacy, you would in fact, just use one ini.

@Unsearchably and remember, I gave you options, you can still run your ini from the root dir. it only needs an two line ini i %appdata% which looks like this :

[defaults]
inilocation=c:\whateverdir\trainerv.ini

and that is all that is needed, you keep your ini in the root directory, whatever it may be.

@sjaak327 so if I use this on Enhanced it will load game much faster ?

Works as advertised! Many thanks!

works for me, now i can update and reload my scripts just fine, shvdne still complains about not being able to write to the log file though, weird.

@sparklingspacess The issue with SHVDNE could be unrelated, as I can log normally with SHVDNE.

Great!

@Chiheb-Bacha about this, it turns out the log file was read-only, i changed that and it works perfectly now, i found out about this because of your comment under the shvdne page, thanks dude

@sparklingspacess glad it worked out :) and welcome, anytime.