Pete Dowson

It won't crash, it is just that it would be taking a lot more resources than it needs. You might not notice until you fly in a busy or complicated place and lose performance. Just adjust it low enough to do the job, and no lower. Pete

But I told you the Sleep might be too long and to try changing that till it responds okay for you. Just wrecking the program entirely isn't the right way to carry on. You do your own thing, to please yourself, but don't keep coming here to get my approval for things which are wrong. I keep advising you, showing you, explaining things, but you choose to ignore me. Please carry on, but don't ask me anything else now. it is taking too long. I have other things to do. Regards Pete

No. I didn't notice this before, sorry, but WHY have you put "" around the numerical comparisons, in these lines? if ("alt ~= prevalt") then if ("hdg ~= prevhdg") then if ("speed ~= prevspeed") then That simply makes the condition always true, because the strings are always strings!!!! Those lines are meant to be comparing two numbers, as I carefully explained. The "" turns them into strings! They might as well all be if ("THIS IS GARBAGE") then because that would give exactly the same result!!! What will happen is that the displays will be updated all of the time, whether they need to be or not. It makes many of the lines a waste of time. You are making far too many silly careless mistakes. Pete

You've not tested this evidently? The L:var names have "L:" at the beginning, as for the altitude one. You've missed it out! I've now looked at the full L:Var list for the AirbusX, and I would have thought the correct Heading value was in "AB_AP_HDG_Select" rather than the "Hist" one -- the Hist one sounds like one retained so it knows which way to turn? I attach a sorted list of all of the AirbusX L:Vars. Pete AirbusX Lvars.zip

If you include it in a message and use the "code" button to envelope it, it will be easily selectable by those who want to try it. There are two answers to that. First, the best way to use the special plug-in "ipcReady.lua" is to use it to start all of the different plug-ins you want to have running all of the time. So could could have your three separate ones, named say "GFMCP1.lua", "GFMCP2.lua" and "GFMCP3.lua", and in the ipcReady.lua you can simply have: ipc.runlua("GFMCP1") ipc.runlua("GFMCP2") ipc.runlua("GFMCP3") However, whilst this is a good idea for different things, with these it is very wasteful to do that. So just make the one plug in, putting all three actions in the same "whileend" loop. Not your three separate loops -- which cannot work because the first loop never ends (if it did it would stop updating its display, you see) -- but just the one loop, which I'll show later. First let's look at the mistakes you made. Let's look at your first example: prevshdg = -1 while true do prevhdg = hdg hdg = ipc.readLvar ("AB_AP_HDG_Select_hist") if ("hdg ~= prevspeed") then stringhdg = string.format("%03d", hdg) gfd.setDisplay(GFMCP,0,1,stringhdg) end end Several errors here, and aNONE of them are due to any lack of programming ability, but just sheer carelessness. You MUST (repeat MUST) be more careful. Just look: prevshdg = -1 Okay, you named the memory for your heading value "prevshdg". But then: prevhdg = hdg What is "prevhdg"? Do you think it does not matter that you spell it differently each time? The computer will NOT recognise "prevhdg" as the same as "prevshdg"! Don't you see this simple thing? This isn't about programming now, so there's no excuse! It is the same as you referring to "lau" instead of "Lua". you may well spell your name differently each time, and that may not matter to you. But computers are fussy! Also, what is the point of having a memory of the previous heading set to -1 initially if the very first thing you do is set it to something different? You don't seem to have looked at the example I did for you -- you have the lines in a different order! The order of lines in a program is VITALLY IMPORTANT. It is the order they will be executed. Like in a story, would you understand it if Chapter 2 came before Chapter 1? In this line hdg = ipc.readLvar ("AB_AP_HDG_Select_hist") where did you get "AB_AP_HDG_Select_hist" from? I'm not saying it is wrong, I haven't been through the L:Var log i made to check -- but did you? Then this line: if ("hdg ~= prevspeed") then Surely you can spot the error there? Is "prevspeed" supposed to be the memorised previous heading, the one you set to -1 initially? Three different names for the same value? That's four (4) definite errors in not many more lines, and all of them simply careless -- not a matter of programming but writing things without enough thought. I'm not going to lecture about this any more. If you do not take note of this I will not help any more. Okay? The other two are better, but in all three you are copying the new, changed value into the memory BEFORE you've read it, which is wrong. As in my original example i provided it should go in the conditional part, after you've updated the display, before the first 'end'. I failed to spot you got it wrong in your posting just after. Remember when I explained this? I said "I am using prevalt as a memory for the previously displayed altitude". So that is what it should be -- a memory of what you just displayed. I know it appears to work still the other way, but it is not logically correct and it is inefficient to do it as you have done -- and also it won't work if the initial value is 0 (because the initial alt is 0 too). Finally, as promised. To combine all three just group your three "xxxx = -1" statements at the start, before the "while" line, and then have just the one while .... end, with all three of the main parts inside, so: while 1 do xxx = ipc.readLvar ... if ... ... end xxx = ipc.readLvar ... if ... ... end xxx = ipc.readLvar ... if ... ... end ipc.sleep(500) end Finally, note that the 500 in the "sleep" will limit the display update rate to 2 per second. You might want to speed that up. A value of 50 would be 20 per second, but that's probably over the top. You could experiment, but I would say no lower than 100 (for 10 per second). Just remember there are 1000 milliseconds in a second. Regards Pete

