Pete Dowson

Okay. This explains why, when I connected my PFC throttle quadrant up, it controlled the AirbusX throttles perfectly, out of the box. I'm going to have to enable the A/T then to see what I can do ... Anyway, with any throttle system, be it PFC or other, try the following two Lua plug-ins: First this, saved as AirbusX_Thr1.lua: ipc.writeLvar("L:AS_FADEC_0", 4096 - (9 * ipcPARAM / 4)) And this, saved as AirbusX_Thr2.lua: ipc.writeLvar("L:AS_FADEC_1", 4096 - (9 * ipcPARAM / 4)) Save them in the FSX Modules folder. Then, in FSUIPC axis assignments, assign Throttle 1 to the so-called 'FS control' Lua AirbusX_Thr1, and similarly Throttle 2 to Lua AirbusX_Thr2. Note that you'll find these listed in the "Send to FS as normal axis" mode, NOT in the "Send direct to FSUIPC" mode. This is a quirk of how macros and plug-ins are recognised. For PFC users, as far as I can see you do NOT need to un-assign the axes in the normal way in PFCFSX.DLL. But I've not actually tried flying the AirbusX yetthe computer I've installed it on is not really suitably set up and i'd need some Airbus familiarisation time first in any case. Note that running a plug-in in this way gives no chance for normal calibration. The computation above: 4096 - (9 * input / 4) is designed to provide the apparently needed range of +40960 (idle) to -32768 (max). This passes through the assorted FADEC modes en route. However, that of course depends on the input value range being -16384 to +16383, which is only likely with a USB-connected digital device. My own PFC throttles only gave a range of -13030 to + 13545 in FSUIPC (allowing for a small dead zone either end -- never forget that), so I had to adjust the formula appropriately. The calculation is easy enough (I append it below), but an alternative to computing the formula is to fill in you minimum and maximum values in this more complex version of the Lua plug-in: mymax = 16380 --replace value with your throttle's max reading in FSUIPC, allowing for a small dead zone mymin = -16380 --replace value with your throttle's min reading in FSUIPC, allowing for a small dead zone mult = -73728 / (mymax - mymin) adj = 40960 - mult * mymin val = adj + (mult * ipcPARAM) ipc.writeLvar("L:AS_FADEC_0", val) That's for Throttle 1. Do the same for Throttle 2 but change "FADEC_0" to "FADEC_1". This longer plug-in is of course not as efficient as the nice short one, so it would really be best for you do actually do the computations and only put the resulting final formula in. So, the explanation: The reasoning behind the computation: Suppose the minimum input value (the negative one) is x and the maximum (the positive one) is y. First you need to compute the multiplier m such that m * (y - x) = (-32768) - 40960 = -73728. which is the FADEC range (it is negative because its max is -ve and min is +ve) So m = -73728 / (y - x) in my case this is m = -73728 / (13545 - (-13030)) = -73728/26575 = -2.774 Now if we multiply the input value by this 'm' we computed, we will get the desired range, but the values will be offset. So we must subtract our computed value from a number which places the values in the correctly offset range. Our 'idle' value is m * x, whereas the idle value we need is +40960, so we need to adjust by a = 40960 - (m * x). Using my own example again, m = -2.774 x = -13030 m * x = 36093 a = 40960 - 36093 = 4867 The final formula in the Lua plug-in you want is a + m * ipcPARAM which in my case comes to 4867 + (-2.77 * ipcPARAM) or more tidily 4867 - (2.77 * ipcPARAM) Feedback on all this please, from folks who know more about Airbus throttles and FADEC than I. If necessary I may build in more useful facilities into FSUIPC, but not without knowing exactly what works and what doesn't. Regards Pete

The thread in the AirbusX Support Forum where I was trying to get some assistance in sorting this out was the one on Hardware Compatibility. Mathijs was sympathetic but he has to leave it to the software guys and they are probably rather overwhelmed with other support issues at present. And, as you say, the Forum is inaccessible at present else I'd give you a direct link to the relevant thread. There is already a way around this which would involve the use of a Lua plug in issuing local variable (L:var) writes for different throttle ranges. The L:vars can select the correct thrust modes. I don't know enough about Airbus, but I understand there's no real continuous throttle control available to the pilot in any case, it is always under computer control. Is this true? I would have thought it could be switched through for emergencies, but if so I am not sure how that would be handled by the simulation. As soon as I have something which appears to work I will publish it here, but Guenseli will probably beat me to it. I will embelish whatever he comes up with for particular application to PFC throttle quadrant use. Note that the use of Lua plug-ins does require a registered install of FSUIPC. Regards Pete

