Bugs affecting X-Plane camera and A-Better-Camera plugin

[slgoldberg]

Hi, folks,

First of all, I just wanted to say I think this is an amazingly well-built aircraft with what's very clearly a well thought-out, well-documented collection of plugin functionality as well as commands and datarefs. Well done.

However, as the author of A-Better-Camera (ABC, free general-purpose X-Plane plugin for managing the exterior camera), I am having some user reports of compatibility issues, that I'm hoping you'll agree are just bugs, and that can be readily corrected for your next update:

(1) Overtaking "sim/general" commands (such as sim/general/{up,down,left,right}, and related):

It appears for whatever reason, your systems.xpl plugin is listening on XPLM commands that are normally used for camera control (up, down, left, right, as well as rotating left/right, and hat-switch commands of the same nature).

While it's totally fine to do that (I do it, too), you are unfortunately overstepping your bounds in using it even when you're not properly in control of the camera, such as when X-Plane or ABC is controlling the exterior camera.

What that means is, you're changing the meaning of ABC's and X-Plane's exterior camera-control keys, and while you seem to be attempting to correctly "wrap" the commands and map them to similar alternatives, you're not doing so in a way that works correctly when another camera is also controlling these commands.

So, for example, about 10% of the time, it appears X-Plane never receives the "end" phase of a given command, such as "move up slow".  So it'll end up "moving up slow" indefinitely, until someone goes into DRT for example, and hits the "end" phase of the move up slow command.  That's kind of a horrible user experience.

I am not sure what your intention is, but if you are only trying to take over the "sim/general" commands for the interior (cockpit) camera, then I would beg you to please add code to your handlers for all these commands to completely ignore them (by returning 1 instead of 0) from your command handler, for each phase of each command you listen to -- when the camera is not in the cockpit.  Even then, it's kind of weird that you're modifying those commands, I'm not sure what you're doing. But at least if you didn't do it outside the cockpit, it wouldn't have as much chance of colliding with the same command handlers built into X-Plane's camera and into plugins like ABC's.

(Note: I'm not positive this is the actual issue; I'm just guessing right now. But I am happy to discuss to figure out what could be causing the runaway camera control behavior with your systems.xpl plugin.)

Another thing you should know, if you are trying to use the XPLMCamera API to do something with the exterior camera, there's a known bug in X-Plane that currently incorrectly fails to call your camera control callback with "inIsLosingControl" set to 1 to indicate that another camera has taken over.  So, if you are trying to use that to be signaled when another camera has taken control (for collaborative camera control with other plugins), please let me know and I'll tell you a good way to work around this bug so you can be sure whether camera control is owned by you or by another plugin such as ABC. (Thanks.)

---

(2) TCAS aircraft position updates:

There appears to be something happening (and I have no idea what, so far) with either your bundled X-TCAS plugin, or with your main plugin somehow causing the position updates to be periodically lost (or otherwise altered) for synthetic traffic plugins that are providing aircraft via TCAS.  So for example, LiveTraffic and Traffic Global aircraft that are integrated using TCAS override (in XP11.50+) appear to frequently "flicker" (aka "jitter") when viewed through X-Plane's built-in camera, or when viewed by a plugin such as ABC's camera.

This doesn't happen when the same plugins are using TCAS override and updating their aircraft positions without the TBM 900 plugins running.  So it's definitely something happening that's caused by TBM 900's plugin(s).  ABC can also show the non-TCAS version of most traffic's positions, instead of using the TCAS position data, talking directly to the plugins' own APIs -- those never have the flicker/jitter problem, even when TBM 900 is running.  So it's specific to TCAS, and likely something that's happening in your plugin(s) that is deferring the update cycle so that periodically TCAS updates aren't properly applied. I'm not sure exactly what I'm saying, I just know it's something like this. :-)

Thanks heaps.

  Steve