Good. I'm glad you got it sorted out! Regards Pete

Always (I mean always) get things working with a default aircraft first. Assorted add-ons do things differently and may need special treatment. Seems you must be looking in the wrong place? The part of the INI file you showed indicates it detecting all three parts. If they are standard DirectInput devices it will see them all unless some other driver is preventing it. But as a self-confessed "noob" why are you jumping straight into the deep-end and doing away with FSX assignment? True, FSUIPC assignment gives more flexibility (eg different assignments for different aircraft), and allows assignments to things like reversers, not otherwise supported by FS, but for general controls there's nothing wrong with doing the assignments in FS and only the calibrations in FSUIPC. You would certainly need to assign in FSX then. That wouldn't stop calibration in FSUIPC. That indicates you have an assignment only for the generic Throttle, not for throttle 1 and throttle 2 separately. Sounds like you certainly have multiple assignments and are confusing yourself by the results. If you've been messing about assigning things in FSUIPC and have now gone back to assigning things in FS, best to make sure you have no similar but conflicting assignments in FSUIPC. Either find and delete the [Axes] section in the FSUIPC4.INI file, or, more simply, delete the FSUIPC4.INI file (it's in the FSX Modules folder) and start again. Of course. Just make up your mind where you want to assign things, then do it just in the one place. For simplicity, and since you want force feedback, just assign in FSX and calibrate in FSUIPC. Do NOT use the FSUIPC Axis assignments options. I think this is where you are getting mixed up. It must be one or the other, not both. FSUIPC cannot override FSX or vice versa, so they simply conflict. Regards Pete

No. I think it very very unlikely. From what I've read it will be a fairly closed, mostly web-based, very game-oriented program, with any potential add-ons, if any, only going through MS in a pretty tightly controlled setup which will cost too much for most amateur efforts. I hope I am wrong, but I am not expecting anything of interest to me at all, quite honestly. Regards Pete

There's no correlation. It's like comparing apples and opanges. They are different things. FSUIPC offsets are references to values, or repositories for values. FS controls are just numbers which get sent (or posted) to FS in order to action something. In other words offsets represent data whilst controls represent functions or actions. What do you actually mean by that? Sorry, I don't understand -- it doesn't make sense to me. There's no conversion. You can't really convert data into functions or vice versa (well, unless the data is a program, in which case the conversion is by a compiler -- but i don't think that's what you mean! ). Maybe you ought to work out what the real question is? You seem to be getting a bit lost on terminology. Regards Pete

