Installing the DDO Client on a New MAC

[Hulioh]

@sea_dragons, @Shadow_Flayer, I was having the same issue described above, so posting this here in the hope it might help;

I'm running on an Intel High Sierra, OS 10.13.6, using Wine 1.8.6 (so likely older than yours!) and I found this fix described in a LOTRO thread (https://forums.lotro.com/forums/show...age-quot/page4) from 2019 where Mac users were having the same frustrations.

What I'm doing:

1. Before launching DDO, I'm opening Activity Monitor (from Applications > Utilities) and a spare browser window (the browser window doesn't seem to be absolutely necessary, it just speeds things up when the launcher is trying to open a window to Microsoft)

2. Launch DDO - get to the message described in the quote above, and everything stops.

3. Go to Activity Monitor, where wine-preloader seems to be taking up all the CPU work (NOT the '64' version, just the plain preloader). Quit that.

4. Wait just a sec while the DDO launcher tries to open a link to download MS Visual C++ (404 not found, but that doesn't matter). Close that browser window.

5. Back in the DDO launcher, normal service is resumed. (First time I did this, this morning, I then had to wait ages for the U56 patch to load too - but there was at least progress and the game does now play).

It's very much a workaround, not a fix, but for me at least it does work. I hope the same for you too.

Good luck and I hope you can get back on soon.

I'm having the same problem on my Mac since the last update. I'm running DDO on MacOS 10.14.6 (Mojave).
I tried the workaround suggested above, and got as far as step 4: closing the browser window on the DDO launcher's efforts to open Microsoft links.
This got me past the stalled screen the OP mentioned, saying "Installing: Microsoft Visual C++ 2010 Redistributable Package (x64)", and brought up the login screen (which info I entered) and then the server selection screen. However, as soon as I pick a server and click the button to log on, I get a brief message indicating I am being placed in line to access the server, and then....crash. No indication as to why.

I did note that the wine preloader in Activity Monitor has several instances, as well as several instances of the 64-bit wine preloader. As suggested, I only quit the wine preloader showing high CPU usage. DDO still crashes upon selecting a server, and ultimately, all of the wine preloader processes disappear shortly afterwards.

Thanks all the same for getting me a couple of screens closer, but unfortunately, still no dice for this Mac user. :/

[sea_dragons]

@sea_dragons, @Shadow_Flayer, I was having the same issue described above, so posting this here in the hope it might help;

I'm running on an Intel High Sierra, OS 10.13.6, using Wine 1.8.6 (so likely older than yours!) and I found this fix described in a LOTRO thread (https://forums.lotro.com/forums/show...age-quot/page4) from 2019 where Mac users were having the same frustrations.

What I'm doing:

1. Before launching DDO, I'm opening Activity Monitor (from Applications > Utilities) and a spare browser window (the browser window doesn't seem to be absolutely necessary, it just speeds things up when the launcher is trying to open a window to Microsoft)

2. Launch DDO - get to the message described in the quote above, and everything stops.

3. Go to Activity Monitor, where wine-preloader seems to be taking up all the CPU work (NOT the '64' version, just the plain preloader). Quit that.

4. Wait just a sec while the DDO launcher tries to open a link to download MS Visual C++ (404 not found, but that doesn't matter). Close that browser window.

5. Back in the DDO launcher, normal service is resumed. (First time I did this, this morning, I then had to wait ages for the U56 patch to load too - but there was at least progress and the game does now play).

It's very much a workaround, not a fix, but for me at least it does work. I hope the same for you too.

Good luck and I hope you can get back on soon.

Okay, that was unexpected. I had no idea there was a background thread that wasn't running the UI window and that killing that thread wasn't killing the user interface to the launcher. Knowing this, I can copy the process ID from 'top' running in a Terminal window into another terminal window to run kill [PIDxxx] and immediately proceed to killing the new browser window. This is weird. It does unstick the launch process, but it's apparently needed every time. Nuts. Thanks for the tip ... but ... nuts!