jordanal

Pete, I would like to refer you to a discussion and my analysis over in the AVSIM Radar Contact forum - regarding the new FSUIPC functionality of getting RC to use ASE weather - it takes too long to parse and is causing RC voice response delays in the critical approach and landing phases of the flight. A moment of your time reading the analysis would be greatly apprciated. Happy Holidays to you and yours... http://forum.avsim.net/topic/321640-leave-freq-for-wx/page__view__findpost__p__1897432

Yes, I'm sure. You have to edit the FSUIPC.ini file by hand. I had it setup this way for a long time but after I bought the TrackIR5 and started to rely on VC interaction, I dropped back to one level (Model 1) of hardware buttons. Life is sooo much simpler now. :cool:

You don't want to program the hard-AP disconnect (bar). What you're looking for (IIRC), is the soft-AP disconnect which you program via a key-combination in the Level-D keys menu. Then assign that same key-stroke in FSUIPC for the red button. Make sure the key-stroke is not already used in the FSX key assignemnts or elsewhere. The same holds true the soft-AT disconnect for your left forefinger button on the yoke. The PMDG aircraft work the same way.

Hi Pete, I'm just curious to know if you've made and headway regarding the seound device selection within the Windows Vista/7 OS?

FWIW, if you install the Saitek drivers (not SST software) for the yoke and throttle, it will enalbe both the model wheel (right index finger) and the clock/timer on the front of the yoke. With the model wheel enabled by the driver, you can tripple the number of buttons on the yoke and throttle.

Some very good thought above to try guys. I appreciate the replies! Regards,

