Pete Dowson

Yes, by multiple assignments to the same button. But it is not efficent nor reliable, and there are far better ways. There are specific megneto switch selection controls provided by FS -- MAGNETO Off, Left, Right, Both, start. Just assign directly to those! Sorry, I've no idea how this part relates to the first part. Offset 3340 is the start of the array of 288 virtual button bits, occupying 36 bytes, not 4. If you need to control magneto switches by offsets, there are simple 2-byte offsets for each engine. e.g 0892 for Magneto1. Regards Pete

The VRI facilities are initiated by the INI file entries telling it which COM ports are used for what. If the Open command fails at that time, during initialisation, then the device isn't connected for that session. The same does actually apply to FS's own use of devices. The Lua basic COM library facilities open ports and close them by specific programming, not by initialisation through INI file declarations. Not without a massive amount of re-organising code, which I am not willing to do. Sorry. Too error prone. And really, considering most users wil also be using SerialFP2 alongside FSUIPC Lua additions, and that would certainly not be easily introduced later, it really doesn't have a huge application among users. The whole design of the VRI facilities was to make it relatively easy for VRI users to use FSUIPC, not replace the whole of VRI's programming. There is no particular reason why direct COM programming would be less efficient, except possibly in the decoding of all of the VRI commands. That's quite a lot of code in fast C compared with interpreted Lua. And a lot of work for you. But as the speed only has to match use button pressing abilities, efficiency and speed are not at all of the essence, are they? Regards Pete

Thanks. I've downloaded it and will take a look tomorrow. Regards Pete

No need now, I remembered. See the Download Links subforum. the latest updates contain the facilities you requested. Details are there. Regards Pete

I haven't checked the GoFlight website, sorry. Certainly they should provide the latest there too. Check the version number. I posted it in this Forum to replace the previous one I was providing. Regards Pete

I've had a chance to test this today. With the latest version of GFDev.dll (the 2.0.0.1 version posted in the Download Links subforum), all dials and switches on both the MCP Pro and the EFIS unit are seen okay by the Lua gfd library functions. I'm now looking at adding display facilities to the gfd library for the new GF-WP6. Regards Pete

The problem is that a lot of add-on aircraft do their own thing, ignoring the FS systems which is all FSUIPC or FS know. There might be ways of dealing with add-on peculiarities, but these almost always have to be investigated separately, and it can get complicated. Therefore, when setting up controls of any sort you always need to start with a suitable default aircraft. Then, when trying it on the add-on you will detect whether it is a change the add-on has introdced rather than something wrong with your controls or the way you are programming them. Okay. But tell me, does the F86 have continuously variable speed brake setting capability? Or is it an "on" and "off", or some other discrete rather than continuous arrangement. Because if it is discrete, not continuous, then i can see why an axis assignment might not be applicable, at least directly. If you wanted to use a lever (an axis) instead of switches or buttons you'd then have to program the axis to send those switch or button controls instead. That can also be done in FSUIPC, but it is done on the right-hand side of the Assignments tab, and there's no calibration involved. Thank you. Pete

Always, ALWAYS, test with default aircraft. If it works on the default FS aircraft but not on the add-on, then you have to ask the add-on makers how to driver their specially modified controls. FSUIPC can only offer standard FS controls. It doesn't know about any fancy differences for aircraft. BTW please ALWAYS state version number of FSUIPC when asking for support. regards Pete

I assume you must actually mean versions 4.30 and 4.60, respectively, rather than 3 and 6. Please update to 4.70 as 4.60 is no longer supported. Regards Pete

PFC are the people to ask about this, but if it is the device I am thinking of then, yes, it works either with my PFCFSX.DLL driver, or the PFCHID.DLL driver, depending on whether it is a COM serial port device or one of the more recent full USB HID device. Both these packages are available in the Download Links subforum. Doesn't the device come with any documentation at all? PFC do have a website and Support forum. Incidentally, please, next time you post here, use a more relevant subject title for the thread, so that other folks know whether it might also be useful for them. That's the point of a Forum support, to help lots of folks at the same time! ;-) Regards Pete

