Is there any way to block or somehow ignore the joystick’s elevator signal?A custom autopilot would need a way to deal with this....no?If the joystick isn’t centered (resting in the null zone) it will update the elevator position each cycle - along with the autopilot gauge.They fight it out so to speak until the stick is returned to the null zone.Any ideas how to approach this?Or any experience with add-ons you’ve tried where the stick position could disrupt the autopilot?Danny

Hi DannyI know this has been sitting around for a while and I'm not sure I have the right answer (C-code only!) but if you are using C, have you tried trapping the joystick using an Event Handler? I've successfully trapped the throttle this way.-Dai

Hi DannyI know this has been sitting around for a while and I'm not sure I have the right answer (C-code only!) but if you are using C, have you tried trapping the joystick using an Event Handler? I've successfully trapped the throttle this way.-Dai

Hello Dai,I used the event handler many times, very useful, but it doesn't trap the events. It allows you to detect an event but does not block it, which means it is also handled by FS afterwards. If you found a way to really trap the events so that they are not "seen" by FS, I am interested in knowing how you did this :)Eric

Hi Dai and Eric,Actually I’ve prototype the AP controller in XML.I don’t know C yet.But I’ve been working towards learning it…I’ve read your excellent doc BTW :)So my plan has been to migrate it to C eventually.Yeah, what I wonder is, if it’s indeed possible for a C gauge to block the flightstick axes.Actually-ideally I’d like to block just one, the y-axis (pitch) and transmit the x-axis (bank).A possible solution to start would be a small single function C gauge.Couldn’t it monitor a local var – set by my XML UI? L:Var == true – block the Y-axis. L:Var == false – transmit the Y-axis.DannyEdit...BTW...currently, as long as the joystick is in the null zone the AP has full authority…and works well.But if there are no null zones set there are problems.Right now I don’t have any add-ons installed to compare with.As I remember, PIC 767 required pitch and bank null zones.But, I don’t remember if Level-D and PMDG require them these days.So they may have a working solution.

Hi Eric/Danny

Hello Dai,I used the event handler many times, very useful, but it doesn't trap the events. It allows you to detect an event but does not block it, which means it is also handled by FS afterwards. If you found a way to really trap the events so that they are not "seen" by FS, I am interested in knowing how you did this :)

Bad wording on my part. What I did was to capture the event and then override it by putting the same event on the queue but containing the information I wanted FS to see. So, suppose I had a failed throttle system; I use the Event Handler to check for throttle input and as soon as I see it, I set the input to (e.g.) zero. In theory you can get an event race doing this but it hasn't happened to me (yet?).

Yeah, what I wonder is, if it’s indeed possible for a C gauge to block the flightstick axes.Actually-ideally I’d like to block just one, the y-axis (pitch) and transmit the x-axis (bank).A possible solution to start would be a small single function C gauge.Couldn’t it monitor a local var – set by my XML UI? L:Var == true – block the Y-axis. L:Var == false – transmit the Y-axis.

See above - it should be possible by using the (un)register_var functions in the gauges.h file.-Dai

Okay I think I understand. It’s not a matter of blocking the signal, but rather when there is a joystick signal you replace it with your own.Sounds like a great solution :) So I'm really encouraged.Are you always able to insert your command before FSX receives the signal?Or is it kind of hit and miss?

Hey guys, interesting and exciting topic to dicuss.

Are you always able to insert your command before FSX receives the signal?Or is it kind of hit and miss?

I believe you cannot "inject" your own command before FSX will get it. I think the flow works like this: You move the axis, say the throttle. FS will set the throttle accordingly, and also a KEY_EVENT is fired. I am pretty sure the gauge gets to know about the KEY_EVENT only after all of this has already happened, then you can reset the throttle to whatever value you want it to be at. The downside is the jumping in controls that can be observed every now and then. More a hack than a solution, but does the job in many cases.Dai, please correct me if I am wrong or if you meant something different, maybe I have missed something too. Oh, and I am also more than interested in a solution that intercepts and blocks signals... Isn't SimConnect able to do so? But there's gotta be a simpler way I hope.RegardsEtienne

You're right. Take this as an example - overriding the requested flap positions in the case of a hydraulic failure. This is catching the keyboard rather than a joystick but the principle is the same.

//***************************************************************************void FSAPI EventHandler (ID32 event, UINT32 evdata, PVOID userdata){//Pass the event through if needed	Hydraulics(event);//----snip----////***************************************************************************//Hydraulic failure - effects on flight controls and brakes - pressure/100//***************************************************************************void Hydraulics(ID32 event){//Auto-deployment of spoilers with weight-on-wheels	if(hydpress_c_sys<150)gndsplrs_gear=0;//Trap flaps in the current position if hydraulic failure.	if((fail_hydsys_a && fail_hydsys_c) || (hydpress_a_sys<150 && hydpress_c_sys<150) && (event==KEY_FLAPS_INCR || event==KEY_FLAPS_DECR))		trigger_key_event(KEY_FLAPS_SET,(int)getLeftFlaps;//--etc.

'getLeftFlaps' is simply a wrapper for

double getLeftFlaps(){  double data=0;  execute_calculator_code("(A:TRAILING EDGE FLAPS LEFT ANGLE,radians)",&data,NULL,NULL);  return RAD_TO_DEG(data);}

There is quite probably is a better way to do it using SimConnect but I haven't really looked at SimConnect.-Dai

There is quite probably is a better way to do it using SimConnect but I haven't really looked at SimConnect.

I haven't tried this out specifically, but under SimConnect_AddClientEventToNotificationGroup I have found the following details for the bMaskable parameter:"Boolean, True indicates that the event will be masked by this client and will not be transmitted to any more clients, possibly including Flight Simulator itself (if the priority of the client exceeds that of Flight Simulator)."Edit:Similar goes for the bMaskable parameter of the SimConnect_MapInputEventToClientEvent function:"If set to true, specifies that the client will mask the event, and no other lower priority clients will receive it."Not sure if this leads into the right direction, gotta admit I have fiddled around with SC quite a little bit but haven't grasped all that "group" stuff altogether so far... :rolleyes:RegardsEtienne

DirectX (DirectInput) provides a means for handling joysticks. The following link gives some C++ code:http://www.cs.cmu.ed...rectx/joystick/there is a tutorial here:http://www.yaldex.co...09lev1sec2.htmland full reference here:http://msdn.microsof...853(VS.85).aspxIt might be possible to achieve what is required by setting the ranges of the relevant axis (axes) to +0, or by setting a large deadband when the autopilot is connected. It would be necessary to save the original values of range and deadband and restore them when the autopilot is disconnected.Obviously, it assumes that Flight Simulator uses DirectInput to handle joysticks!Just a thought which I haven't tried.