Hi Pete, it's been a while since I've had the need to pop-in here - I hope you and yours are well. :) A theoretical question if you have a moment. I have FSXsp2 and the latest FSUIPC4-interim with a Saitek Yoke and ThrottleQuads. As you probably already know, the Saitek THQ is a bit different in that, below the hardware idle-detent, it is basicaly a hardware button. As you can see below, for quite some time I've had each throttle-lever button send a repeate reverse-thrust command, which quickly just ramps up reverse-thrust to 100% (unrealisticaly). [JoystickCalibration] Throttle1=-16384,-16384,-16384,16383/32 [Axes.PMDG MD-11] 1=YU,256,F,66420,0,0,0 20=; ******** THRTL LEVERS ********** 21=RY,21,C65966,0 ; THROTTLE1_DECR 22=UY,21,C65967,0 ; THROTTLE1_CUT What I'm now contemplating, I want each throttle-lever button to cause a axis reversal so that after pushing the button, my throttle lever is now reversed; and as I now push the throttle lever forward above the idle-detent, it will be increasing reverse-thrust. Then, if I push the button again (by bringing the throttle-lever below the idle detent) it would once again reverse the throttle axis back to its normal direction; whereby any travel above the idle-detent is normal increasing thrust. I basically want to use a push-button to reverse my throttle axis each time it is pushed (causing the full axis to alternate between normal and reverse thrust). I know I could calibrate some arbitrary percentage of the axis to forward and reverse thrust using a fake idle-spot, but I have always had the hardware idle-detent equal 0% output (I just couldn't stand it any other way). :wink: Is this something that might be even remotely possible now, or perhaps someday in the future? Thanks and regards,

Oh Dang, I read that as Mike1=, Mike2=..., Mike3= was the only line/feature not compatible with Vista or 7. I really hope you figure out a way to make it work for 7 too someday. Thanks again for all you do Pete. Regards,

Hi Pete, It's been a while since I've had the need to post here so I hope you and yours are well. I just grabbed your latest WideClient interim version 6.7.9.1 and I'm really juiced over the new "Audio Output" selection feature associated with the run commands. I have been routinely switching default audio devices by hand for years to get Radar Contact to play on my USB Headset while the other Wideclient apps continue to use my Creative sound card. From what I understand, now I can get widelient to do this for me. Just one problem, I can't seem to make it work. On my Windows 7 x64 Ultimate wideclient, I have the following entries in my wideclient.ini file. I only want Radar Contact (Run1) to use the Headset, and leave the other three apps to continue to use the Windows default audio device (Creative SB X-Fi) card. I tried both "Wave1=Plantronics Headset" and "Voice1=Plantronics Headset" to no avail. I also tried "Wave1=Headset Earphone" which didn't work either. Radar Contact continues to use the Creative card (through my speakers) after it is succesfully started by Wideclient. As I have done for years, if I change the Windows default Audio device to the Headset before starting Radar Contact, it then succesfully uses the USB headset. Did I miss something obvious :?: In my Windows Device Manger, I have two entries under "Sound, Video, and Game Controllers": Creative SB X-Fi Plantronics Headset In my Windows Control Panel Sound Applet, I have two entries: Speakers Creative SB X-Fi Default Device Headset Earphone Plantronics Headset Ready ; PLEASE SEE WideFS documentation for parameter details ; ===================================================== [Config] Port=8002 Window=32000,32000,160,38 Visible=Yes ButtonScanInterval=20 ClassInstance=0 NetworkTiming=5,1 MailslotTiming=2000,1000 PollInterval=2000 Port2=9002 ResponseTime=18 ApplicationDelay=0 TCPcoalesce=No WaitForNewData=500 MaxSendQ=100 OnMaxSendQ=Log NewSendScanTime=50 Priority=3,1,2 ; ----------------------------------------------- [User] Log=Errors+ Run1=C:\Program Files (x86)\rcv4x\rcv4.exe Wave1=Plantronics Headset Delay1=5 Run2=C:\Program Files (x86)\TOPCAT\TOPCAT.exe Delay2=5 Run3=C:\Program Files (x86)\FS Flight Keeper\FSFK.exe /DBG Delay3=7 Run4=C:\Program Files (x86)\HiFi\ASA\ASA_Exec.exe ; ===============================================

Thanks Pete, yes indeed, I was moving USB devices around to different ports the other day in an effort to de-conflict an issue between my mouse and my TrackIR5 software. Thanks for the up-check on my tentative edits. I'm at work and the proper syntax was nagging at me, so I thought I would get the straight scoop from you before I get home to apply the changes. Thanks again and regards,

Hi Pete, I had my USB devices move again on me last night and today I figured that I better get my brain wrapped around the 'JoyNames' section of the User Guide. I have re-read the section several times and I'm still not sure of something. So would the following be a true edit of my existing ini file? I currently have something like this: [Axes] 0=0X,256,F,66387,0,0,0 1=0Y,256,F,66388,0,0,0 2=0Z,256,F,65764,0,0,0 3=1X,256,F,66424,0,0,0 4=1Y,256,F,66422,0,0,0 5=1Z,256,F,66425,0,0,0 6=2X,256,F,65763,0,0,0 7=2Y,256,F,65762,0,0,0 8=2Z,256,F,66420,0,0,0 9=2U,256,F,66423,0,0,0 10=2V,256,F,66421,0,0,0 [JoyNames] AutoAssignLetters=No 0=CH PRO PEDALS USB 1=Saitek Pro Flight Throttle Quadrant 2=Saitek Pro Flight Yoke Would I then add the alphabetic Reference to both the JoyNames section and the axis assignment like this? [Axes] 0=RX,256,F,66387,0,0,0 1=RY,256,F,66388,0,0,0 2=RZ,256,F,65764,0,0,0 3=TX,256,F,66424,0,0,0 4=TY,256,F,66422,0,0,0 5=TZ,256,F,66425,0,0,0 6=YX,256,F,65763,0,0,0 7=YY,256,F,65762,0,0,0 8=YZ,256,F,66420,0,0,0 9=YU,256,F,66423,0,0,0 10=YV,256,F,66421,0,0,0 [JoyNames] AutoAssignLetters=No 0=CH PRO PEDALS USB 1=Saitek Pro Flight Throttle Quadrant 2=Saitek Pro Flight Yoke R=CH PRO PEDALS USB T=Saitek Pro Flight Throttle Quadrant Y=Saitek Pro Flight Yoke Thanks for helping me get it straight in my head...

Well, that's plain wrong. Why would you want the rudder reversed compared to the way it is in a real aircraft? Wait a minute, are you saying that if I push the right rudder pedal forward (away from me) on a real aircraft, it is supposed to steer/yaw the nose the right as viewed from within the cockpit? After all these years of flightsiming I still wouldn't know because I've never operated a real aircraft to any extent. Regards, Al

Hi again Pete; I wanted to bring your attention to a little something I noticed the other day before you release your next final version of FSUIPC4. For the longest time, on both FSUIPC3/FS9 and FSUIPC4/FSXsp2, I have used the "Rev" checkbox to get my rudder on many different aircraft to agree with the physical actions on my CH Pedals. Using the reverse checkbox in FSUIPC calibration, it allows me to push my right foot forward (away from me) on the pedals and the steering on a given aircraft turns left as well as the rudder vane. Same thing in reverse, left foot foward (away from me) steers/yaws the plane to the right. The FSUIPC rev checkbox makes this work fine and dandy. No axis assigned in the FSX controls either. Then how come the rudder pedals as viewed from within any Virtual Cockpit don't move in the same direction when using this reverse checkbox? With the above description being true, I move my right foot forward for example, the right rudder pedal in a VC moves closer to me, not away. Is it just a VC graphics thing that the "rev" checkbox does not act upon? Just one of those silly things that made me go, huh? Best regards, Al

Thanks Pete, changing the share to a more specific path does indeed solve the issue. I changed the share from the entire drive (D:\) to the specific FSX path and called the share FSX. It now shows up as a proper UNC path in both FSInerrogate2 on the wide-client and the FSUIPC.log locally. The lanmanservers entries in the registry were correct, but there was no full FSX path to match since I was sharing entire drives. Much appreciated. :D Regards, Al

Hi Pete, I am trying to read the declared UNC FS path over on my wide-client PC as recorded from with FSUIPC. My WideFS PC (FSXsp2) installation is D:\Microsoft Flight Simulator X\. I have managed to run FSInterrogate2 on the wide-client and it confirms that only the non-UNC install path is recorded at offset 3E00. According to the variables doc, if my FSX pc is networked such as it is, 3E00 should note the full UNC path of the FS Installation. The entire partition/drive (D:) containing the FSXsp2 installation is shared out across the network without any issues noted. Is there something I'm missing trying to get the full UNC FSX Install path? I also see that the local path is only recorded in the FSUIPC.log but when searching back through this forum, I see other's have the full UNC path. Thanks for any thoughts you my have on the subject, Al ********* FSUIPC4, Version 4.321 by Pete Dowson ********* Reading options from "D:\Microsoft Flight Simulator X\Modules\FSUIPC4.ini" User Name="xxxxxxx" User Addr="xxxxxxx" FSUIPC4 Key is provided WideFS7 Key is provided Running inside FSX (SimConnect Acc/SP2 Oct07) Module base=61000000 Wind smoothing fix is fully installed DebugStatus=255 16 System time = 17:09:57 16 FLT UNC path = "C:\Documents and Settings\jordana\My Documents\Flight Simulator X Files\" 16 FS UNC path = "D:\Microsoft Flight Simulator X\"

Well that fact that you added repeat capability to the axis pan_view is much easier to setup and seems to work fine here with 4.306. Thanks for the improvement but I still seem to have the same stutter/repeat issue wheather using the buttons assignment or axis assignment to my hat switch. For some reason, I still get bad stutters with my hat switch when panning around the cockpit or around the outside-view of an aircraft. It's not a frame-rate issue becuase when I enable the joysticks from within the FSX controls menu and the POV (hat) button is set to high in the FSX buttons menu, the hat switch pans around in a super-fast, fluid motion with absolutely zero stutters (less than two seconds to pan all the way around an aircraft). When I again disable the joysticks in the FSX controls menu, the hat switch stutter comes right back. I tried adding RepeatRate=0 to the buttons section of my FSUIPC.ini file to no avail. I'm now confident that I've had this problem for a while, over various versions of FSUIPC, over several different CPU builds, and two different yokes. The only thing I can think of in common is my use of a powered USB hub on my desk to which all my FS periphials are attached. But, if it were a hardware polling issue of some sort, I would think the panning would be as bad when enabling the POV hat switch in the FSX controls menu. Any thoughts as to why my repeat rate on the hat seems much worse then when my joysticks are enabled through the FSX contorls menu? Thanks & regards,

Hmm, than I am really confused, so I'll back up a bit. On my FSXsp2 rig, this past weekend, I started noticing that when panning with my hat switch on my Saitek Yoke, each view rotation/movement would pause for a second or two between movements of the view, like the button repeate rate was wacked-out or something. I know this has been on at least 4.305 and 4.306 interims. For example when holding the hat switch left, it would move a bit to the left, wait a second then move again, and repeat. I have been keeping up with installing the Interim releases as you post them, so I thought maybe something changed. In this thread: viewtopic.php?f=54&t=71448&p=445316&hilit=repeat+rate#p445156 you mentioned having changed the hat from button programming to axis movment, so I thought I missed some news regarding a new way to setup the hat switch. I'm still using the buttons 32 to 39 with the "Pan_view -1" code from the the User's Guide (sorry at work now, don't have exact code). All the other axis and button programming seem to be OK or unchanged, it's just the hat movment that I noticed. Blurb from near the bottom of the second page of the thread mentioned above: "Here it works absolutely the same as in FSX. I have no idea what your hat configuration looks like, so how can I suggest any change? I have a hat assigned to the Pan View axis in FSUIPC4's Axis Assignments. That's it, nothing else to assign. It sounds like you are still using the Button assignments either instead, or as well. Check all this. The improved operation can only work with the axis assignment, and that is regulated to provide exactly the same repeat rate as demonstrated by FSX. In other words, for the same assignment, FSUIPC4 is now doing the same as FSX, so I cannot do any more. Regards Pete" Al

