pilotjohn

Sounds good to me...

I think it's a good point, and now that I rethink my use, I would likely want to decrease granularity, but now quite to the day. I would probably use an hourly save, with a format like %Y%M%D%h%m, or maybe a 5-15 minute save. Those that won't read the manual won't know about the expansion capability anyway, and the feature will continue to provide the same facility as it has now. For those that don't care about the date, they can just use %A, but for those that want to be very granular, they have the option. I think it's better to have the capability, with a short warning message in the manual about potential misuse, than to force a date-only option. And while I would normally use the hourly option, I can imagine scenarios where I would want the level granularity that minutes and seconds would provide (for example retrying some decision that was wrong, that might have happened 5 minutes ago, like flying up a box canyon, but it's a scenario where I won't know when the bad decision will be made and when it can be corrected, so the granular archive is needed). Having a more granular definition for date/time, would also allow users to mimic Auto-Save naming schemes without using YYYY or MM. Perhaps %d %h%m%s, with %d being an expansion for the name of the day of the week. Lastly, it's pretty easy to trim the directory from excess files, even manually, if a misconfiguration occurs and many files are created. So while I whole heartedly agree with the concept of trying to save the user from him/herself, advanced users should be given the choice and option to kill their filesystem. Maybe there's a way to do both, with manually setting things in INI and limiting what can be "entered" in the text field in the GUI? But that seems like more work for you. :)

I'm not on board with Prepar3D either, just wondering out loud... I agree FSX without EZCA is sterile. :) I haven't done any development for FSX but read plenty. I've been wishing for a nice clean flight/landing judge add-on, so this and that might be the push needed for me to start up VC++.

I'm assuming you've tried by using SIMCONNECT_DATA_FACILITY_AIRPORT and then calculating the closest one yourself? And that's the facility that doesn't get you all the airports, or may not get you the closest one... I wonder if this is fixed in Prepar3D.

Odd... I also run UT2, but don't have the hang problem. I see a Previous Flight save pretty consistently, but on several occasions it failed to load, and once or twice crashed FSX in weather.dll. I guess which is all the more reason why the "also save flight as" option expansion is likely a better solution.