It simply means set the value of a viariable called "prevalt" to -1. I am using prevalt as a memory for the previously display altitude, so we know when to change it. since -1 is not a possible MCP altitude, setting it initially to -1 will make sure we display the first value we get. Mo, we read that altitude into a different variable called "alt". That says "obey the following lines, up to 'end' if alt is not equal to prevalt". In other words it is where we test if the altitude has changed. We don't want to keep displaying the same value several times a second. It wastes time and may even make the display flicker. That simply converts the number we have in the 'alt' variable into a string of 5 decimal characters, with zero (0) padding on the left if needed. So 200 becomes "00200" and so on. Please, I recommend strongly that you follow the links in the Lua documents to the Lua website and learn a little bit more abouyt the Lua programming language. you don't need much, nothing complicated, just basics. Pete

There is no syntax except correct spelling which is ipcPARAM (not ipcParam). It is a global variable supplied to a Lua program, that's all. Regards Pete

All FSUIPC does with FS controls is send them to FS in exactly the same way as FS itself does, through its messaging system. There's absolutely no difference. I think those controls move between different view windows you may have opened with the View menu entry "New View". Is that what you are trying to do? S and shift+S are assigned in FS by default to the controls VIEW_MODE (65567) and VIEW_MODE_REV (65749). I think you are getting confused between different view windows and different view modes. If you are not sure what controls do what, simply enable FSUIPC's Event logging, then operate the control via the normal keyboard or FS button assignments, and view the result in the FSUIPC log file. You will see lines like this logged: 158062 *** EVENT: Cntrl= 65567 (0x0001001f), Param= 0 (0x00000000) VIEW_MODE Note that the names, like VIEW_MODE, used in FSUIPC are obtained from FS's "CONTROLS.DLL", and are the same as those used in its own CFG files. I knowe they aren't always self-explanatory, so checking is really the only sensible way. Regards Pete

Ah, sorry. Anotheer typo! I am getting careless, sorry. No, not ipc.writeLvar("L:AS_FADEC_0"), 4096 - (9 * ipcPARAM / 4), but ipc.writeLvar("L:AS_FADEC_0", 4096 - (9 * ipcPARAM / 4)) The parentheses enclose the parameters for the writeLvar call. I would have thought that you'd have been able to fix that, with all of your Lua experience? Pete

Okay. Thanks. The values I got seem to show a wider range than you found. I don't know why. I did try -32768 to +32768, which would obviously have been a lot easier, but using those extremes I couldn't get the throttles back to idle. Regards Pete

Ah, yes. Sorry. That message was my last before dashing out for a Table Tennis match and I made a silly error, which you should really have seen as soon as you got that error Message? Look, it says: which means line 5 of "ipcReady.lua" has an error, there's a missing ). Look at line 5: if (alt ~= prevalt then Don't you see that there's a ( and no )? Obviously the intention was for this to be if (alt ~= prevalt) then which will work, though it could equally be if alt ~= prevalt then as Lua doesn't need parentheses around conditions -- that's a C requirement and my habit, since I'm a C programmer. You will need to be able to find simple errors like these -- they won't be hard to find as the Error report tells you exactly where to look. Please note that I'm only showing you code snippets like this so that you can work out how to do them yourself. I'm not intending for you to simply copy them and use them, but to read them, and understand them. If you don't put such effort into it you will not finish what you need to make the MCP work with the Airbus X. Pete