Hi Pete, Just a thought; you might want to add a bold note to the Interim release notes in the FSUIPC locked threads above about the hat switch programming change. I couldn't figure out why my hat switch recenlty started to stutter so bad (2 or 3 seconds) while rotating pan_views. I just found a thread whereby you inidicate that you switched the hat button from the button-repeat functionality over to dedicated axis. Noting this in the Interim notes would save everyone else who has a hat switch from figuring out what changed. Thanks, Al

May be a stupid question, but you did open up the firewall (TCP port 8002) on both machines, correct? Whether it's MS's built-in Windows firewall or a third-party firewall, this action must be performed. If that later, I highly suggest you get rid of any third-party software-firewalls on both machines as they can affect the performance of the WideFS & Simconnect, without any visiable errors. I've been using a very similar setup for years, including the FSX versions. Jim's reply above is correct (he is HiFiSim support from their forum), and you must read and understand that ActiveSky-X now uses the remote Simconnect functionality found in the FSX-Deluxe SDK and the associated SDK patches. Read the "Networking" section of the ASX manual and/or visit the HiFiSim forum for assistance with this one. I can help you over there as well. FWIW, I use FS-Commander X v8.3, AI-Smooth, and Radar Contact on a WideFS/Wideclient and they still work perfectly. Regards,

