Pete Dowson

FS assigns things (axes and buttons) automatically, using it's own idea of what is what from the connected devices. If you assign in FSUIPC you MUST unassign in FS, or, better, disable the controllers in FS. HOWEVER, I see you have not assigned them in FSUIPC, so leave well alone. You appear to have skipped some steps in the calibration process -- those centre zone values are defaults. I doubt whether they would truly suit any real device. I don't think you've set the centre values correctly. Also the min and max values for the aileron control seem very low -- compare them with your elevator. I don't think you turned the aileron control anywhere near far enough when calibrating. This will mean the whole range of the simulated aieron is covered in just the small left-right zone you calibrated it to. That is bound to give you rather over-sensitive control -- good for fighter pilots but not for most aviation. I suggest you start again with the calibration, and follow the steps ennumerated in the user guide one by one. Regards Pete

For text files it's best to simply paste them in. Saves me time too, not having to click and download attachments then deleting them from my disk afterwards. Your Lua plug-in sound test works fine here, exactly as you posted it, both in FSX and Prepar3D 1.4. All i can think is that it cannot find the "CabinAlert.wav" file. I'd need to see your INI file to check the sound path. Can you check the wave file is where FSUIPC is looking? There's really nothing else to go wrong. More logging in the FSUIPC sound module is available. Edit the INI file, adding: Debug=Please LogExtras=x20 to the [General] section. For me, then running your test Lua, this shows for P3D: 24648 Sound: Id 1, PlayNow("CabinAlert") 24648 Sound: Id 1, PlayTheSound("E:\Prepar3D 14\Sound\CabinAlert.wav") 26349 Sound: Id 1 DeActivate: sound not playing now ... 26349 Sound: Id 1 EndPlay: releasing buffer 26349 Sound: Id 0 EndPlay: all done! [/CODE] You don't need to run the Lua in debug logging mode -- it isn't that complex that it cannot be followed. Regards Pete

Version 3.99 is well out of date and not supported. The signature system has been changed since then. Please always check that you are using a current and supported version -- 3.999w is the earliest such version, and there is a later interim update to 3.999x available in Download Links. Pete

I'm afraid it sounds like you are one of the few users suffering from the timing bug in FSX's SimConnect, related to the trust verification process. Please see the thread in the FAQ subforum entitled "FSX fails to run after FSUIPC4 first installed" As you will read there, it isn't an easy problem to overcome I'm afraid. Unfortunately I've never actually seen the problem occur on any system i've been involved with (I suppose that means I'm lucky, but it does prevent any in depth investigation in the SimConnect code layers). Microsoft did know about this problem and tried to fix it -- it is a lot worse with the base release, and a lot better (ie rarer) with SP1 + SP2 installed (or Acceleration) -- but they only managed to reduce the probability, not fix the cause which they really believed was in Windiws itself not their code but never proved it. So if you haven't already done so, make sure you install the FSX updates SP1 + SP2 or Acceleration. That, I'm afraid, I don't know. You'd probably need to write a program to interface your application. FSUIPC4 does include a facility called "GPSout" which does feed NMEA 0183 formatted standard GPS data out to a selected serial (COM) port. Sometimes USB connections emulate standard serial ports for their connection to external devices. Whether your Bluetooth connection can be operated that way I don't know -- it will most likely depend on whatever drivers come with your device or appication. The first thing to find out, though, is whether your Garmin Pilot can accept the NMEA 0183 type GPS input from whatever connection you might be able to rig up, overriding the internal GPS it would normally use. Most moving map programs for these devices don't provide such options. If you write your own program to do the interfacing to your device then you can use the FS interface supported by FSUIPC and documented in the FSUIPC SDK without needing to pay for and register FSUIPC. The aplication interface is free for personal and non-commercial use. The GPSout and Lua plug-in programming facilities are part of the benefits of purchasing the license. It would work if SimConnect could load it. See above. Pete

Sounds like you made a mess of calibration, or you have the axes assigned both in FSUIPC and in FSX so the differing values conflict. No way does any form of calibration following the instructions ever exaggerate anything. It's simply a process of matching the range of values coming from your controls to the range of values expected by FS. If you want any advice about what you've done, show me the settings you've made -- the FSUIPC4.INI file from the FSX modules folder. But first, if you are assigning in FSUIPC disable controllers in FSX. If you are not, then make sure the sliders are set correctly in FSX, as instructed -- sensitivity full right (max), null zone full left (off). Do that BEFORE calibrating. Pete

And it is assigned, and it is sent then the button is seen as "pressed". This is clearly shown in your log: 1205841 VRI command USRBTN1. trapped as Joy 290 Btn 17 Toggle 1205982 Button changed: bRef=0, Joy=290, Btn=17, Pressed 1205982 [Buttons] 2=P290,17,C66298,0 1205982 FS Control Sent: Ctrl=66298, Param=0 1205982 *** EVENT: Cntrl= 66298 (0x000102fa), Param= 0 (0x00000000) INCREASE_AUTOBRAKE_CONTROL [/CODE] As I said, VRi buttons act like toggles, so you should assign to both press AND release -- you clearly have not done the latter as shown by the only other time you pressed it in this log: [CODE] 1202518 VRI command USRBTN1. trapped as Joy 290 Btn 17 Toggle 1202581 Button changed: bRef=0, Joy=290, Btn=17, Released [/CODE] When testing such things you'd be best not loading an aircraft like the PMDG, as it does tend to constantly sent FS controls all of the time, -- resulting in your long log with little of interest. Control 85637 is one of its own controls and I think it also uses "rotor brake" controls for something devious, internally. For a cleaner log so you can see what is going on, load the default 738. You'll see the Autobrake increase each other button press, they way you've programmed it. Additionally it is likely (though I don't know) that the PMDG aircraft does not obey default FSX commands like the A/B ones. You'll probablyneed to use its own controls as listed in the 737NGX SDK. Pete

