Pete Dowson

I suspect that is the usual Saitek installation error which afflicts a lot of folks, and needs a Registry fix. Check the Saitek support forum. Otherwise it could simply be that you are using the assignments in FSUIPC which provide a reverse zone, which before calibration whould certainly place the idle at around 40-50% (though by proper calibration you could set that where you wished). If you want to use it as a simple forward thrust only lever then assign your single throttle lever only to "axis throttle set" and calibrate on page 1 of the calibration tab. Regards Pete

No, on the contrary, it is not actually possible to get reverse thrust using the page 1 generic assignment. This is because it is still sending the Axis_Throttle_Set control, and that control provides no reverse thrust capabilities in FS at all! This is why it has to be mapped to the separate controls -- THROTTLEn_SET are the only ones offering reverse in FS, which is why they are mapped to those controls in the first place. I'm afraid none of the symptoms you describe make any sense at all to me, and are not and never have been reproducible here on any of my systems. If other folks were getting the results you are getting there'd be a hue and cry, because they simply negate one of the main and mostly used facilities FSUIPC offers. As I said, it is just not possible in FS to get axis-driven reverse using the normal Axis controls. So I am completely bewildered at what is going on in your system. And because of that I've no idea what to suggest. Perhaps at least enable the Axis Logging again and show me a section of the log where you are achieving reverse thrust with the generc throttle assignment only. I'd also like to see the INI file again please. Pete

Oops! Thanks for finding this. Silly little bug, a typo in the code. I'll fix it in 4.837, 3.999q and Wideclient 6.972, probably later today ... [LATER] Okay. Fixed, updates now available in Download Links subforum. Regards Pete