ALT+Enter switches between FS in Windowed mode and FS in full screen mode. it has nothing whatsoever to do with any "toolbars". Have you not used FSX before? It should have its own documentation on how to use it. You need to get to FS's menu in order to access any of its flight mode options. The AddOns menu is only one of them, and that's where FSUIPC's settings are found too. Try pressing and holding the ALT key to bring up the FS menu, or, if you wish, making it permanently overlay your view by using the right-click menu selection. Otherwise, please refer to Microsoft's own instructions for using FSX. Personally I think it would be a mistake to try to use FSUIPC options before even knowing anything about FSX. BTW the files you attached show everything is okay as far as FSUIPC4 is concerned. Your so-called "trouble with FSUIPC4", is rather unfairly attributed. Regards Pete

FS's own assignment facilities are oriented towards buttons, not toggle switches. Certainly FSUIPC will allow you to assign one action to the switch 'on' (=button press) and another to the 'off'. (=button release). With many of FS's own controls there is only a "Toggle" version, not separate "On" and "Off" controls. Where there are separate controls you can use those, but Fuel Pump is not one. So for that you have two alternatives: 1. Program the same "toggle" control for both "on" and "off" switch actions. This works fine provided the FS switch and your real switch are synchronised -- i.e. start in the same position. It means you have to check the switches match FS before you start. 2. Program the switch to use FSUIPC offsets -- i.e. values written or bit changes directly in the data which affects FS internally. This is a little more complicated as you have to find the correct "offset" value and work out which Offset control to use. If you want to try this way you will need to also download the FSUIPC SDK package which contains the lists of offsets. If you want help with the latter method, do come and ask. Regards Pete

Error 2 is file not found, so either it isn't a program (exe or com file) or you have something else wrong in the path or name. It is rather suspicious that you are trying without the ".exe" part in the first place, as that is needed if it is an exe file. Create a shortcut for the program, which works when you click it, then right-click on the shortcut icon, select Properties, and check the 2target". That should show a full path to the program, the exe. cut and paste that into your Wideclient INI file. Regards Pete

There's no need nor point in changing the email. You'd have to purchase a new key. The email is only used to tie the key to you and your name, it isn't used to send you anything! This is almost always due to a video driver problem. FSUIPC is not actually doing anything at that time, it is Windows trying to draw the options dialogue from the standard resource data. Try it in Windowed mode (switch FS between windowed and full screen mode using ALT+Enter). If it then works it proves it is a driver problem because that's the only difference. You need to find a better driver for your video card, or stick to using Windowed mode for FS. The log shows FSUIPC is running perfectly okay. Regards Pete

Try this one and let me know. If it's okay I'll probably add it to the examples I supply. [LATER EDIT: The code is now fixed and tested, and will appear in the examples pack] See if my comments tell you enough on how to use it. If not I'll try to clarify more. Regards Pete Vendor = "Bodnar" Product = "BU0836X" Device = 0 -- Multiple devices of the same name need increasing Device numbers -- Use separate Lua plug-ins for separate cards! -- NOTE: this can handle up to 16 rotaries only, using the first 64 "virtual buttons" -- List the pairs here: Rotaries = {} -- Example { 31, 30, 25, 22 } would be 31+30 for one, 25+22 for the next, and so on -- Which is clockwise and which counterclockwise doesn't matter -- you'll get -- fast and slow of each in any case dev, rd, wrf, wr, init = com.openhid(Vendor, Product, Device, Report) if dev == 0 then ipc.log("Could not open HID") ipc.exit() end -- Set the boundary time in milliseconds between -- "fast" (shorter) and "slow" (longer) signalling FastTimeLimit = 100 -- Adjust to taste -- Polling time in milliseconds: should be much shorter than -- the boundary time Pollrate = 20 -- same as 50 times per second -- Initialise variables used to keep track of things LastTimes = {} Buttons = 0 PrevButtons = 0 Diff = 0 -- This function will be called by a time event, set at the end of the program before exit. function poll(Time) -- read any data available from the device (only need most recent report) data, n = com.readlast(dev, rd) if n ~= 0 then -- Data was returned, so get the status of all the possible "buttons" we are using -- one value of 32 bits Buttons = com.gethidbuttons(dev, data) -- See if any changes occurred: Diff = logic.Xor(Buttons, PrevButtons) PrevButtons = Buttons if Diff ~= 0 then offset = 0x3340 buttonbit = 1 j = 1 while Rotaries[j] ~= nil do mask = logic.Shl(1, Rotaries[j]) if logic.And(Diff,mask) ~= 0 then -- This one changed -- See if changed in less than the "boundary" time thisbutton = buttonbit if (LastTimes[j] ~= nil) and ((Time - LastTimes[j]) < FastTimeLimit) then thisbutton = buttonbit + buttonbit -- Use next higher button for fast end LastTimes[j] = Time -- Toggle a virtual button accordingly ipc.togglebitsUB(offset, thisbutton) end j = j + 1 buttonbit = 4 * buttonbit if logic.And(j,15) == 0 then buttonbit = 1 offset = offset + 4 end end end end end event.timer(Pollrate, "poll")