Have you looked at the "gfd" Lua library? It is all very straight-forward. What is the problem? You must ask specific questions, not ask me to do all your work for you. I don't have time! Did you even bother to look at and try the "gfdDisplay.lua" example, provided with the examples installed with FSUIPC? Surely that shows you what to do? I've no idea what you are talking about here, and there is no such thing as "lau" files, only Lua! Anyway, you are making this thread less than useful as a "stickie" for others to refer to. Please start a new thread if you want to continue. Pete

Good. Thanks. Pete

The displays are numbered in sequence, either left to right or right to left, I do not remember. But it should be easy to find out. You can't do any harm -- just write to each one till you find out. It won't explode or do anything else nasty! There's no such thing as a "lau". Please try creating Lua files instead! Pete

If you visited the AirbusX forum discussions over at Aerosoft you would have seen this is already being discussed. I'm not sure what, if any, solution will be forthcoming at present, but keep an eye out here too. Guenseli (see the sticky AirbusX thread in this forum) has located the relevant L:vars to control the FADEC, and these look like a promising way to use any hardware throttle system, programmed via FSUIPC, to select the different throttle modes. Yes, but they can be programmed in FSUIPC too. No, that's not possible. I have no doubt that there will be a solution. Airbus throttles are not continuous thrust controllers in the Boeing (or most other aircraft) senses. The throttle movement merely selects thrust modes, and those modes are selectable via FADEC commands. Programming those in FSUIPC should be possible, but it is still a matter of investigation, something which started a few days ago. Regards Pete

Apart from the fact that I agree with Guenseli about the fact that reading an non-existent L:Var will always give 0 (and which can therefore be assumed), I cannot really comment, as no matter what I do I cannot produce any sort of problem at all. Also, of ocurse, Guenseli has a lot of experience accumulated with Lua and L:vars, and I'm sure you can place your trust in what he says. On another subject, I do wish you'd be more definitive about whether the changes I made in FSUIPC help at all. As one of very few folks reporting any problems at all I have to depend on you to at least report success or failure, and try various timeout values to see which works best. However, I've seen nothing from you apart from a brief mention that folks could "try my update"! Please also refrain from talking about "lau" files, as there is no such thing as "lau" supported by FSUIPC at all. The name of the language supported for plug-ins is Lua! Regards Pete

Yes. Check out the "ButtonKeys" facilities, described near the end of the WideFS technical document. That allows Windows "hot keys" to be used to send virtual button presses, much like the ButtonScreen would have in your original question. The only thing I'm not sure of with Windows hot keys is whether, when more than one application registers the same hot keys, all get notified or only the first or last to register. You'd need to try it -- it's not something I've ever tried I'm afraid. If only one of the WideClients gets the one key you'd be in a similar boat to using the ButtonScreen, having to press a key for each client. [LATER] I've looked up what Windows does with multiple apps using the same hot Key .... they can't. To quote: "... the second instance will fail when it tries to register the hot key, since the first instance has already registered it.". So this is not a perfect solution, though with 5 PCs I suppose it shouldn't be too much of a hardship to press 5 keys one after the other. An alternative which may or may not work is to define the 5 different hotkeys, but program one of the resulting virtual buttons (probably the one directed to the main FS PC) to not only do the Zoom change but also to do a series of 4 KeySends. Then have those keysends programmed in the WideClient INI to press the other 4 hotkeys for you. I'm not sure if that will work because it depends where Windows traps the hotkeys, and it is a very convoluted method, but it may be worth a try. The button programming in that FSUIPC would need editing in the FSUIPC INI file where you can define multiple actions on any buttons. In the end you might find it worth getting a dirt cheap gamepad or similar connected to that client PC so you have a button you can press. You could even program the other buttons on the same thing to do other interesting things ... Regards Pete

