openBVE Freezes after applying brakes

Hello, I've installed openBVE on my Mac (Mac Os X Lion 10.7.4. MacBook Air) and tried it on LU Northern Line. Everything seemed perfect until I started to break. Affter applying it, the game freezes. I also tried it on LU Bakerloo Line, but effect was the same, I tried to assign another key for break, but again the same effect.

Somebody please help me! Thank you!

This seems to be a known issue which was posted to the old OpenBVE discussion boards (which have now closed). What version of Mono are you running? Where did you download it from?

I've got Mono 2.10.9 build 1, which I've downloaded from http://www.go-mono.com/mono-downloads/download.html

And openBVE was downloaded from http://www.openbve.org/Download

Try running the official build. Make sure you have SDL and OpenAL installed.

I already got SDL and OpenAL installed, but I reinstalled them from your links, but again, BVE freezes.

I cannot run the official build, because it is fow Windows, so my Mac can't read the exe format.

axSys wrote:I already got SDL and OpenAL installed, but I reinstalled them from your links, but again, BVE freezes.

I cannot run the official build, because it is fow Windows, so my Mac can't read the exe format.

Mono actually reads .exe files. If you can't manage to launch them, try running them from the Terminal.

Tried. And from the Terminal as well.
It opens with The Unarchiver and then closes. Nothing happens.

you're supposed to type this:

Code:

mono OpenBve.exe

The same effect with the official build

1. Try other routes and trains.
2. Try disabling sound.

Nothing. It still freezes

Try the alpha version of Mono (2.11.2) linked from your download page. *Should* be relatively stable even though it's labelled as alpha, and you can always roll back if it causes problems elsewhere

Can you also try the official Railsimroutes 323, as this definitely should work as this should have full functionality on all OS's. (Some trains have Windows only plugins, and while they should work with default features, we need a known point of reference)

Cheers

Chris Lees

http://www.bvecornwall.co.uk

My personal feel on these sporadic problems with the Mac, is that it's likely a problem in one or more of the dependencies. Given that they are not seen on other platforms and the only difference is in the dependencies.

The only real way of knowing is if someone with a mac problem, is able to run openBVE in a debugger to find out where problems are occurring. So that work a rounds can be found and bugs if needed can be reported to dependency developers.

@Andy - You're pretty much on the mark with the dependencies theory. Speaking from my own experience as a Mac user for 20 years I can say that knowing HOW to properly install and operate stuff like Mono is going to feck most Maccies from the start.

I told Michelle this, ages ago. She could never get the message either. Maccies are 95percent+ NON technical types. They tend to be creatives ata high level (graphics, publishing, music etc) who use Mac because Mac delivers without the distraction of being a programmer or system expert.

It is never going to be possible to make OpenBVE Mac-user friendly until such time as an installer is provided to configure EVERYTHING needed, up to the point where the user just clicks the BVE start icon in the apps folder (or its alias).

And don't start talking about de-buggers to Mac users (like me), cos dem-buggers wouldn't have a clue where to start.

Sadly Gray, for all those Apple Mac users, I'd say your right on those points unless an Apple Mac user with some technical expertise materialises.

This issue was bugging me as well. Since I couldn’t find any solution on the web I had a look at this myself. From the crash logs it seemed that the OpenAL implementation on OS X gets into a deadlock when you apply the brakes in OpenBVE.

So I downloaded the OpenBVE source, installed MonoDevelop and stepped right into the code. And for sure: As soon as I started braking my train the program froze. This was easily reproducible. When it happened OpenBVE was trying to stop playback on a buffer with a duration of 0. This causes a deadlock in OS X's OpenAL lib in 100% of the cases. (Read: In each of the at least 3 dozen tries I made.)

I tried various approaches to prevent that from happening. The most workable solution so far seems this:
In OpenBve.Sounds.LoadBuffer() I changed the code to no longer try getting a buffer from OpenAL if the duration of the sound we’re dealing with is 0. Or in other words, I changed the if-statement in Sounds.cs, line 177 to look like this:

Code:

if (buffer.Origin.GetSound(out sound) && sound.Duration > 0)

The code I was using is from the openbve_stable_1.4.2_source.zip that is found here: http://www.openbve.org/Download/source-code

Now I am certainly not familiar enough with the OpenBVE source to even have the slightest clue if that may cause any side effects. But at least after 2 hours of playing I didn’t notice any strange behaviour. And, most of all, the game doesn’t stall any longer when applying the brakes.

Can anyone incorporate that change into the code base (if it makes sense to you, that is)?

Thanks for the above explanation, but is there a way to do it without using the source code? As a non-technical Mac user, I could make the change above but have no idea how to compile the source into a Mac app like the one provided on openbve.org