You need to help yourself by purchasing new keys for FSUIPC4 and WideFS7, as already pointed out. Pete

Oh, is that all? that's easy then ... I was looking at supporting the max FSUIPC could handle in the virtual Buttons, which would be 72 (72 x 4 = 288 button inputs). Yes, according to the tests we did and the Lua code I supplied. With it limited to only 16, that is okay. It just wasn't nice for the generalised case of up to 72. Regards Pete

Isn't that the same for nearly all aircraft, including all Boeing airliners? On the contrary, all FSUIPC offers (all it can offer) is the spoiler axis, which is the same one you can assign in FS itself. In FS there is no difference between "speed brakes" and "spoilers" -- they are called speed brakes when used up to one point in the air ("flight" detente on the boeings), and spoilers when used after landing in the fully deployed position. FS calls them spoilers in both cases. FSUIPC does not invent facilities which FS does not have, it only provides an alternative way of doing the same things. I don't know how you have become confused and think there is more to it. There is not. Simply assign the spoiler axis as you wish, in FS or in FSUIPC. You may need to reverse the axis, in the calibration section, in order to have it deployed when pulled back, the opposite of a throttle lever (but the same as a flaps lever). That is all. Regards Pete

Hmmm. Well, I'll look at it, but I'm up to my eyes with stuff this week. Remind me on the weekend please. Pete

Why not just turn it on and leave it on till you are done? That's what i do. Regards Pete

Sorry, no, there's no provisions for that at present. What's the application for such an odd facility? Pete

Email me details to petedowson@btconnect.com. Regards Pete

No, sorry. You can change the email address, but not the name. Something has to identify you. Using different names implies different users. Originally i had both name and email fixed, but folks change email addresses so that was relaxed. Changing names isn't good. You could try raising a problem ticket at SimMarket, explain yourself and hope they'll sympathise. But they are pretty clear about these things. Regards Pete

Yes, nearly there. I'll definitely get to it this week. [LATER] Just looking at the problem now, some questions arise which will make it easier for you to adapt: 1. How many, maximum, rotaries can be fitted to one BUO836X card? 2. Is is possible to ensure that they are altogether in termis of the indications they send -- like your example sent bits 31 and 30 (shown as x80000000 and x40000000)? If so it makes it much easier to generalise, simply scanning the bits in order. Otherwise you'd have to list every bit in a table, much messier. Regards Pete

It's 0C49, not 049C, and the documentation says -127 to +127. I don't know what you are reading. There's no possible value "254", or even 138, in a signed byte -- there are only 8 bits in a byte, and when it is signed it only has 7 bits for the value. that's why it runs from -127 to +127. You are treating it as an unsigned value, running from 0 to 255. You cannot expect to get a negative number in an unsigned value! It's the sign which tells you whether it is negative or positive! If whatever system you are using cannot treat numbers as signed when they are, just subtract 256 from the value you do get when it is 128 or greater. You'll notice your "254" is really -2. Pete