0.4.0 Can't locate bottles

[MysticalOS]

First Step, UNCHECK "use separate bottles path" Patch 23.5 launch.

I use a custom bottles path already via the codeweavers plist editing (external plist, not one inside app bundle), which is why I didn't want patch messing with them at all. Somehow it still does. Does unchecking "use separate bottles path" write default bottles?

[italomandara]

Unchecking doesn't replace the config, so you'd be ok in that case

[MysticalOS]

Yeah, it didn't work. I ended up modifying my crossover manually by just updating libs/etc myself because whatever patcher does broke detection of my bottles

tried twice. with that box unchecked. after patching crossover app finds no existing bottles

[italomandara]

Yeah, it didn't work. I ended up modifying my crossover manually by just updating libs/etc myself because whatever patcher does broke detection of my bottles

tried twice. with that box unchecked. after patching crossover app finds no existing bottles

I just checked this works fine for me not sure what's going on when you have a customized file but should work just fine theoretically.

[MysticalOS]

no idea, my bottle is defined per https://www.codeweavers.com/support/wiki/mac/faq/cxofficemacbottlelocation defaults write com.codeweavers.CrossOver BottleDir <path>

and that somehow gets broken by patcher. it only started recently. I tried to find what modified file broke reading the external path but unsure what change is breaking it.

[italomandara]

retry with your own patch, take note of the file date and time then patch without the option, if it patches it anyway you should see a backup file named _original. I double checked and it does what is supposed to do. maybe the first time you patched it it didn't have yout modified path and copied the stock configuration file in _orig then when you repatch, probably just restores that?

[MysticalOS]

I don't think you are understanding. the above does not modify any files in bundle at all, it modifies the prefs file OUTSIDE of app, which the app reads on launch unpatched but patched it ignores it so something is changing the behavior of reading external file. the app is UNPATCHED until i patch it with cxpatcher, and that breaks reading preferences file

[MysticalOS]

and i've tried 3x now. vanilla just freshly unzipped crossover, works. run cxpatcher on it, broken, unable to read custom path defined in prefs file

Only other problem i can think of is if patcher is now modifying the app bundle identifier, then it's altering the expected prefs file.

ie if you are changing it to cxcrossover in app bundle or something then it won't read com.codeweavers.CrossOver on load it'll try to find com.codeweavers.CXCrossOver or whatever modified bundle is?

[italomandara]

and i've tried 3x now. vanilla just freshly unzipped crossover, works. run cxpatcher on it, broken, unable to read custom path defined in prefs file

Only other problem i can think of is if patcher is now modifying the app bundle identifier, then it's altering the expected prefs file.

ie if you are changing it to cxcrossover in app bundle or something then it won't read com.codeweavers.CrossOver on load it'll try to find com.codeweavers.CXCrossOver or whatever modified bundle is?

Not doing that, also the cxpatcher for CX 22 does the same but it works ok.

[MysticalOS]

the 22 patcher didn't have checkbox for separate bottle, at least last version I used, and it had no issues.

[italomandara]

the latest version has it

[MysticalOS]

🤷‍♂️ Currently making a python script that just automates copying the files out of cxpatcher and into crossover since that seems to work. just replaced dxvk, gptk, and moltenvk and it still works and reads my custom bottle paths.

Don't know what to tell you, cxpatcher used to work for me until the code changes for changing bottle paths. regardless of option on or off. So this is easiest workaround for me since it's all i need patcher to do. I can understand why the custom bottle code exists now, so average users don't bug codeweavers, so I won't even ask for a simple "do it the old way" option. I'm fine doing it this way from now on. Thanks for your time.

[italomandara]

I updated the binary check that, there was crossover.inf being overridden

[italomandara]

Also I think this wasn't clear enough in general using CXPatcher on something modified in other ways isn't wise, i'm sure there's an explanation to what happened to you, I could add a new feature that let's you edit the path so that everything is in my control and if anything goes wrong i couls be able to replicate.

[italomandara]

https://github.com/italomandara/CXPatcher/issues/139

[marcolaux]

@italomandara I have the same issue but I did not modify anything.

• With the vanilla installation my bottles were in Application Support/CrossOver/Bottles
• after patching the bottles can't be found and new ones get created in ~/CXBottles

[italomandara]

@italomandara I have the same issue but I did not modify anything.

• With the vanilla installation my bottles were in Application Support/CrossOver/Bottles
• after patching the bottles can't be found and new ones get created in ~/CXBottles

It's not the same problem, that's intended, if the toggle is on that's what's the toggle for

[italomandara]

in order to have the same bottles path disable that toggle, but then games may not work because CXPatcher needs to add new libraries and using an old bottle created with the original Crossover app will conflict with that, that's why we have it enabled by default.

[marcolaux]

in order to have the same bottles path disable that toggle, but then games may not work because CXPatcher needs to add new libraries and using an old bottle created with the original Crossover app will conflict with that, that's why we have it enabled by default.

alright, got it