Configure BetaCraft to not use .minecraft to store files

[MauroFoti]

I have tried BetaCraft with some old indev builds. I've also got the normal minecraft launcher with a 1.18.1 installation, and when I opened that, all the settings (video settings, resource packs and key bindings) were back to default. I'm guessing that BetaCraft changed options.txt and the old format was incompatible with newer version.

I see that the launcher creates a .betacraft folder, why not store there settings and save files?

[jredfox]

I looked into this actually yesterday and it was due to the fact they hard code their appdata per os as minecraft not betacraft. so it's going to pull it from that folder. it doesn't expect or want to use betacraft folder. the user.dir is set to .betacraft but it still in other versions will use .minecraft or minecraft depending on os. Working as intended. If he added a file proxy it could fix this by redirecting all files that try to use .minecraft or the user.home to their proper directory for isometric screenshots but that would require additional work when it already is intended by those minecraft versions. it could be if (fileAbs#getParentFile() == userHome || fileAbs#getPath#startsWith(mcAppData#getPath) redirect otherwise don't. Also Idk in java if there is a set way on doing this or if it requires a patch to the File.class to use said proxy

[jredfox]

update: in order to do a file proxy there are several options. A: replace the File.class which is against TOS if the java vendor is from oracle and is impossible to do so without pre-appending the jar to the bootloader or modifying JNI per JRE major build. B: ASM every class that constructs the new file to a method that creates a file thus providing a proxy. Betacraft I doubt would do this as it then would be modified clients even if it's only in memory. C: use a javaagent to modify the File.class during construction. there are too many limitations you can't add /remove fields or methods. you can't call any new classes that were not previously in there. but it's the only viable option we can hard code the proxy straight into the constructor methods that need them as a patch to redirect the minecraft dir to betacraft/<instance>

edit: there is one last way he could do it method D: change the appdata directory of the files for <= infdev and then change via reflection the values of the files. this is problematic as it can / will change per build on where the file vars are located and will also limit the fix to JRE 8. this is because reflection is impossible post java 8 without modifications to the jdk allowing a pass per module of a reflection library aka backdoor or just straight up modifying reflection to be ok even more difficult and more jdk class patches which would can change per build of the same major version like 100 times in java 9 for instance. however it's an option since minecraft stores the appdata as fields rather then just straight hard coding from what I can tell and then build the file path later

I went ahead and explained this to morestack that it would be good to provide this enhancement for userfriendlyness. both of us already know generally of how this can be accomplished. It may be a while though since the latest launcher is still in a nightly build and I threw like 10 issues at him after betatesting the launcher because it seemed alot more complete then the last time I tried using it. I said enhancement not bug because it's intended by some minecraft older clients to hard code the appdata path per os nothing to do with the launcher.

CONCLUSION: method C: is the only doable method for this project due to the limitations of having to work with oracle jre/jdk the standard java installation as it's not against TOS for any java installation and it evolves not modifying the client and not knowing how / where the File objects are getting instantiated. it also doesn't use messy reflection code and will work even if there is a new field on an old build that omniarchive just found unlike method d would support.

[WSDguy2014]

The issue still persists in the latest version 1.09_16 (portable). I can confirm that in launcher-1.09_16-portable.exe file. Somehow, it's not fixed.

How to reproduce this issue:

1. Create a fresh new instance, name the instance (for example: in-20100223) and select version in-20100223.
2. Before launching the game, if there are files within \%appdata%\Roaming\.minecraft already exist (such as options.txt), remove these files and launch the game.

Intended behavior: Files should create upon launching the game first time at <your launcher-portable app file>\.betacraft\<instance file folder, such as "in-20100223"> on any of your disk storage drive.

Actual behavior: Files created upon launching the game first time at \%appdata%\Roaming\.minecraft on your disk storage drive C:.

[Moresteck]

To be fixed in 2.0