Running: XRSound-BETA4; however, I have noticed this as an issue in previous versions but never thought to write it down.
Bug: Orbiter crashes on scenario unload. The crash occurs after multiple scenario loads on a single client instance.
<...snip...>
Thanks for the info! I was able reproduce the problem, and I've tracked it down and I'm working on a fix. Long-story-short, XRSound keeps track of all vessels in Orbiter, and that list was not being reset to empty as it should have been whenever the user exits to the launch pad. Over time, then, if you relaunch a scenario enough times (for me it was ~16 times), the vessel in focus uses one of the same vessel handles (pointers) that Orbiter created in one of the previous ~16 runs. Since that handle is already in XRSound's list with a NULL XRSoundEngine pointer, XRSound thinks that vessel should not have default sounds played for it, and so no sounds are played for it.
The reason it crashes on exit to the launch pad after that, then, is because XRSound goes to free up the global music slot, but that slot was never loaded during that scenario run because no vessel that had default sounds enabled was in focus at any time in that latest Orbiter session (this is a separate bug from the first one, but the first one uncovered it).
So the fix, which I'm working on now since it's Presidents Day here and so I happen to be off work, is two-fold:
1) Reset the list of all vessels in Orbiter to empty whenever the user exits to the launch pad, and
2) Check whether the music sound context is NULL when the Orbiter simulation exits to the launch pad.
Since this bug is pretty serious, I'll upload BETA-5 once I have this fix implemented and tested. Thanks again for the good catch! :tiphat: