Use old filesystem access

[B-Keeper]

Since a few commits ago, SP uses the My Games folder for saving/loading. I'd like to avoid this at all cost. Is there a way to revert to the original system to use the game's base directory?

Also, it's no longer possible to load any saves made by any previous versions, the game complains about their version being -1 instead of 1. I'm not sure if this is related to the issue above, or a separate one, though.

[ensiform]

+set fs_homepath "" in launch

This is a non release version saves aren't going to keep continuing to work per-se. And pre-openjk saves won't work at all.

[B-Keeper]

Regardless of what fs_homepath is set to, the config file will always be saved to My Games, apparently. Any other way to stop this apart from rip out the current system from the code, and use parts from an earlier commit?

[xycaleth]

I've just tried this myself, and setting fs_homepath "" writes everything, including the config files to the original location.

[xycaleth]

Although it seems it keeps trying to load the config file from the My Games directory.

[B-Keeper]

What I did was setting fs_homepath to " ", then deleting everything from the My Games folder. After restarting OpenJK, fs_homepath was set to the default (the My Games folder) again.

[xycaleth]

It should be "" without any spaces in between the quotes. Are you setting it when you launch the game? (i.e. not in the console).

[B-Keeper]

I've tried "" without spaces as well, nothing changed. I've set it when I started the game (openjk_sp-x86.exe +set fs_homepath "" from the command line). When I try to modify this variable from the in-game console, the game tells me it's write-protected.

[ensiform]

You have to actually use the path, my typing of didn't show up

[ensiform]

Don't put a slash at the end either.

ie +set fs_homepath "D:\Games\SWJKA\GameData"

[B-Keeper]

That didn't help either. After restarting OpenJK, it will default to the My Games directory.

[ensiform]

Did you read the console? because that probably means @xycaleth probably still fucked it up with the cvar code; last I saw it wasn't actually setting it.

[B-Keeper]

Yes, I've checked the console. Here's a detailed description of what I've done so far.

Launch OpenJK from the command prompt with the following command:

openjk_sp.exe +set fs_homepath "C:\JediAcademy-test"

Now check the value of fs_homepath from the in-game console:

"fs_homepath" is:"C:\JediAcademy-test" default:"C:\Users[censored]\Documents\My Games\OpenJK"

So far, so good. Now shut the game down, start it again normally (without any command line arguments). Since the game now starts in fullscreen, and last time I've turned fullscreen off, it's obvious that the config file in the game's base directory is now ignored. But to make sure, check fs_homepath from the in-game console again:

"fs_homepath" is:"C:\Users[censored]\Documents\My Games\OpenJK" default:"C:\Users[censored]\Documents\My Games\OpenJK"

And here we go. No matter how many times I try, it will always end up like this.

[ensiform]

It doesn't save the path, it has to be entered every single time. IE with the shortcut or batch file.

the cvar is CVAR_INIT which means on startup only can it be changed.

Because the cvar must be set prior to the filesystem being initialized and it cant read a config file without the filesystem being initialized so, this is why it must be set during the command line arguments via cmd.exe or batch file or a windows shortcut or some wrapper application. This is the new default because of the way windows now handles writes. There will be a portable version during the final release that will let you run it all from 1 directory but that'll be a separate exe.

[B-Keeper]

Nice. So until the final release comes out in a few years, I need to hack the code myself to get the old system back...

[ensiform]

Or use a shortcut. Is it really that difficult? This is to prevent the need to run as admin for program files installs. And it is Microsoft guideline who doesn't allow the writes to take place. And makes it more similar to unix ecosystem with user home directory.

[B-Keeper]

Not difficult, but why it was necessary to completely replace the old system with this? There should have been an option to use the old behavior.

But that's okay, I can always re-implement the old code if I want...

[mrwonko]

It was necessary because normal users do not have write rights in the "Program Files" directory in recent Windows versions for security reasons, so applications should store their data in the user's "Application Data" folder, though games often use "My Documents" instead.

[B-Keeper]

That could be true for the Program Files directory, but many people (including me) don't install their games to that place.

I don't say the new system is a bad thing. But completely ripping out the old code, thus leaving no way to get things to work as they always used to, is a bad thing.

[ensiform]

The old code isn't ripped out. New code was added, and I've told you how to get it back to that way already. I'm not gonna have this discussion once yet again. Use the startup targeting and be done with it, stop complaining like a little bitch as though you're the person who's got a full released copy.

You (and the "many" people including myself are in the minority and as mrwonko explained it is not something we are allowed to accept anymore) Its physically impossible to detect if there is write capability as a program files folder because windows silently allows it anyway in the virtualstore secret folder. Which is why there will wait for a special portable version later. Assuming you aren't going to be capable of compiling it yourself.

[B-Keeper]

Not really, what you have told me is to create a shortcut to force the new system to imitate the original. Using the original would mean to set a cvar, or build the exe with a define, or whatever, to make the game use the base directory without the need to tell it (by supplying a full path to it each time) where the said directory is. The current system is not portable at all.

[...]

[xycaleth]

Please note that ensiform's views and opinions are his own and don't reflect the views and opinions of everyone working on OpenJK.

About building the exe with a define, I believe MP has something like this, where you can add PORTABLE_VERSION and it will compile a "portable" version of the exe. This essentially makes the changes to the file system invisible (I say invisible because all it does is force fs_homepath to be blank by defaut like you did manually using the batch file) and makes JKA act like it did originally. I left this out when I was porting the changes to SP from MP as I wasn't aware that anyone had problems with it. But I'll take a look at porting this extra bit across as well seeing as it sounds like it is useful after all.

[B-Keeper]

Thank you, and sorry.

[ensiform]

Yes it does seem the sp version is missing the portable version define.

Stop spouting nonsense please. Games for windows is not mandatory by any means. You act like tons of games support running without a homepath without a switch or console variable but there really isn't. Or their filesystem as a whole doesn't work anywhere similar to a point that a config file could be loaded before the filesystem. (It can't be in q3 terms)

How exactly is following standards with filesystem and the other minority OSes filesystems have anything whatsoever to do with gameplay changes.

[xycaleth]

Right! If you're happy with compiling the source code yourself, you can compile a portable version. You'll need to generate visual studio project files using CMake with the BuildPortableVersion switch enabled. You can this either by running cmake like this: cmake -DBuildPortableVersion=ON .. Or using the interactive prompt: cmake -i .. Which will let you set the portable version setting, and a load of others (which you can leave as default if you don't know what they do).

Let me know how it goes, and if it works because I haven't tested the portableness of the portable code yet :P

[B-Keeper]

Builds and works fine. Thank you for fixing this.

[xycaleth]

Awesome :) No problem.

[ensiform]

Ideally we want to have an exclusive build portable option and if that is not true it will have an option to build extra versions of sp engine, mp engine and mp ded engine with that (default not so not to clutter msvc for most). Perhaps we can discuss with @deepy if he's fine with allowing portable pre-built versions on buildbot for windows with the regular.

[deepy]

Building an extra binary is no problem from buildbots side.