Get the Desktop App for Battle.net Now
- All your games in 1 place
- Log in once
- Automatic game updates
I run on 2GB of RAM FWIW. Per above, 64-bit Ubuntu still gets stuck at login. The OS address space should not be visible to the 32-bit application anyway, yeah?
Edit: My D3 launch script is getting a little ridiculous :)
Edit2: For those who care, it is now:
WINEPREFIX="/media/ssd/Diablo III/wineprefix" taskset -c 0 setarch i386 -3 wine "Diablo III.exe" -launch
"taskset -c 0"keeps the game on a single processor core, which removes a lot of stuttering. Does your game slow down for a second now and then? Give it a try.
Edited by mashdar#1871 on 6/7/2012 12:00 AM PDT
I commented on the wine ticket, and raised the question of whether this counts as a bug in wine.
This actually makes me curious if the same issue occurs under Windows if you use the boot option to enlarge its process address space from 2GB to 3GB:
Is anybody with 32-bit Windows feeling adventurous enough to see if the "/3GB" flag in boot.ini makes the warden cry?
This might also explain why some people were still having problems the "removed from game" bug after installing a 32-bit kernel.
It shouldn't. That's what the -3 does in setarch.
setarch i386 -3 wine "/path/to/Diablo III.exe" -launch
Works for me on Ubuntu 12.04 x64 4GB ram and 4x core AMD Phenom
Also have stable working on
taskset -c 1-3 setarch i386 -3 wine "/path/to/Diablo III.exe" -launch
(for three core limit)
client 22.214.171.12450 enGB and ruRU versions
setarch i386 -3 playonlinux works like a champ :) Played for > 2 hours with no problems.
@Vaux & Mashdar
I run on 2 Gig of RAM as well.
The command isn't literally "/path/to/Diablo III.exe" use whatever your path is. For example, my path is:
/home/kaos/PlayOnLinux\'s\ virtual\ drives/DiabloIII/drive_c/Program\ Files/Diablo\ III/Diablo\ III.exe
Yours is going to be different.
Workaround appears to be working for me as well (latest Debian Testing 64bit with self-compiled patched GIT wine from May 7), many thanks to everyone that worked on finding a solution.
Edit: but albeit running fine, it doesn't seem to run as well as it did before, seem to have impacted performance a bit
Edited by Evanidus#1421 on 6/7/2012 5:14 AM PDT
Someone else realized the problem with just removing the ram. Virtual Memory could be included as well, and who knows what else. Basically we know it's some number related to memory or a 64 bit arch that's being passed to warden and then it eats your processor. Probably becomes negative number and tries to loop up to that number from zero, or it has the entire number and tries to loop up to it with a 32 bit int so it can never reach it.
Edited by Vaux#1580 on 6/7/2012 6:28 AM PDT
Threats of violence. We take these seriously and will alert the proper authorities.
Posts containing personal information about other players. This includes physical addresses, e-mail addresses, phone numbers, and inappropriate photos and/or videos.
Harassing or discriminatory language. This will not be tolerated.