Yes, it could well do. Anything to speed it up. But have you tried with the latest FSUIPC updates, in which I've put a time limit on "killing" and "resurrecting" Luas files? I've now installed the AirbusX and tried with and without the timeout, using GoFlight RP48 dials (which act identically to the MCP ones), and I simply cannot make the repeats run fast enough to even try Killing the thread -- using Guenseli's long Lua, too. Admittedly I am using a fairly fast PC for this. However I am programming both fast and slow button numbers, both pressed and released, to maximise the rate, and yet there's still no problems. The logs shown earlier in the thread indicate enormous Lua run times, exceeding 60 mSecs in some cases, which is astonishing. The default timeout in the latest FSUIPC versions is 66 which should catch enough such long times to prevent a crash, but this can be increased if necessary. The alternative of separating all of the functions in the giant Lua into separate Lua's directly assigned to buttons rather than selected by parameter may also work well, depending really on what the cause of the delay is. Maybe it's more related to disk access than processor. Regards Pete

Sorry, I've no idea at all. Are you sure it isn't to do with WidevieW settings? I don't know anything about WidevieW these days -- I've not used it since FS98 days. You'd need to run a separate instance of WideClient for each WideServer, with the server named explicitly for each. Apart from the one instance with which you wish to run applications (i.e. the one talking to the main simulator PC), the others need to have different "classInstance" values. They won't support applications, but will support a button screen. The buttons have to be programmed in the respective FSUIPC buttons menu. You don't need steps. Assign to "Offset Word Set" with a parameter value of 64 times the zoom level needed. I'm afraid you'll need to press such a button for each PC you want so set. If you used a hardware button instead you could program that same button in each FSUIPC and so only have to press the one, once. Each copy of WideClient will see the same button and relay it to their respective servers. That can't be done with button screens, which aren't sharable. Regards Pete

Interesting. Do you have a link for it to share with others? [LATER] Ah. Is it CHCOMM3A? From http://www.flightsim.com/kdl.php?fid=101190 ? That' so long ago I forgot all about it. And I've never looked at it before. Glad it suits your needs anyway! Regards Pete

I couldn't think of any other explanation for the fact than SimConnect was not reporting the loaded aircraft name to FSUIPC -- when it does, it is logged. Glad it was easy after all! Regards Pete

I think you must have a corrupted default flight. Try renaming your FSX.CFG file so that FSX generates a new one. I'd need to see the FSUIPC4 log (and not a Continuation log as you showed here, but a single complete log -- do not press any buttons in the Logging tab!) for a run which did not start WideServer, not one which did. I'm out this evening so there'll be a delay. Pete

One other thought. WideServer doesn't initialise until FSX is ready to fly. In your last FSUIPC log file whether you never got that far as far as FSUIPC4 could tell. It logs the aircraft name you loaded and it never did. Can you enable "Extras" logging in the FSUIPC Logging menu, close FSX, restart it. Wait till you are ready to fly. If no "with wideServer ..." message appears in the title bar, close FSX and show me the FSUIPC4.LOG file. Regards Pete

Sorry, I can't read anything on that pic. I'm surprised you even bothered to splurge read over your details! Does the button read "Disable wideFS" or "Enable WideFS". Better still, show me the FSUIPC4.INI file. No, WideServer is built into FSUIPC4. There's only the one module. There's no separate WideServer module for FSX. Regards Pete

No. FSUIPC doesn't provide any way to add multiplayer or AI traffic. The TCAS injection offsets are for programs using multiplayer to show other folk's aircraft visually to also allow TCAS displays reading aircraft data through FSUIPC to plot their positions etc. FSUIPC itself has no multiplayer interface. If you've created an AI aircraft you can send it some commands through FSUIPC -- the facilities at offset 2900 cover this. You can put them into slew mode and then do some things with them, including moving them. Programs like AI Smooth use these facilities to try to help smooth out traffic patterns at airports. In FS9 and before you need the FS multiplayer SDK to create aircraft. In FSX and ESP you can do it via SimConnect. Ultimate Traffic 2 actually creates all of its AI traffic on FSX via the SimConnect facilities, but it then let's them fly according to injected flight plans. Controlling their flight precisely and step-by-step is obviously more processor-demanding, but should be easily feasible for a single aircraft. Regards Pete

Okay. FSUIPC versions 3.989c and 4.626, now available in the Updates Announcement, provide the button states as follows: Regards Pete

FSUIPC 4.626, now available in the Updates Announcement, includes the timeout precaution I mentioned. I've set the default time to 66 mSecs, so Lua plug-ins are only killed off to be restarted if they take longer than that to execute. From the sound of the more recent reports here this won't actually help, because it looks like the problem is in the AirbusX. However, please update. Regards Pete