There's no such thing as a "lau". Please get that right. You won't get anything else right if you cannot correct that one annoying thing. You need a Lua plug-in which is running continuously, in a loop, rwading the variable at intervals and writing it to the display when it changes. Something like prevalt = -1 while true do alt = ipc.readLvar ("L:AB_AP_ALT_Select") if (alt ~= prevalt then stringalt = string.format("%05d", alt) gfd.setDisplay(GFMCP,0,4,stringalt) prevalt = alt end ipc.sleep(500) end To make this run all the time you could save it as ipcReady.lua, which is run automatically when FS is ready to fly. Or you'd have to program a button or keypress to run it when you wanted to fly the AirbusX. You could then add the other MCP variables in the same way, in the same loop. Not sure what you are thinking in this proposal: What's XXXXX, what's 0123456789, where's the formatted string going, what is %05d doing as an extra parameter in setdisplay? Please read more carefully. Programming is an EXACT science, you can't make it up as you go along as you are doing. Stringing together bits of nonsense just won't work! THINK! You surely can't really be stupid if you can understand flying, and certainly not advanced aircraft like the Airbus. Pete

I think all of the displays on the MCP will only accept numeric values, so your "LN123" probably won't work. try "00123" for a 5 digit decimal display. Which parts are you still not understanding? Pete

Yes, it is 'no more available', because the menu system is controlled by SimConnect in FSX and ESP, not by the hacks I incorporated in FSUIPC3 and before. This is also why FSUIPC is in the AddOns menu not Modules. You'd have to hack into SimConnect code or data, it is built into FS. Regards Pete

No. why? That, as documented, displays stuff in a Window in your FS. Why do you want that? To display things on a Go-Flight device you use the Go-Flight functions, as listed for the gfd library. I already told you to use that. Why don't you read the documentation? Why not look at the examples? Pete

Maybe you aren't handling negatives with the normal integer. Any heading greater or equal to 180 will look negative with a signed variable. It's still valid. Just add 360 to the computed result if it is negative. Regards Pete

Further to this, by monitoring the L:vars (using the Lua plug-in provided for this, the one called "Log Lvars"), I see that, for instance, the MCP's altitude reading is obtainable by reading the L:var called "L:AB_AP_ALT_Select". So all you'd need to do is read that into a variable, say alt then create the decimal string you need to display by using using string.format("%05d", alt). Pete

I've changed the title of this new thread of yours to refer to Lua, not your "lau" which will only succeed in confusing folks. Please do try harder to spell proper names properly! So, you can read the section entitled "the Go-flight Device (gfd) Library", then. It comes after the Sound library and is currently the last section in the Lua Library Reference document. Okay, so you can look at that file too. It is an example of how to manipulate GF displays. I've no idea. Can you read the AirbusX autopilot values anywhere? It may be like the PMDG aircraft and not export them anywhere. Possibly they are readaable via L:vars, but you'd need to work that out. Try and see. You can't do any harm. As I already told you, mostly the GF displays are numbered either left to right or right to left. Oh dear. How many GF MCPs do you have? If only 1 the unit number will be 0. The second is 1 and so on. The id is the specific display number, as I already said. The text is what you want to display. It will be a number, won't it? You don't get altitudes reading "L:AB ...", and in any case the display probably won't take letters and the string is far too long for a 5 digit display!!! Please think things through a little more before posting. You are wasting both of our time! You need to read what is already available and think a little, please. I am getting the impression that all this is rather beyond you. I don't even know if what you want to do is possible. It wasn't for the PMDG 737 for instance, which is why folks had to use GF or special PMDG drivers. Pete

0580 is 4 BYTES long, not 4 bits. 4 bits can only accommodate values to 15. You have an error then. Assuming you really mean "bytes" not "bits", if you only read the first 2 bytes you will only get part of the fractional value of the heading. Please use the tools available to check your work. You can use logging and Monitoring in FSUIPC, and of course FSInterrogate. Regards Pete

You appended this query to an Announcement trying to help folks with hexadecimal and binary numbers. I've moved it. In future please start a normal new thread for a new subject. Please always read what you are appending to to ensure it is appropriate! There is no FSX "command" number 65000. They begin at 65536. 66000 is "Mixture4 incr small". All FSX control numbers are listed in the document entitled "List of FSX Controls" which is installed with FSUIPC4 in your Modules folder, in the section containing the FSUIPC documentation. The "setup" program (you mean installer I assume) does not list any controls whatsoever. Where are you looking? Regards Pete

Thanks to Guenseli for identifying the FADEC variables, I have a potentially useful solution to throttle assignments, especially those like PFC which cannot be assigned in FS. Note that this is all very much experimental at this stage. Feedback welcome. 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