Correct. Why play the sound with zero volume? Just don't play it, or stop it if playing. FSUIPC scales the volume to give more precise control with 100 positions that otherwise you'd get. Yes, as it says. Why would you want to play sounds with no sound? As Marcelo says, and as stated in the documentation for the sound.play function, just set the volume control -ve. (Obviously you cannot do this for zero, so don't use zero). Regards Pete

Wow! There's something really wrong if the values don't change. This is assigning to "axis throttle set", then, on page 1 in FSUIPC calibration, checking to Map option, and then calibrating in the 4 throttles page? If you are doing that and seeing no changes then you have some really serious problem somewhere. Please enable axis logging again and see if your joystick is actually doing anything. Why not follow the instructions in the User Guide? You know the saying, "if all else fails, follow the instructions" or similar? I assume your partner (the one using the other joystick) doesn't know any more? Regards Pete

2008!? No, you've read it incorrectly. It doesn't say that. It is not possible to bypass SimConnect successfully. The special test version it describes in one place was never released generally. All control is done through SimConnect. The "circuitous route" which is being bypassed is only the one described -- I've highlighted it here in red: The last is still necessary otherwise FS will never see the request at all! The first two are omitted. If you assign in FS instead of FSUIPC you get two sets of messages, the last two. It's a pity you didn't provide a link to the 4 year old post you referenced, as I would be interested to see how it resolved. I certainly didn't remember it, nor have ever seen any similar incidents that I recall. If this was a general problem you'd expect to see it a lot. There is a way to find out what SimConnect is doing, and that is to enable SimConnect logging and see what that log looks like. See the FAQ subforum where there are instructions for getting one of these. Your INI file looks okay, though this shows you've not calibrated the throttle properly yet: Throttle1=-16380,-512,512,16380 Those are the default values, certainly not agreeing with your earlier statement The logging shows a much lower and well spaced out set of axis requests. There's no way anything will be overloaded by this level. In fact considering FSUIPC polls the axes at set intervals, there's no way to overload anything no matter how assigned There's something else going on in your system. I don't know where. You say but as you can see, the only throttle operation going on is it being reduced to idle very quickly (the numbers on the left are miliiseconds, so thise complete sequencxe is less than a third of a second): 676982 *** AXIS: Cntrl= 65821 (0x0001011d), Param= 13348 (0x00003424) THROTTLE2_SET 676982 *** AXIS: Cntrl= 65820 (0x0001011c), Param= 13348 (0x00003424) THROTTLE1_SET 677122 *** AXIS: Cntrl= 65821 (0x0001011d), Param= 2907 (0x00000b5b) THROTTLE2_SET 677122 *** AXIS: Cntrl= 65820 (0x0001011c), Param= 2907 (0x00000b5b) THROTTLE1_SET 677262 *** AXIS: Cntrl= 65821 (0x0001011d), Param= 0 (0x00000000) THROTTLE2_SET 677262 *** AXIS: Cntrl= 65820 (0x0001011c), Param= 0 (0x00000000) THROTTLE1_SET What else do you have installed in your FSX system? There must be something wrong somewhere, because your use of these facilities is very common and quite basic. It isn't complicated -- the mapping simply causes two controls to be sent instead of one, as you can see. For a 4 engined plave it would send 4. These aren't large loads for SimConnect -- you should see what happens with add-on aircraft like the PMDG or LevelD ones! I'm not sure how to advise you to proceed. If you do have other add-ons try a process of elimination in case one of them is interacting here. And, as you say, you don't have a problem with other ways of assigning, so why not use those? You can do everything you are currenty doing with standard assignment to FS controls and also with assignment in FSX itself. In fact the more common way is to assign to generic throttle ("Throttle" for direct FSUIPC, "Axis throttle set" for FSUIPC assignment to FS control, or the one main throttle in FSX) then map it to the 4 separate throttles on page 1 of the FSUIPC calibrations. That's the way actually recommended in the FSUIPC User Guide. Regards Pete

Are they the same whether num lock is on or off? As Andy says, EZdok key usage can be reassigned. I have done so here. If the wheel inputs look like standard keypresses and cannot be changed, then FSUIPC can no more distinguish them than can FS. Your best bet is most certainly to change the EZdok settings instead. Regards Pete

BTW, further to my last reply, I've just done here EXACTLY what you say you've done there, with FSUIPC 4.836, and it all worked correctly. Note that the "arbitration" for throttles takes the last one to give the highest value (most forward thrust) and then stays with that until the other is moved to exceed it. This is different from arbitration for aileron, elevator and rudder. Pete

I've not see any similar problem reported here before. First thing to do, always before reporting any sort of problem, is to check that you are up to date -- which you are not. The current main release is 4.827 and there are later updates in the Download Links subforum. Any particular reason for selecting the "direct" option instead of the normal FS controls. You should also know that you can still leave your throttles assigned in FSX, as generic throttles, and map them to the 4 separate throttles in FSUIPC. Jumping straight from using FS assignments to FSUIPC assignments is never necessary -- the FSUIPC mapping and calibration faciities long preceded to addition of the assignment capabilities, which were added for the more complex cockpit situations or when needing different axis assignments according to aircraft type. In the case of two separate sets of controls, FSUIPC's "direct" assignment does give one advantage -- FSUIPC can then arbitrate between them, using only the one wth the larrgest deflection. However, with throttles it may sometimes be better just to have an idle zone large enough for the currently unused input to be parked there without any risk of "jitter" interfering with the other one. You should always make an idle zone, not just one point, to ensure idle can always be set despite the invariable small aberrations which will occur. You should also calibrate with the max and min settings a little away from the extremes for the same reason. If you follow the numbered steps for calibration in the User Guide you will get better results. That's the whole point of calibration after all. Of course. "Throttle1" means "throttle for engine 1". Where do you get this idea from? FSUIPC has never "bypassed simconnect" and cannot do so. All controls are operated through Simconnect. Can you point me to this misleading post, please? I know of no possible reason for FSX to hang simply from use of any axis assignment or calibration. Something else is going on. I need more information -- please show me the FSUIPC4.INI file (from the FSX Modules folder). You could also try enabling FSUIPC's axis logging (in the Logging tab) so you can see what is going on. If you temporarily switch FSX into Windowed mode and enable the Console Log you will be able to see the results of moving the axis in real time. However, before doing ANY of this, please update your FSUIPC4. I don't want to see any results with an old version -- use 4.827 or later (run the FSUIPC4 installer and then copy in 4.836 for the latest version). What makes you think that? It doesn't matter how or where you assign axes -- all of the mapping and calibration facilities are available no matter where or how you assign. Assignment is always a separate business. Regards Pete

Good! Pete

I see. If you run FS "as administrator" then any program linking to FSUIPC also has to be run that way. Windows prevents programs of different privilege levels exchanging data with each other via memory sharing, which is how the link works. Generally it should not be necessary to run any of these programs "as administrator", but I know such tricks are used for FS9 if it is (mistakenly, in my view) allowed to install into the protected "Program Files (x86)" folder of Windows, which is where it goes by default. Regards Pete

FSUIPC 4.836 is now available, and the Lua documentation is updated in its thread in Download Links. Regards Pete

Good. That makes sense assuming their "read lights" function always returns zero. The results you got with the mixed masks earlier, though, remain inexplicable. I don't see how those results were possible. I've added a "ReadLights" function to the GFD library, but it will of course always return zero on your RP48. It'll be included in the update 4.836 which i'll release tomorrow I expect, along with the FSUIPC3 version and WideClient. Thanks for the feedback! Regards Pete

Okay. Just for information, FSUIPC doesn't use the run-time, everything it needs is either built-in or shared with FS. Interesting. i was born in Hillingdon, Middlesex and grew up near Slough, but moved to Kidsgrove (now part of the borough of N-u-L) when I got married, in order to work for English-Electric-Leo computers. That was in 1964. Worked at Copthall House in N-u-L (near the Baths) for years. Been living in Knypersley, near Biddulph, for the last 31 years though, after leaving ICL.. ;-) At least two colleagues of mine, from English-Electric (by then ICL) emigrated to Canada in the early 80's and we are still in touch with one couple, in Nepean. Regards Pete

I'm not sure what this refers to in any case. Did you add to the wrong thread by any chance? Pete

And what's changed? I'm afraid I have never heard of either AFSD or FSDAT. Are you sure they are FSUIPC applications? Also, are you talking about a problem with WideFS connection or direct with FSUIPC. Your report is ambiguous. Anyway, I need actual information if you want assistance because there is noe in your message. Please provide this as a minimum: 1. What version of FS or CFS? FSUIPC + WideFS supports everything from FS98 to Prepar3D. Identifying your simulator is a must! 2. Actual version numbers of FSUIPC and, if relevant, WideServer.DL and WideClient.EXE 3. Log files from FSUIPC (from the FS modules folder) and WideServer (if relevant -- also Modules folder) and WideClient (if relevant). Before obtaining log files make sure you close everything down -- both FS and WideClient (if relevant). Pete

Actually I booted up my cockpit this morning and it did say there was an update, which i let it do. I didn't notice any problems thereafter, though. I'm still waiting for options in GSX for: 1. Calling up the fuel trucks without getting the fuel menu coming up. (I have in-cockpit means of controlling felling)., and 2. Remote control of the menu and its selections, as is possible with AES, so i don't have menu overlays on the outside world! Both have been requested by myself and others, but no joy yet. Regards Pete

Well if you do need to write to an L:Var it would mean having a macro file invoked via the offsets in FSUIPC to do these things. But it might be much simpler than that! Why not simply find out how you (YOU, the pilot) is changing the heading bug! What is happening when you change it using whatever means the aircraft currently provides -- i.e. via keyboard or mouse?That's whyt i suggested logging! If you know how that is done then doing the same from your program can be derived! Why jump straight into more complex things before checking the simpler ones? Note, in any case, that there is an FSUIPC "control" you can assign to log L:Vars. It isn't really so complex! Pete

BTW looking at the Real Air site, I notice this listed as one of the improvements they mad to the aircraft in their SP1 update: • Improved support for advanced hardware input devices: You can now use advanced hardware input devices such as those made by GoFlight and Elite to control the HSI heading and course knobs as well as the VOR2 OBS knob. Also, when using these or similar devices to adjust the autopilot altitude you should now correctly see your selected altitude on the autopilot screen. Maybe you need to update the aircraft? Pete

Yes, but I don't think you read my last reply properly. I'll repeat the important parts: Many add-on aircraft use their own autopilot values. It is probably simply writing back to the FS value because it uses a standard bit of gauge for its display. ... see what controls it uses when changing the heading bug on screen. Do the standard FS keystrokes work? Do the standard FS controls work if you assign them in FSUIPC? In other words, find out how you can normally change the heading bug! I'm sure it cannot be fixed permanently at 168 as you seemed to imply in your last message! Obviously writing to the FS offset is pointless. Also: It may be using local gauge variables (L:vars) to hold values like this. Try logging L:Vars and see if one of those holds the heading bug value. ... have you checked the User Contributions subforum here? I just had a quick look, searching for "Duke" and there are two threads with lots of examples. Seems the aircraft uses L:Vars quite extensively. The solution probably lies in that direction. I shouldn't really have to repeat these things. Obviously you must be able to change the heading bug, and not via the offset which it is permanently in control of. Why not investigate in the ways I suggested? Regards Pete

Buttons of various types are usually easier to find than rotary encoders, especialy those dual concentric types! I get my supplies from places in the UK like Maplins and Conrad. I think Conrad is multinational, you'll need to check. the UK site is http://www.conrad.com/Components.htm?websale7=conrad-int&ci=SHOP_B2C_TAB_COMPONENTS. Regards Pete

But it is actually impossible, because the device cannot know what clear mask you've set. All it sees is the end resulting value I send it. It simply makes no sense. If it isn't consistent, it cannot be consistent when data it doesn't know anything about is one value as opposed to another. Well I could understand the readlights returning a random value, but that would only make random lights stay on or come on, it can never prevent lights you are explicitly lighting being lit! Well, it is possible, of course. I just don't see the point. What would be "nice" about it? Regards Pete

FSUIPC4835test.zip Thanks, Pete

WideClient is simply waiting for the Server to identify itself. If your Network is actually working, this will be automatic only if both PCs are in the same workgroup. if not you can either change them so they are, or tell WideClient the name of the Server and the Protocol to be used. This is all explained in simple terms in the section of the WideFS user guide which has a RED banner pleading with your to read at least that part. It isn't a lot to read. It's at the beginning of the installing WideFS part. Pete

If the reading of indicators from the RP48 isn't working because of a firmware fault, then the only sets of masks which will give consistent results are those where ALL the bits are accounted for. Where a bit isn't specified to be on or off, the value read back, incorrectly, will be used, and is likely to be always 0 (off). Actually, the behaviour is astoundingly bad! Can you double-check, please? The logic in SetLights is as follows: X = readlights from device Y = X and (not ClearMask) Y = Y or SetMask writelights with Y For a working "readlights" your first test output would therefore do this: X = 0 Y = 0 and (not 0x55) = 0 Y = Y or 0x0F = 0x0F Note that the result being written is completely independent of the ClearMask, so it would be the same if that has been 0xFF. Note also that the written result always has non-zero bits meaning "light the LED", and that is going to happen independently of the return from "readlights" or the value of the clearMask, and yet your result shows no lights at all on the RP48. So, I can't see how you can ever get consistent results. even with 0xFF as "ClearMask", which you should expect, then as the above logic shows the only possibly incorrect lights with other ClearMasks much be only those lights not featured in the ClearMask. No, if the device is operating unpredictably,.as your result shows, then no workaround seems possible. It won't set the lights i tell it to! So it is just a matter of luck whether you get the right results! BUT, for now I've assumed that my LGT2 workaround will work for this RP48 - i.e. that your findings above aren't typical -- and i'm making an update (4.835) with this workaround in. I'd be grateful if you'd try it directly, please, and see if it helps or if you still get the random results it appears you might from your tests. If you do confirm your very strange findings, I'll write to my contact in GoFlight and tell him that this version of the RP48 is simply not supportable as it stands. I hope you are submitting a bug report. If the workaround is, contrary to expectations, okay, then I'll apply it to FSUIPC3 and WideClient. But i'll wait for results first. I'll post a link to the update here in a short while ... Pete