The install guide just tells you about installing (and registering if you've purchased FSUIPC). It installs documentation for you. It's the FSUIPC User Guide which it installs which you would need to browse. Regards Pete

You need familiarisation with the Offsets, rather than with the "controls" -- i.e. completely different documentation. Controls are really meant for assignment to buttons and keys, generally not used via the FSUIPC applications interface where, for most things, there are better, more direct, methods. The 3110 offset is a "get out" for some actions which cannot be achieved more directly. That's all. Which is why example programs are provided, and sources for those, and even the source for the Library providing the C interface to FSUIPC. There's also the utility program FSInterrogate which is provided so you can investigate the offsets and see how things work. Regaerds Pete

In that case you have simply not enabled WideServer -- it's an option on the main About tab of the FSUIPC options in FSX. Pete

You have to write your own driver program, interfacing to FSUIPC as described in the FSUIPC SDK and supported by the various language packages therein. You seem to misunderstand FSUIPC's function. FSUIPC is not a hardware driver program and contains no direct support for serial, USB, parallel or any other sorts of devices. Therefore there is no "protocol" defined. FSUIPC provides an interface for programs to get information in and out of FS. That's it. You have to program the rest in any way you like. FS itself already contains such controls. There's no strings because there's no protocol. Those numbers are Control Numbers which can be written to FSUIPC offset 3110 to get FSUIPC to invoke the appropriate FS controls. Please download and study the FSUIPC SDK. There's a complete list of supported offsets contained therein. Apart from the list of additional controls added by FSUIPC (those in the 1000 - 5000 range, etc), which are listed in the Advanced Users manual, there are many hundreds already built into FS and listed in the "List of FSxxxx contorls" you will find installed alongside that document. These numbers are the same as used by FS internally, and assigned to buttons and keypresses as recorded in the FSUIPC INI file when assigned in FSUIPC's menus. "Requests" to read and write FSUIPC offsets are made using the API (Application Programming Interface) defined for it in the SDK. It involves opening a connection, queuing read and write requests, then calling a function to process them. There are examples there, in the SDK. (BTW how is it you found out about offset 034E but found nothing about how to read and write offsets?) Regards Pete

You have the button assigned in more than one place, then -- probably in FS as well as in FSUIPC. You must always ensure you are only programming each button and axis is one place. And if it is continuing to operate with your finger off then it sounds like you have a broken button. Have you tried referring to FS documentation, or Help, as that is likely where you have the problem? FSUIPC will not send any commands to FS unless you've programmed it to, which is pretty unlikely if all you've done is used flap inc and flap dec. You said 4-way button. What are the other 2 ways programmed to do? Are you sure it isn't just those interfering? Perhaps you mean the hat, which is a "POV", giving 8 button numbers in FSUIPC and also an Axis which you can program in FSUIPC4 or FSX. Check your FSX assignments. You probably have the POV set to select views or pan them. If you assign in FSUIPC you must ensure you unassign in FS. If you assign it as a set of buttons in FSUIPC you shouldn't also assign it as an axis in either FSUIPC or FS. Regards Pete

You can use the Lua gfd library to send stuff to GoFlight displays. It's up to you to program whether it only does this when the autopilot is enabled. Sorry, I don't understand any of that. In fact, reading back a lot, I think i might have been misunderstanding much of what you are trying to say. What is your native language? Do you think you might be able to write in your native language and get it translated into English by someone else, or maybe a good translation program? I think we might understand more then. Pete

If you mean FSUIPC, yes. FSUIPC3 works with all versions of FS from FS98 to FS2004, whilst FSUIPC4 works with FSX and ESP. Why not simply install it and check the User Guide? It explains exactly what you get if you purchase it. I've no idea what EFB has to do with it. That's nothing to do with having a registered FSUIPC. You can buy WideFS if you want to run FSUIPC-interfacing applications on a Networked computer. Unless you know you want to I wouldn't worry about it. And you don't have to buy FSUIPC as well if you don't need its facilities. I've no idea about "UVAAcars" as I've never heard of it. You need to decide what you want to run and where, and also find out what needs FSUIPC and what doesn't. I can't tell you about all the programs there are out there I'm afraid. Pete