1. Install a fresh copy of BGEE from Beamdog 2. Untar BG1-npc.tgz in the resource folder for the mods (bg1npc and bg2tweaks, see WeiDU.log) 3. Load the quick save game 4. The game is in the area north of the gnoll fortress 5. If I leave the area on the right side of the bridge heading to the fortress 6. The game crashes
The files can be found in the attached zip archive.
I've applied the 10.11.1 OSX update this morning. Unfortunately, the problem persists.
Did you also try uninstalling/reinstalling BG after the update? Not sure if that would make a bit of difference, but it's worth a shot. I'll try it myself, but it will take the better part of the day to get it done...
I am having the same problems. Running - OS X 10.11.1, Steam, Single Player Game. Was having intermittent issues traveling in the areas around Nashkel. Now I cannot travel out of the Gnoll Stronghold.
I reinstalled yesterday. That did not resolve the problem.
No Mods. The only customization I have is a custom portrait for my character.
Started a new game. Crashed to desktop leaving the bridge to Balder's Gate (Bridge is still closed). Driving me nuts. Probably going to ask for a refund from Steam. I have a $20 unplayable game.
OK, I'm a very un-technically minded person and this is driving me mad. I've been playing the original Balder's Gate II, not the enhanced edition, with no patches. Since upgrading to OS X El Capitan the game will not load. This is so depressing. I'm 50 hours in! Any advice? Do I just have to pray and hope that someone fixes this bug?
It is depressing, ChrisLancaster. I don't know if anyone from Beamdog is aware. Don't know how to alert them, either. I thought posting to this thread might get their attention.
There's gotta be something wrong with this El Capitan OS. I remember reading somewhere on Obsidian's PoE forums that the game also freezed/crashed on El Capitan. I'm not sure if it's something that Beamdog can deal with Regarding BG:EE. But anyway @AlexT and @Dee would surely be interested in investigating the issue when they get the chance.
Funny thing that while BG2EE remains playable BGEE is not. BG2EE uses version 1.3.2064 as game engine. BGEE uses 1.3.2053. Does anyone has problems with IWDEE? IWD uses version 1.4.
BTW, @Dee and all the other beamdog listeners: It's time to make a statement. That doesn't fix the bug but users do not need to waste time reinstalling the game.
@ChrisLancaster you are very unlikely to see a patch to the original game at this point, the enhanced editions are the modern, still supported, versions.
It is quite possible that the crashing behavior is an intentional 'upgrade' in El Capitan, as operating systems are getting a lot stricter about catching certain kinds of code that might expose clients to security risks, and then closing those programs, hard. That is entirely speculation on my part, but if the BGEE series are using any techniques that are deemed 'abusable' (and I suspect many best-practices in the gaming industry of 20 years ago would qualify - anything for performance!) then we are unlikely to see an El Capitan patch that fixes the problem.
Again - that is pure speculation on my part. I remember Microsoft used to go to great lengths to add app-specific hacks directly into the Windows operating system to avoid breaking old software that used such techniques, while making sure new software was not as easily exploited. Raymond Chen had a few interesting blog articles on the topic at The Old New Thing (quite a while back though!)
I recently updated to 10.11 and ran into this problem with area transitions. The crash happens when attempting to leave certain areas. During Chapter 4, these two areas the crash is repeatable 100% of the time: AR0900 and AR2100.
It looks like an issue with changes made to OpenAL and something BeamDog is doing. The crash is in this function: sub_55707A. It looks like a problem when trying to do clean up to OpenAL context in the following function call: _alcDestroyContext (0x55710D). It will also crash when trying to close the device alcCloseDevice (0x55711E). Now, it doesn't always crash. Most of the time context and device are correctly closed going from one area to another. However, in the two listed areas above they will always crash for me. My guess is that there is a bug with OpenAL context/device for these area transitions causing the method to crash when it attempts to free them. I believe all this code has to deal with World Map clean up so I don't think it is too critical.
Since I only spent a short time debugging the problem, I don't really know a full proof solution. It would likely be easier to trace through IE code and track down the problem with the context. It might be getting closed incorrectly before this call thus causing crash. In the interim, if someone wants to get the game working you only need to kill these function calls. The caveat being the game won't do certain clean up causing potential memory leaks. Then again, the game is crashing anyway right? You could use this as a work around to leave these areas, then go back to the unpatched binary until you run into this problem again.
You can also use gdb/lldb to break on these two locations and then return thread.
Example lldb break commands to skip over crash:
---
b 0x005a343a br com add 1 thread ret c DONE b 0x005a342e br com add 2 thread ret c DONE
---
Hopefully this helps and BeamDog comes out with a fix soon.
edit: I have tested using work around patch to get out of area, save/exit, then reloading with original game and everything is working. Afterward, transitions (at least with AR0900) no longer crash even in unpatched binary.
I'm using a vanilla install go BGEE and can't get out of the cloak wood now. Crashes overtime and generates a lot of bug reports. Hopefully someone is monitoring these threads and we get a fix soon
@scient Good catch! Indeed, the issue has something to do with a change Apple made to their OpenAL shared library in El Capitan. We'll let you know when we have a work-around or update.
@Cerevant Perhaps just recompiling it with latest framework might solve the problem or at least throw up a warning if there have been changes to the existing way you are doing things. I only spent like 30 minutes looking into the issue with lldb/IDA. Also, props to you guys on overhauling IE. It was hell trying to make changes to Planescape Torment engine issues at the assembly level for unofficial patches.
@scient our best guys (not me) are on it, and they did spot that it was an OpenAL issue during our quiet period there. We weren't ignoring y'all, we were busily chasing the issue down.
Now all the relevant details have been filtered up to the decision makers to determine when & how this will be fixed, QA'd and released.
Good news to hear; looks like I'm late to the party! I started playing exclusively on my Mac, and I too am running into this issue. Good news to hear it's being worked on; BG:EE is basically unplayable, and it makes me sad But it makes me happy to know that this game has current support, unlike the original, and I can expect to play it again soon
For those desperate to keep playing (like me), the cheat to move areas seems to still work; it's rough needing to look up each area code, but if it suits you, then that'll help for now.
It looks like an issue with changes made to OpenAL and something BeamDog is doing.
This and the fact that there are areas where the issue can be reproduced with much higher probability, got me thinking.
So, here is a temporary workaround until the fixed version is available: Go to Sound options and disable «Ambient volume». That fixed the issue for me.
My test case for curious: I am trying to travel from Cloakwood-1 to Cloakwood-2. I was unable to avoid the issue even by rebooting Steam/OS X (which sometimes helped). So, 100% probability for ~10 attempts. 1. Disabled «Music volume» and «Ambient volume» Result: SUCCESS (two attempts) 2. Enabled «Music volume» Result: SUCCESS (one attempt) 3. Enabled «Ambient volume» Result: FAILURE (three attempts) 4. Disabled «Ambient volume» Result: SUCCESS (>five attempts)
PS People who can confirm or(it's confirmed) deny the workaround please comment.
It looks like an issue with changes made to OpenAL and something BeamDog is doing.
This and the fact that there are areas where the issue can be reproduced with much higher probability, got me thinking.
So, here is a temporary workaround until the fixed version is available: Go to Sound options and disable «Ambient volume». That fixed the issue for me.
This saved my save, thanks @lava . Using BE:EE unmodified on OS X: El Capitain (I hadn't played prior to El Capitain, so I don't have prior experience). I was stuck in Nashkel, such a lovely place.
So, here is a temporary workaround until the fixed version is available: Go to Sound options and disable «Ambient volume». That fixed the issue for me.
thanks - interesting link, and the comments following suggest it may even be my fault! (I'm kind-of responsible for the change of destructor rules in C++11, but everything is a committee decision )
Comments
1. Install a fresh copy of BGEE from Beamdog
2. Untar BG1-npc.tgz in the resource folder for the mods (bg1npc and bg2tweaks, see WeiDU.log)
3. Load the quick save game
4. The game is in the area north of the gnoll fortress
5. If I leave the area on the right side of the bridge heading to the fortress
6. The game crashes
The files can be found in the attached zip archive.
I reinstalled yesterday. That did not resolve the problem.
No Mods. The only customization I have is a custom portrait for my character.
EDIT: Here's the link to the discussion about problems with El Capitan at PoE forums. Maybe it'll lead you guys to some conclusions: https://forums.obsidian.net/topic/82294-osx-el-capitain-has-broken-poe/page-2#entry1741921.
BTW, @Dee and all the other beamdog listeners: It's time to make a statement. That doesn't fix the bug but users do not need to waste time reinstalling the game.
It is quite possible that the crashing behavior is an intentional 'upgrade' in El Capitan, as operating systems are getting a lot stricter about catching certain kinds of code that might expose clients to security risks, and then closing those programs, hard. That is entirely speculation on my part, but if the BGEE series are using any techniques that are deemed 'abusable' (and I suspect many best-practices in the gaming industry of 20 years ago would qualify - anything for performance!) then we are unlikely to see an El Capitan patch that fixes the problem.
Again - that is pure speculation on my part. I remember Microsoft used to go to great lengths to add app-specific hacks directly into the Windows operating system to avoid breaking old software that used such techniques, while making sure new software was not as easily exploited. Raymond Chen had a few interesting blog articles on the topic at The Old New Thing (quite a while back though!)
It looks like an issue with changes made to OpenAL and something BeamDog is doing. The crash is in this function: sub_55707A. It looks like a problem when trying to do clean up to OpenAL context in the following function call: _alcDestroyContext (0x55710D). It will also crash when trying to close the device alcCloseDevice (0x55711E). Now, it doesn't always crash. Most of the time context and device are correctly closed going from one area to another. However, in the two listed areas above they will always crash for me. My guess is that there is a bug with OpenAL context/device for these area transitions causing the method to crash when it attempts to free them. I believe all this code has to deal with World Map clean up so I don't think it is too critical.
Since I only spent a short time debugging the problem, I don't really know a full proof solution. It would likely be easier to trace through IE code and track down the problem with the context. It might be getting closed incorrectly before this call thus causing crash. In the interim, if someone wants to get the game working you only need to kill these function calls. The caveat being the game won't do certain clean up causing potential memory leaks. Then again, the game is crashing anyway right? You could use this as a work around to leave these areas, then go back to the unpatched binary until you run into this problem again.
Search: E8 28 C3 04 00 C7 06 00 00 00 00 8B 46 04 89 04 24 E8 0B C3 04 00
Replace: 90 90 90 90 90 C7 06 00 00 00 00 8B 46 04 89 04 24 90 90 90 90 90
You will also have to resign the binary.
You can also use gdb/lldb to break on these two locations and then return thread.
Example lldb break commands to skip over crash:
---
b 0x005a343a
br com add 1
thread ret
c
DONE
b 0x005a342e
br com add 2
thread ret
c
DONE
---
Hopefully this helps and BeamDog comes out with a fix soon.
edit:
I have tested using work around patch to get out of area, save/exit, then reloading with original game and everything is working. Afterward, transitions (at least with AR0900) no longer crash even in unpatched binary.
I don't believe that many feel comfortable with patching binaries. It's really up to Beamdog to acknowledge the bug and provide a fix. Soon.
Finally. Good news indeed.
Ahh, we are all heroes, you and me and Boo, hamsters and rangers everywhere, rejoice
Now all the relevant details have been filtered up to the decision makers to determine when & how this will be fixed, QA'd and released.
For those desperate to keep playing (like me), the cheat to move areas seems to still work; it's rough needing to look up each area code, but if it suits you, then that'll help for now.
So, here is a temporary workaround until the fixed version is available:
Go to Sound options and disable «Ambient volume». That fixed the issue for me.
My test case for curious: I am trying to travel from Cloakwood-1 to Cloakwood-2. I was unable to avoid the issue even by rebooting Steam/OS X (which sometimes helped). So, 100% probability for ~10 attempts.
1. Disabled «Music volume» and «Ambient volume»
Result: SUCCESS (two attempts)
2. Enabled «Music volume»
Result: SUCCESS (one attempt)
3. Enabled «Ambient volume»
Result: FAILURE (three attempts)
4. Disabled «Ambient volume»
Result: SUCCESS (>five attempts)
PS People who can confirm or(it's confirmed) deny the workaround please comment.
THANK YOU VERY MUCH!!!
http://hacksoflife.blogspot.ca/2015/11/sasl-crash-on-el-capitan-gory-details.html
More news soon.