AC and real date/time only would be fine (I fly sim time mostly, and when the flight is loaded I'm back to sim time.) Real time will also allow me to pick the latest drop-off point. Thanks for considering it! If you're not using something like strftime() for the date/time stuff, and you think it's useful, then maybe sim. time could be available as well (e.g. Y2/M2/D2) but that's not necessary for what I envision. The only reason I thought location would be available is because I noticed that FSX keeps a pretty consistent log of my flight, including airports at which I've done only a touch-and-go, so I thought it might be some obvious thing it provides. If something's possible without too much fuss, great, if not, no worries. Thanks, again! John

Sorry, I likely edited the above post after you read it... So would adding a small variable expansion capability to "Also save to a Flight called" be too much work? In the end, after all this thinking, that's really all I would need to get the functionality I'm seeking, and then some. And I'm sure there would be other uses for it... Please?

1. For me, it would be enough to get a saved flight tagged with the plane, period. Stripping anything but numbers and letters, and trimming to some limit like 50, 64, or 100 characters should be good enough and work in most cases (for those cases where two names conflict, the user could always edit the aircraft title to fix the problem and get a title to their liking - life's a compromise). This would allow you to resume the flight from where you left the plane if you want, or just do whatever you normally do. No need to make things automatic. I start FSX, if I want to continue where I left my Scout, I just load the "Previous Flight ACAScoutTundra" or whatever the name of the plane would be. If I don't want to continue, I just set up the flight I want as I normally would. I may be wrong, but this seems like it would be rather trivial since it would require just another call to the flight saving code with a different file name. 2. Would it be possible to save flights any time a "new flight" is selected? That is, anytime a flight is ended, or before a new AC is selected, or a new scenery or world position is selected? This would allow for #1 above to be used in cases where you switch planes, sceneries, or just end a flight to start a new one, without having to exit FSX. 3. I understand the naming has been around for a while. Perhaps an option could be offered to use different format. Or, there could be a textfield that would allow the definition of the name using some simple markup, in the form of strftime() plus some FSUIPC built-ins like the AC title (the default markup would be the current format). This would provide two things: one, an near-automatic archiving capability without having to rename files after exiting FSX, and two, it could be used for #1/#2 above by making this the only change in FSUIPC. You could configure your auto-save options to save with something like "AutoSave $AC %Y%m%d%H%M%S" and to save on ground. Then your only requirement would be to wait long enough after shutdown for the auto-save interval to be triggered (e.g. arrive at airport, taxi to parking, shutdown, wait 1 minute). This would even provide a solution for having multiple plane locations for the same plane, since the you could pick the location for the given date. Does FSX provide the current airport? Perhaps that could be an expansion field as well, something like $LOC, if there's not airport then replace with something like "NOLOC" or "INFLIGHT". In order of "wants", they are in order of importance. But #3 would provide the functionality of #1 and #2 so that would be perfectly welcome as well, and might be the most efficient use of your time. I would be even willing to write the file naming expansion code for you to insert wherever. So there's more than one way to do this, and whichever would be easier for you, I'm all for it. But, the more I read over my choices above and think about their use, the more it seems that #3 would solve a lot of these. :) Or, perhaps even easier yet, the "Also save to a Flight called" option could be used for this feature. All it needs then is the macro/var expansion capability for date/time and AC/LOC or whatever might be possible; no GUI changes, just some extra code to strip/trim AC name, perhaps LOC if possible, substitute for $AC/$LOC or whatever, and then pass through strftime() and done. I get goosebumps just thinking about it: a history of pretty much all your flights, cataloged automatically by date/time and AC and/or LOC, that you can pick and reload (relive) at your leisure.

I am a big fan of the auto-save and previous flight save feature of FSUIPC. I have a question: When is the "previous flight" saved? When the flight is ended and/or FSX is exited? I don't see it in the manual. I also have some suggestions: The auto-save filenames should include YYYYMMDDHHmmSS so that they're easily located (e.g. last one) and to make it convenient for archiving. Lastly, I'd like to see a per-aircraft "previous flight" save option. This would allow me to resume a flight where I left off on a per plane basis. Wherever I left my Scout Tundra is where I can resume from. Or, wherever I left the Islander is where I can resume it form. So in addition to the above, there would be like a "Previous Flight - Scout Tundra Blue+White Whatever" saved file. Regards, John

Third time's the charm... It's fixed, it works! Thanks, John

I know how it is... I tested with the aileron axis, and that works correctly: Ailerons (SLOPE 4) ---> 1.jpg 475662 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 10649 (0x00002999) AXIS_AILERONS_SET Ailerons (SLOPE 0) ---> 2.jpg 837163 *** AXIS: Cntrl= 65763 (0x000100e3), Param= 12953 (0x00003299) AXIS_AILERONS_SET Brakes (Left SLOPE 0, Right SLOPE 4) ---> 3.jpg 685874 *** TOE BRAKE AXIS, Right set = 176 (IN=16192, OUT=12450) 685874 *** Both toe brakes over threshold: FS BRAKES control sent 685905 *** TOE BRAKE AXIS, Left set = 176 (IN=16192, OUT=12450) 685936 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET 685936 *** AXIS: Cntrl= 66388 (0x00010354), Param= 12451 (0x000030a3) AXIS_RIGHT_BRAKE_SET Notice how the ailerons output the same thing as the GUI, however the two brakes (one at SLOPE 0, the other at 4) log the same thing despite the GUI showing two different things.

I've also disabled filtering, just to be sure. So with a slope of 4 you are getting an OUT of 12450? I think that is the OUT value that should occur without a SLOPE.... If I remove the SLOPE I see that value (~12700) in OUT in the GUI and in the logs. But if I add in a SLOPE of 4, the GUI shows an OUT of ~9700 but the logs still show an out value of ~12700. So shouldn't the GUI and logs agree +/- a few hundred? Without a SLOPE they agree. With a SLOPE the GUI shows 9700+/- while the logs show 12700+/-. I'm mapping a range of 32768 (-16k to 16k) to a range of 36864 (-16k to 20k). So at an input of +16k (fully pressed brakes) the OUT should be about 12743 (or (32768 / 36864 * 32768) - 16384) without a SLOPE map, which appears correct. But depending o the SLOPE setting, since the IN of 16384 is not the MAX value, the OUT should be less and less with higher an higher slopes. Am I correct? This appears to happen in the GUI, but not the logs. I'll verify one more time to be sure, and I'll try to reproduce with another axes where the SLOPE appears to work correctly.

Hmm... I'm still getting the same behavior with 4.709a. GUI OUT shows 9744, but log param shows 12451, and wheels lock. If I remove SLOPE and change MAX to 24576, OUT/param show 9500 as expected and no wheel lock.

I think most just don't care enough... but don't feel bad. It's like this for me with everything: if I touch it, I'll inevitably find something that's been broken/missing/wrong that no one noticed before. :) Thanks for the great support BTW!

Thanks I'll test... so the reason for the artificial maximum is because the pressure required to press the brakes on Saitek is very low and linear and thus braking always goes to the stops. It's hard to not go to the stops and stay coordinated with both brakes (there's no feel of pressure). Going to the stops always locks brakes in FSX. Going to stops and locked brakes are completely unrealistic, and seem to provide unrealistic stopping distances (I'm an RW pilot as well a sim hobbyist). I noticed that going to 80% max provides no locked wheels and a more realistic feel. The reason for the slope is that because the "throw" of the Saitek brake is so short, I wanted finer control over individual brakes in the beginning of the movement, which also is more natural (the initial movement provides a lot less stopping power, then the final "to the stops" effort; while the level of effort required to push is not simulated by Saitek, the slope adjusts the result of the axes movement.)

Brakes axes are assigned in FS, not direct control by FSUIPC... Here are the settings: LeftBrake=-16193,20480/8 RightBrake=-16193,20480/8 SlopeLeftBrake=4 SlopeRightBrake=4 When the brakes on my Saitek rudder are fully depressed, the GUI shows the attached screenshots, and the log shows: ********* FSUIPC4, Version 4.709 by Pete Dowson ********* User Name=... User Addr=... FSUIPC4 Key is provided WIDEFS7 not user registered, or expired [Continuation log requested by user] Running inside FSX on Windows 7 (using SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed 318383 System time = 21/06/2011 14:28:41, Simulator time = 08:30:45 (15:30Z) 318383 LogOptions changed, now 10000000 00000001 320629 *** AXIS: Cntrl= 66388 (0x00010354), Param= -12637 (0xffffcea3) AXIS_RIGHT_BRAKE_SET 320629 *** TOE BRAKE AXIS, Right set = 10 320660 *** AXIS: Cntrl= 66388 (0x00010354), Param= -14745 (0xffffc667) AXIS_RIGHT_BRAKE_SET 320660 *** AXIS: Cntrl= 66387 (0x00010353), Param= -14923 (0xffffc5b5) AXIS_LEFT_BRAKE_SET 320660 *** TOE BRAKE AXIS, Left set = 4 320660 *** TOE BRAKE AXIS, Right set = 23 320692 *** TOE BRAKE AXIS, Left set = 20 320692 *** TOE BRAKE AXIS, Right set = 45 320723 *** AXIS: Cntrl= 66387 (0x00010353), Param= -13107 (0xffffcccd) AXIS_LEFT_BRAKE_SET 320723 *** AXIS: Cntrl= 66388 (0x00010354), Param= -9011 (0xffffdccd) AXIS_RIGHT_BRAKE_SET 320723 *** TOE BRAKE AXIS, Left set = 48 320723 *** TOE BRAKE AXIS, Right set = 81 320754 *** TOE BRAKE AXIS, Left set = 86 320754 *** TOE BRAKE AXIS, Right set = 155 320785 *** AXIS: Cntrl= 66387 (0x00010353), Param= -2294 (0xfffff70a) AXIS_LEFT_BRAKE_SET 320785 *** AXIS: Cntrl= 66388 (0x00010354), Param= 9010 (0x00002332) AXIS_RIGHT_BRAKE_SET 320801 *** TOE BRAKE AXIS, Left set = 155 320801 *** Both toe brakes over threshold: FS BRAKES control sent 320801 *** TOE BRAKE AXIS, Right set = 176 320832 *** TOE BRAKE AXIS, Left set = 176 320863 *** AXIS: Cntrl= 66387 (0x00010353), Param= 12451 (0x000030a3) AXIS_LEFT_BRAKE_SET 320863 *** AXIS: Cntrl= 66388 (0x00010354), Param= 12451 (0x000030a3) AXIS_RIGHT_BRAKE_SET

Just tested... reads 4.709 in GUI, shows correct value in GUI (9744 OUT for 16384 IN with 20480 MAX and 4 SLOPE) but it's still sending the unsloped value according to the logs (param = 12136).

Thanks...!

It's 4.703. But, I just installed 4.708 and it has the same behavior. I figured out the center settings... one other question, what are the /8 or /40 after the calibration settings?

No, it's not the coincident point. So I have MIN at -16384, MAX at 21502, SLOPE at 15. At these settings, an IN value at 16384 (fully depressed brakes) provide an OUT value of about 5100 according to the GUI. However, the logs show that it's sending a param value of around 11700, which would be the OUT value if the SLOPE were 0. It seems like the GUI is showing the correct value (5100) but the incorrect value (no slope) is being sent to FS. Is there any other way to verify this? 1. I set MIN/MAX/SLOPE as above. I fully depress the brakes, and see an OUT of around 5100 in the GUI. 2. I return to FSX, fully depress the brakes, switch to the modules directory open FSUIPC.log and see the last two lines showing around 11700 as params being sent. 3. I return to FSUIPC, set brakes SLOPE to 0, full depress brakes, and see an OUT of around 11700. So during condition 1/2, the GUI is showing 5100 OUT but the logs are showing 11700 being sent. I'm not sure if this is a bug, or if I'm missing something somewhere... And on this separate note, is there a way to change this "null" central zone?

I can see how a joystick input of 16384 with FSUIPC MAX set at say 24576, the OUT value without a slope would be different than an OUT value with a slope, since now the IN value looks like an intermediate point and not MIN or MAX. So, this, I think is correct. For example with MAX set at 21502, an IN of 16384 outputs about 11700 without a slope, and 5100 with a slope of 15. Well, it seems FSX's brake locking (or at least brake locking animation) is rather crude. It has no relation to ground speed or rate of application. Whether I apply at just before Vr, or at a slow taxi speed, and whether I apply fast or slow, the brakes lock at the same time. So I am puzzled why the slope is not having an affect. Well this is interesting... it doesn't seem like the SLOPE has an affect on the OUT according to the logs. So I have the MAX set to 21502 which results in a linear OUT of about 11700 at full press, and locked brakes. Regardless of what I set the slope to I get locked brakes. At a SLOPE of 15, the full press OUT that is shown is around 5100 but I still experience locked brakes. I turned logging on, I press the brakes fully to lock, and the last thing I see in the log file are these two lines (slope of 15 while the UI shows out of 5100): 1065518 *** AXIS: Cntrl= 66387 (0x00010353), Param= 11631 (0x00002d6f) AXIS_LEFT_BRAKE_SET 1065518 *** AXIS: Cntrl= 66388 (0x00010354), Param= 11631 (0x00002d6f) AXIS_RIGHT_BRAKE_SET When I release the brakes, I get: 719539 *** AXIS: Cntrl= 66388 (0x00010354), Param= -16384 (0xffffc000) AXIS_RIGHT_BRAKE_SET 719602 *** AXIS: Cntrl= 66387 (0x00010353), Param= -16384 (0xffffc000) AXIS_LEFT_BRAKE_SET On a separate unrelated question, what does the "512" or other number represent below the center set value to the left of the slope button in other axes?

I've calibrated my brakes to provide only 80% effort at full "press" to avoid wheel lockups. I did this by tweaking the INI file to include a larger MAX for the axes than what the joystick (Saitek Rudders) actually provides. This works as expected with a linear slope (MIN=-16384 MAX=24576): -16384 IN provides -16384 OUT, 16384 IN provides about 9800 OUT. If I change the slope, it obviously changes the OUT value at full press. So what I did was to empirically recalculate the MAX to still get an OUT value of 9800 or less. With a slope of 4 and a MAX of 22528, 16384 IN provides about 8100 OUT. However, this OUT value locks up the brakes. So the question is, what does OUT represent? Is OUT the axes "value" that is sent to FSX or something else? How can I determine what is being sent to FSX by FSUIPC? If an OUT value of 9800 with a linear slope does not lock the brakes, shouldn't an OUT value of 9800 or less also not lock the brakes with a different slope? I'd like to calculate exactly what MAX should be with a slope of 4, to get 80% effort sent o FSX when the axes is fully "pressed". When this was linear, it was easy. With a slope, I assumed I could do it empirically, but the OUT value doesn't seem to represent what I thought it did, and since I'm not sure what the formula is for the slope, it's hard to calculate exactly the MAX value for 80% effort. Can you shed some light on this?

Got it... I'll try that. Thanks! Perhaps this could be a new feature in the GUI in the future.

It does for me... apparently that's it for this aircraft then. If I have FSUIPC calibrate (aircraft specific) the axis with RZ, at a raw input of -16384 FSUIPC shows -4096 as output, which in effect causes the CL to go to fuel cutoff. Start & Feather is greater than -3850 from what I can tell from documentation, and around -3000 seems to work. Ideally I'd like to have -3000 at the controller's -16384 (idle) position, and scale up from there. That is scale the raw input of -16384..16384 to -3000..16384. Would this be in the specific aircraft area of FSUIPC.ini? I see the specific aircraft settings, but not the -4096. If I set this in the INI, won't it be overridden my FSX in some way? NRZ/RZ basically scale the raw min/max to 0/max or -4096/max (or as read from FSX?), correct? What I'd like to be able to do is scale to something else besides 0 or -4096 in this case. Below are the FSUIPC sections (prop pitch 1+2 is mapped directly to 3+4 calibration for this aircraft, on axes 0V/2X): [Axes.MJC 8-300 Q British Airways] 0=0Z,256,D,11,0,0,0 1=0U,256,D,12,0,0,0 2=0V,256,D,19,0,0,0 3=2X,256,D,20,0,0,0 4=2Y,1 5=2Y,B,-16384,-8322,65925,-3000 6=2Y,BR,-8062,8064,65925,-3000 7=2Y,B,8320,16383,65925,-3000 8=2Z,1 9=2Z,B,-16384,-8322,65926,-3000 10=2Z,BR,-8062,8064,65926,-3000 11=2Z,B,8320,16383,65926,-3000 [JoystickCalibration.MJC 8-300 Q British Airways] AllowSuppressForPFCquad=Yes ExcludeThrottleSet=Yes ExcludeMixtureSet=Yes ExcludePropPitchSet=Yes SepRevsJetsOnly=No ApplyHeloTrim=No UseAxisControlsForNRZ=No FlapsSetControl=0 FlapDetents=No ReverserControl=66292 Reverser1Control=66422 Reverser2Control=66425 Reverser3Control=66428 Reverser4Control=66431 MaxThrottleForReverser=256 AileronTrimControl=66731 RudderTrimControl=66732 CowlFlaps1Control=66162 CowlFlaps2Control=66163 CowlFlaps3Control=66164 CowlFlaps4Control=66165 SteeringTillerControl=0 MaxSteerSpeed=60 PropPitch3=-16384,0,512,16380/8 PropPitch4=-16384,0,512,16380 Throttle3=-16380,-512,512,16380/32 Throttle4=-16380,-512,512,16380/32

I'm trying to setup my Saitek quadrant's prop control to feather the condition levers on the Majestic Q300 at the idle position. However, FSUIPC outputs -4096 as the minimum which causes the CLs to move to the Fuel Cutoff position. I'd like to limit this minimum so that at the controller's idle position the output is greater than -4096 and the CLs stop at the Start & Feather position to avoid accidental fuels shutoff. I can do similar things for the throttle since the Q300 allows this mapping, but not for the prop. How can this be achieved? I will then use the mixture axes to move the CLs to Fuel Cutoff (I have this part working already with sending FS commands in ranges).