Yes, mapping flaps to all PMDG aircraft using FSUIPC axis assingments and calibrations work fine as I have been using it this way for several years. From your settings that you list above, several items come to mind. 1) Uncheck "use detents" and don't set specific ranges unless your axis has physical detents for each flap position, which is rare. 2) Make sure you check the "Rev." (reverse) checkbox to reverse the axis input (axis up/away = flaps up / axis down/close = flaps down). Also, make sure FS isn't assigning the same axis to any item in the FS assignments and calibration menu, built-in to FS and therby causing some kind of input-clashing. If you still having trouble, I can post my .ini file sometime later today. Good luck...

Hi Pete, While executing my first flight last night using the latest version of FSUIPC4, v4.28 and FSXsp2, I experienced the dreaded super-fog (whiteout views) that we seemingly solved in the v4.26 beta in this forum, "Possible negative interaction with 4.25?" http://forums.simflight.com/viewtopic.php?f=54&t=69008 Since I had not experienced the issue while using v4.26, can you think of, or double-check any changes that you made to v4.28 that may of caused this issue to rear its ugly head again? Regards,

You're very welcome Pete, it's the least I could do considering all the work you've put into the drops lately. As for FPS, it's a bit hard to tell as I changed Nvidia GPU drivers the other day, but the FPS were still locked @ 24 so these drops do not hurt my FPS in any way.Take care and regards,

Hi Pete, I just e-mailed you my results below and the attached logs and ini for each of the following tests: V4.255 = reconfirmed super-fog within 15 seconds of entering sim-state. V4.256 Test1 (WeatherRewriteSeconds=1) = No Super-fog – tested through ASX “Depiction Output Idle” after entering sim-state (about 8 minutes) V4.256 Test2 (WeatherRewriteSeconds=30) = No Super-fog – tested through ASX “Depiction Output Idle” after entering sim-state (about 5 minutes) V4.256 Test3 (WeatherRewriteSeconds=1 & WeatherReadFactor=1) = No Super-fog – tested through ASX “Depiction Output Idle” after entering sim-state (about 5 minutes) V4.256 Test4 (Erased WeatherRewriteSeconds & WeatherReadFactor to set default) = No Super-fog – tested through ASX “Depiction Output Idle” after entering sim-state (about 5 minutes) Regards,

Yes, "OwnWeatherChanges=Yes" is in my ini which I have including in the e-mail I just sent to you for verification of current settings for Test1 :D I am also re-running Test1 right now (so far without super-fog). OK, and understand. My intentions are:Test2: Change: WeatherRewriteSeconds=1 to WeatherRewriteSeconds=30 Test3 Change: WeatherRewriteSeconds=30 WeatherReadFactor=2 To: WeatherRewriteSeconds=1 WeatherReadFactor=1 OK, but I may back-up to v4.255 for a minute to re-validate my test scenario is still capable of the super-fog. Good idea?Regards,

Pete, Good news, after waiting almost 5 minutes at the startup of my Green Bay, WI test scenario, I did NOT encounter the Super-Fog during the first test (Test1) of version v4.256 moments ago. This is the same test scenario where I have been consistently getting super-fog immediately after ASX starts its depiction process from the simconnect-client. The only thing I changed for Test1 (since v4.255) was the upgrade of the dll to v4.256 and manually entered the line “WeatherRewriteSeconds=1” prior to starting FSX. Of importance, I have these settings in my FSUIPC.ini: SuppressWindTurbulence=Yes VisibilityOptions=No LogWeather=Yes WeatherRewriteSeconds=1 WeatherReadFactor=2 Do I proceed with the rest of the requested v4.256 tests as stated in the download thread or do we move in a different direction now that Test1 seems to have made a difference? For confirmation, how can I revert back to verify I still get super-fog while still using v4.256? If desired I could re-perform Test1 again but let it go a lot longer (sitting on the tarmac), although the simconnect log will get rather as you know. Will post this result in the forum thread and wait for your advise there. GOOD JOB!