zip

Hi Pete, thanks so much for your response. I'm just happy this wasn't so far out in left field... Etienne

Hello Pete, me again with another feature idea following my earlier suggestion for a curved response on throttle axes :) Would it be possible to enhance the calibration of the various axes to make them type specific? Thinking along the lines of calibration profiles, the idea would be to select response curves and calibration "sweet spots" specific to particular configurations: Example: - Turbo-prop calibration without reversers - Turbo-prop calibration with reversers - Jets with reversers - Regularly aspirated piston I find myself constantly "tweaking" calibration and curves in response to the way various add-ons behave based on the class of each aircraft. Best regards, Etienne Martin

Hi Pete, Thanks for your reply. Upon further thought, it came to me that an off-center "S" curve (as coded for a centered axis) may very well work for a throttle to smoothly transfer from reverse to idle to max provided the center of the "S" can be offset (in this case, the low range). This would allow for smooth transitions between idle and either reverse/normal thrust and probably help with the deadband as well. Sincerely, Etienne Martin

Hello Pete, I had a question that stems from my recent foray into a certain ATR 72 that can be very hard to control on the ground when using mapped throttles. At issue are goobles of power that transforms the aircraft, and only this particular ATR, into a rocket on the ground by barely nudging the throttle (half a mm). The response with any other a/c, including other turboprops such as the 1900D have no such issue. You have a very nice curve response on the aileron/elevator axes, but there is no such thing I have found to affect the response of engine throttles (single or separate). What I'm looking for, and what I may have missed, is a method to adjust the curve of throttles so it is more sensitive in the low range (to allow for less response, more throttle movement, in the idle range) and then moves to a more linear mode. A sort of J curve. Is that in existence, or in the works? Cheers, Etienne Martin

So you know, I had major problems with the CH Throttle Quadrant when I hooked it up to FS. All the axis sensitivity settings were completely off the mark using FS "defaults". I had to manually reset all the sensitivity settings for the CH THQ, clean it up through FSUIPC's joystick calibration page, reverse the spoiler axis, and voila, perfect range including reversers. The moment I change something in the joysticks order or configuration, my sensitivity assignments in FS get completely messed up, causing range or centering problems. Hope this helps.

This was just an idea you gave me when you talked about subclassing. One of the reasons to subclass is to filter or trap events and preventing them from being forwarded. This is a standard way to filter messages in Windows that we don't want to propagate. For example, in the situation above with the GPS/NAV circuit, it would be nice to be able to trap the GPS/NAV mode toggle request sent by FSNav to FSUIPC (assumption: FSNav uses FSUIPC) and preventing it from occuring via a filter. Of course, there may be a way to do just this as Eric Marciano just found out how to use the register_key_event() handler without having FS crash. This is similar to your new offset to prevent flap or gear movement, but would apply to non-continuous event types (such as circuits on/off). Makes sense?

Thanks for the answer, I'm going to experiment some more. Speaking of subclassing, there is no listener "event" callback from FSUIPC is there (this to trap FSUIPC writes)?

Hello Pete, An issue rages on with the Captain Sim 707 and FSNavigator, in that to use an external heading source, the 707 (Version 1.1), requires GPS Navigation mode to be on, and FSNavigator in a classic turn of Murphy's Law, turns GPS mode off (and forces it off) the moment you engage the "set heading and hold course" mode. This inherent conflict had me make my GPS/NAV switch on atngau 1.3.6 sticky, in that it checks to see if the mode is off, and turns it back on if it's supposed to be on (undoing FSNav's logic). This on/off cycle is interesting, inefficient and a poor man's way of fixing a couple of wrongs, so two questions while we wait for this problem to be addressed: 1) is FSUIPC's offset 0x132C faster than a send key event in FS? 2) any better ideas on possibly preempting the GPS/NAV off call so this becomes entirely unecessary? Cheers, Etienne

Well, I'm using FSUIPC 3.30 and the release candidate of AS2004MR2 and have no problems as you mention here (aside from a losing my mouse every so often, which is why I have two now on different USB ports, but that is not related to either FSUIPC nor AS2004 :shock: ) Sounds like a previous problem I had with ATI catalyst drivers. Other than that, I'm at a loss.

Yes, of course. And no, I didn't use strlen (in my quest to save CPU cycles). I used a hard coded value, and I always preach never to use hard coded values, and got bitten by it once more, to prove my theory: expect the unexpected. So, I have a HUGE comment to this effect. I did add a double zero (\0) at the end for good measure and making sure it's a single byte string as well. It's a classic bug caused by classic inattention.

Pete, you have, once again, my gratitude for providing me with a fix to my oversensitive rudder (via the new slope buttons)! I have a Saitek HOTAS and the CH Products rudders/yoke, and when I enable one, I usually clobber the other and come up with a completely messed up control system. This latest version provided exactly what was needed, and my CH rudders are now tame without using the CH control program. So thanks for continuously improving this wonderful tool.

Ok, I will force a 0 there (the compiler should normally place one there but it may not be written). Thanks.

Hello! A couple of people who have downloaded my freeware gauge on AVSIM had problems with my automatic registration via offset 0x8001. Both users were using FSUIPC unregistered, version 3.22, running on XP. A manual registration worked for them. The automatic registration was tested on several machines without the registered copy of FSUIPC, and was found to work correctly. The problem doesn't appear to be widespread (less than 1%). Is it a good idea to go ahead and automatically modify the fsuipc.key file instead? Thanks for any suggestions.

Dynamic forces - I should explain. The idea is to be able to apply acceleration and/or change the position of the a/c to mimic things like buffeting - hence dynamic forces as I call them. A misnomer probably. Thank you so much for your prompt answer. Regards,

Hi, I'm looking at implementing a simple slew type function without using slew mode. I'm interested in the ability to set a/c position and orientation from code. Is this possible, and if so, what is the recommendation for the offsets? Thanks !