Yes, probably -- if re-written to do so. though I'm not actually sure if all of its functions would be covered as I don't really know it. Of course. All of those which work through FSUIPC on FS9 should work, and certainly most do -- after all, that was the whole reason for the continuously compatible interface FSUIPC has offered since FS2000 days.. There are some newer programs whose developers chose to use FSUIPC over SimConnect too, either because they found it easier or more familiar or, more likely, because they could also then port to FS9. Once it was realised that FS9 wasn't going to die any time soon its number of users is still an attraction for developers. Pete

Where on Earth did you get 4.60a? That's really way way out of date and not available anywhere I know about. The earliest supported version is 4.853. Please download it and reinstall. The registration key supplied for FSUIPC4 is for you, the User, and can be used on any and all computers you own. It is not fixed to any specific hardware. You purchased FSUIPC4, not any specific version. You are expected to keep it up to date if you want continued support. You never need to pay again for the same product. No, and it is not necessary. The only use of the name and email is to tie it specifically to you. it is not actually used as an email address. It could even be a house address. Regards Pete

No, I think it is written specifically for SimConnect. Pete

No. That should work fine. Doesn't it? Enable Button and Event logging in the FSUIPC Logging tab, and try again. Show me the resulting log. Note that VRi buttons operate like toggles -- one press "on", next press "off", etc. If you are assigning a toggle control then you need to assign to both Press and Release otherwise you'd need to press the button twice each time. Regards Pete

Do you have any software drivers installed for this device? If the button is not also assigned in FS (and you say you checked this), it ceretainly sounds like something else you have installed to doing it. Turn on Button and Event logging options in the FSUIPC Logging tab. This will show precisely what is happening. Pete

I'll take a look -- next week. Pete

Hmm. Maybe I misunderstood, but I thought the OP was complaining that the rudder trim had more effect than the rudder itself and wanted the rudder to have as much effect. Pete

The only reason I can think for that to be the case is that you are assigning it to both "Press" and "Release". That's the only difference between a toggle switch and a normal button. If you assign to both press and release you'd have to hold the button down (i.e. not release it) to stop the release action occurring as well as the press. A toggle switch only sends one change (press or release) each time you toggle it! Just delete the assignment to the button release. Not sure what you mean by "I've also tried assigning "do nothing" to the release cycle" but evidently you did that wrong. And why assign anything at all on release? If nothing is assigned to 'release' then nothing will occur on release. Pete

Really? In which aircraft is this? Are you talking about the on-screen gauge button, or a real hardware button? FSUIPC is not a hardware driver, so for external hardware you'd need to do some programming. If you mean a screen gauge in an FS aircraft then the button should surely only light if there were a caution condition, and not many of those are simulated in FS itself, so what aircraft are you using which does have cautions and doesn't bother to light the button? Pete

Yes, but that example is for setting a switch. The 0 and 1 tell it whether to open or close the switch. You are merely entering characters in the FMC scratchpad. The parameter is (theoretically) of no use. However, this part: // Send another command only if there is no active command request // and previous command has been processed by the NGX if (Control.Event == 0) strongly implies that the 737NGX code only accepts a new command if it is different in some way to the previous one. It evidently assumes otherwise that the command is in fact statically set. When you change the parameter 0-1-0 etc it is evidently making it believe the command is different, and then processing it as normal. Hence your repeats. The log proves conclusively that FSUIPC is doing exactly what it should, so the only answer is to find a way to convince the NGX code that you should be allowed to send the same character twice or more when needed. Sorry, you need to explain more about that. What did you try, and what was the result? Really this is now a matter for PMDG support. I don't know what their code is doing or why -- they must be able to advise. It could well be a bug which they should fix. If the only way to to have a different parameter for each keypress, just to make it different from the previous one, then you could implement that by using a Lua plug-in. But please check with PMDG first as that may get complicated with so many keys to program. Pete

There really should be enough rudder action to do what you need the aircraft to do, then, so it sounds like a poor aircraft design.you may be able to adjust rudder effectiveness in the Aircraft.CFG file -- but I'm not the right person to advise on such things. Best trying an aircraft design forum or the support for the aircraft you are using. Pete

