Jump to content

Christopher Collins

VATSIM Developer
  • Content Count

    189
  • Joined

  • Last visited

Community Reputation

4 Neutral

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I've commented on this many times before in the forums here and at x-plane.org, but you can't mix stereo playback and monoaural capture on bluetooth audio devices - that requires the use of two separate bluetooth profiles (A2DP+Handset) which basically results in undefined behaviour (and as a result, is not supported). If you want to run aircraft and simulator audio through the headset as well, you will need to use a conventional USB headset or a wireless headset that uses a proprietary link (not bluetooth) that supports stereo playback and monaural capture simultaneously.
  2. As always, It'll be ready when it's ready. I do not give release estimates until I'm sure I can hit them. You can always use the GL renderer for now, or if you must have vk/metal, please use another client if you can't wait. I will not be cannibalising XSB 2.x for the X-Plane 11 users - I've always made it clear that X-Plane 10 was getting one last supported release, and that's what 2.x is. I haven't had a lot of time the past few months to do anything, and in the few moments I've had, I've been largely trying to fix the TCAS support for 11.50 correctly so I can get back to fi
  3. This suggests that the voice system thinks you're not authorised to use it. The most common cause is your password being the wrong case - Make sure you have entered your password exactly (including the capitalisation) as it was supplied to you - whilst the traffic server will accept either case, voice requires that it matches exactly.
  4. The log told you everything we know: For whatever reason, in that attempt, Portaudio can't open your devices - because we're using the portaudio API to do synchronised full-duplex audio, we don't actually get told which device failed by the API. (see the source at https://github.com/xsquawkbox/AFV-Native/blob/master/src/audio/PortAudioAudioDevice.cpp#L89 - we do a single open for both paths and report what we get told by the portaudio interface) Ultimately, this is not an XSB or AFV-Native bug, something in your config just doesn't like the parameters we're using or you're trying to byp
  5. Yes. There are instructions on how to do this on the x-plane.org forums somewhere (the rough procedure hasn't changed since it was introduced before my time), but the rough outline is: Install XSB on every system. On the "primary" system (the one running your flight dynamics and coordinating the others), set up audio and your keybindings. Enable the Proxy in XSB. This system MUST be your voice and XSB text/command system - trying to use any other system in the setup will likely cause problems. On the "secondary" systems (all the others), Disable XSB's voice support (
  6. Just because there seems to be some confusion about this: You should not run the standalone AFV client with XSquawkBox 2.0 or newer. The advice about this on the AFV website is outdated (the PDF manual was updated, but the website itself never was). XSquawkBox 2.0 has full AFV functionality built in, including some extras, such as per-radio volume control in correctly rigged models. Running the Standalone AFV client with XSquawkBox is unsupported - It will cause problems if both clients are configured correctly. If you cannot work out how to configure the voice system in X
  7. Do not run the standalone AFV and XSquawkbox together - it doesn't work and isn't necessary since the release of 2.0. If you do, the two clients fight each other for control. This fact has been communicated both in the XSquawkBox FAQ (see the entry titled "How do I use voice-over-IP with XSquawkBox") and in the most recent version of the AFV user guide (Revision 5, dated 27 March 2020). Native AFV support has been part of XSquawkBox 2.0 since it's first beta in November 2019. PTT and other controls for XSquawkBox are set up per the instructions in the XSB2 manual.
  8. Supporting X-Plane 9.x just isn't feasible anymore. XP9 is missing a handful of features that some of the client infrastructure is now dependent upon and supporting older versions of macOS and X-Plane is not an insignificant task - I really cannot justify the effort to work around those absences. Also, if you're capable of running X-Plane 9, you're not running the latest MacOS. X-Plane 9 does not and cannot work on macOS 10.15 due to the removal of 32-bit application support - I suspect you're actually running on an older version of macOS. Given X-Plane 10 came out in 2012, it may
  9. As much as I appreciate your enthusiasm, Ross and I have both discussed this whilst trying to work out why on earth the frequency hack is in there (it's been in all the old versions of XSB as well, so you honestly did not test this very well). VPilot and XPilot have selective behaviour in this area dependent on what the controller advertises whereas XSB consistently uses the truncated. Until such time as VATGOV5 presents a ruling, as far as I'm concerned, the standing guidance to use the truncated frequency stands otherwise then I risk breaking the client for territories who are stil
  10. It's still there, but you need to explicitly request it (.atis <CALLSIGN>). The automatic display of the ATIS was a direct side-effect of the old voice system - the voice room information was side-channeled with the ATIS, so we got both at once, and so we just displayed the text ATIS. In AFV, there is no hard requirement to perform that query anymore, so XSB2.x doesn't unless you explicitly ask for it using the .atis command.
  11. A more useful error message will be in the Log file (the hex number is due to a bug, but it's usually correctly recorded in the log just prior to that line being logged). That message is used when an unrecoverable error is encountered trying to establish a voice connection - there's generally only three common cases for this, and the odds are that one of these applies in your case: System (not simulator) clock is incorrectly set, resulting in the token expiry time we get from the AFV Instructure to be "in the past" relative to your system clock. Your system clock must be correctly
  12. XSB2.x is not XSB1.x - there were significant changes and the manual (now only on the website so it can be updated) covers how to get things going given the changes.
  13. Check your Log.txt - it'll tell you what and where each of the plugins it's loading are.
  14. When asking for help with the client, bug or not - please remember we are not mind readers and do not know what you're using or what you're even trying. There's an old standard with support which really helps when trying to provide somebody information to properly consider what advice you need - framed in the XSB context: What do you have? In the XSB context, generally your OS, X-Plane version and the XSB plugin version are a really good start. Always give these in accurate terms - not just "the latest" or "X-Plane 11", but the full version numbers - e.g: "XSB 2.1" or "X
  15. *sigh* Please take the hint - I'm telling you under what conditions I would expect what you're seeing to happen given my knowledge of it as the developer. Please show a little initiative and actually look into all of those possibilities and provide a clear, unambiguous response to show that you have genuinely considered those points, and maybe share the relevant information - otherwise there is naught that I can do for you.
×
×
  • Create New...