Please do not confuse offsets (which are FSUIPC tokens for data in or out of FS) with control numbers. Your 70205 is a control number. It must be that your keyboard emulation is only ever sending a "KEYDOWN" and never a "KEYUP". If a KEYUP is never seen, then separate keystrokes can never be seen. Hmm. Strange. That implies that KEYUP is actually seen after all. So, it is possible that the PMDG implementation needs a different parameter with its 70205 control so it knows it is a new keypress. Can you tell me why you chose to set the parameter "1" in the first place? I don't use any PMDG products myself, but it seems to be something to do with their handling of these controls. Please enable Key and Event logging in the Logging tab of FSUIPC and try again. Show me the Log section showing the results. If this shows that FSUIPC is doing its job correctly, which sounds to be the case, then I think your question is for PMDG. BTW if you press A then B then A again, do you get ABA? If so then it sounds like the PMDG code looks for a change. If so, re-program the key Up control to something innocous -- if such a keypress exists (+603, +605 seem to be unassigned, for example?). Regards Pete

I think that very much depends on the aircraft and which GPS you are using. Whilst FS does include a large range of controls for its GPS, some of them don't work. The transponder mode is not simulated in FS in any case so the switch is merely cosmetic -- if you are using something like FSInn or Squawkbox then they each have their own ways of dealing with the transponder mode and ident functions, and FSUIPC can certainly help there by allowing keypresses to be assigned to buttons. FSUIPC does not use XML. Please review the documentation (which will be installed for you when you install FSUIPC -- you do not have to purchase FSUIPC in order to install it and use it for interfacing applications). Also review the User Contributions subforum where you will see all the different ways folks have found for interfacing different add-on aircraft. As you see, when building any sort of cockpit system you rteally do need to plan for the aircraft you are wanting to use. WideFS supports switches and dials, but not axes, on networked clients. For axes you'd need to write a small Lua plug-in, but generally it is not recommended to have control axes on a client because of latency issues. There's no measurable overhead and little to no delay in having switches on a client. No, not FS gauges, which are merely either XML scripts or small modules wholly dependent on the graphics code in the body of FSX. There are add-on applications which can provide gages external to FS -- FSExpand, SimAvionics, Aerosoft Australia, and Project Magenta all support this sort of thing for different aircraft types. The iFly 737NG Pro version comes with an integrated ability to network too. These programs either use WideFS or their own Networking code. FSUIPC is an interface into FS. It is not a hardware driver. You are under some misuinderstanding here. You can write software to drive any displays you can program and interface via FSUIPC to extract the data for display. FSUIPC does support plug-ins written in Lua which can handle displays too if they are COM or USB connected. It really doesn't matter provided the switches and buttons are visible via Windows (DirectInput). Unless you write Lua plug-ins or external applications for interfacing, FSUIPC handles joystick-type devices via Windows, just like FS -- up to 32 buttons, 4 POVs and 8 axes on each of up to 16 devices. It also supports GoFlight devices via the GFDev.DLL driver supplied by GoFlight and VRI devices with some provisos. Really your best bet is to review the documentation, the supplied Lua examples, and the User Contributions. But you first need to determine what aircraft you are going to be building for. Also check out LINDA which uses Lua plug-ins and a front-end program to make a lot of this stuff easier. Pete

Sorry, I cannot support any operating systems other than Windows XP, Vista, 7 and 8. There is evidently some mis-implemented aspects in the Mac Windows emulator. In fact if no log is ever produced there must be very serious deficiencies because the log creation is one of the very first things it does and it uses basic file creation calls into Windows. Maybe it also doesn't read the INI file for the same reasons? What do you mean by "there is a connection"? Do you mean the Server sees the client but the Client cannot receive from the Server? Did you check for a WideServer log file? Pete

I'm sure that is as intended. It it did not do that and you started panning again there would be a very big jump on panning to reset the coordinates. I don't think there is any other way. Why not try it in FSX mouse look mode, then, so you will know? Why ask me? If you prefer Ezdock why not use it? I do. The FSUIPC mouse look was added by request of others and is simply a mapping onto the FS function. Regards Pete

The files are as they are because that's how folks asked for them. Originally the first files were only intended for Radar Contact -- the utility was written explicitly for it -- and its files have Closed indications included. All the other formats were added one by one on request. Pete

Yes, probably, though I've not tried anything in that aircraft -- but for the default aircraft you should find the FS controls adequate, and especially for simple things like light switches. Pete

If so it will definitely be because that aircraft or FS generally is programmed to make them additive. As far as FSUIPC is concerned they are different axes and it is simply sending the values to FS for it to handle. Are you assigning in FSUIPC as well as calibrating there? If not, if they are assigned in FS instead, then make sure the sensitivity slider is set max (full right) and the dead zone slider set off (full left). Both will otherwise limit the effect of the axes. (FSUIPC's slopes facility does NOT limit anything, it merely changes the sensitivity in one area and balances it in another). Pete

Why? You shouldn't need to execure any that way! I see this: 481434 VRI command USRBTN1. trapped as Joy 290 Btn 17 Toggle[/CODE] but I've no idea if you've assigned anything to Joy 290 Button 17. You don't say and you've not shown me the FSUIPC INI file which contains your assignments. Pete