Pete Dowson

I am sure that EZDOK does not use FSUIPC, and FSUIPC most certainly has nothing to do with EZDOK. You need the EZDOK support forum. Furthermore, as your FSUIPC is not even registered it is really not doing anything except using SimConnect to populate its offsets. These are all data requests made during initialisation, and then left to SimConnect yo supply updated data as it occurs. FSUIPC may also be servicing other applications, if you have any. I suppose it is vaguely possible that other applications interact with EZDOK. One thing I do notice is that your P3D is being allowed to run at an unnecessarily high average of 144 fps. I'm wondering if this is simply not allowing any time or processor power for EZDOK (or anything else) to do much. Try limiting the frame rate -- at least to your screen's refresh rate, lke 60. Pete

The display library is for Wideclient loaded Lua, not FSUIPC. The FSUIPC display facility is ipc.display and the example for that is "display vals.lua". The fact that MyDisplay.lua is for WideClient only is clearly stated in the list of Lua examples provided, in the Lua plug-ins documentation! Pete

Great news! Thank you. This is wehat I needed to know before releasing 4.969g as 4.97 tomorrow. Thank you. I will check those so that I can confirm that the intended action has indeed been carried out correctly. Pete

Test with a default aircraft. If that's okay, then it is likely that the PMDG doesn't like the way throttles are being controlled. Mostly PMDG aircraft coding takes the throttle input at a higher level, the same as FSUIPC does. But if you assign in FSUIPC "direct to FSUIPC calibration" then this bypasses the PMDG throttle input, and its interception will use a different value, causing a conflict much like double assignment. Even if you assign to the FS controls "Axis throttleX set" and then calibrate, the same problem occurs. Generally the only safe way to do it with those aircraft is to assign to those "Axis" controls and NOT calibrate in FSUIPC at all. Pete

Sounds very much like multiple assignment. If you assign in FSUIPC make sure you have controllers disabled in P3D. not simply de-assigned, but disabled. This is normal. Youcan have generic button assignments as well as profile specific ones. It has ALWAYS been this way. The idea is to have general things, like Gear, assigned generically/globally, and only assign specific things for specific profiles. It also applies to key presses. It would have been nice to do this for axis assignments and calibrations, but unlike buttons and keys, axes are always active so it could not be like that for those. The version number of FSUIPC is so easy to see I don't understand why folks rarely tell methis essential information without me asking. And before posting here you should ALWAYS check the Download Links subforum (updated modules folder) for the latest version and interim updates. Pete

Yes, and I was still waiting for the logging I asked for. Also I ALWAYS need the FSUIPC4.Joyscan.csv file, which tells me in compact form exactly what the joystick scanner did. Also please try this version, which is the Release Candidate for 4.70 which I am hoping to release tomorrow. I you could test it soon and show me both the Log (with that extra logging option enabled still, as you have now), AND the joyscan file -- whether it works or not, it would be very useful to me, please. FSUIPC4969g.zip Pete

Actually the last question in your post was "Do I need to buy a new license for Version 5 ?" I was very busy at the time so just answered the obvious final query. Pete

Did you already buy the FSUIPC5 Registration? As I confirmed to you in my first reply, you need to buy it. Your FSUIPC4 key wll not work. Pete

No need to look at your program to answer your question. The ipc.sleep command is actually documented, thus: "ipc.sleep(msecs) Suspends execution of the plug-in for the given number of milliseconds, allowing other threads to operate with less hindrance." So 1000 is 1000 milliseconds = 1 second. You really need to use the FSUIPC Lua Library documentation as a reference for such questions. The function actually uses the Windows function Sleep. It guarantees that much delay -- but that's a minimum, as other loading on the same PC may delay it a little before the thread regains control. There's no guarantee of any time except it won't be less than what you specify. If you want to check how long it was just use the ipc.elapsedtime before and after to measure it. Pete

PLEASE ALWAYS POST SUPPORT QUESTIONS TO THE SUPPORT FORUM!!! Main thing to do is change the AutoAssignLetters=No to Yes, so that letters are used in assignments, not numerical IDs which can change. I also see that the Throttle has two IDs associated with it: 0=Saitek Pro Flight X-56 Rhino Throttle0.GUID={35FAD9F0-E63B-11E6-8004-444553540000}3=Saitek Pro Flight X-56 Rhino Throttle3.GUID={35FA3DB0-E63B-11E6-8003-444553540000} yet the Stick is missing. This looks like one of the usual Registry muck ups which occur a lot with Saitek devices, especially if you install their software which seems to often make such a mess. Can you please do this: 1. Download and install the current interim FSUIPC4 update, 4.969d, from the Download Links subforum 2. Add these lines to the [General] section of the FSUIPC4.INI file: Debug=Please LogExtras=x200000 Then run P3d. Keep it brief. After clsoing it down, show me the FSUIPC5.LOG file (always more important than the INI file), and the FSUIPC4.Joyscan.csv file, both from the modules folder. I'll check those files to see if there's anything FSUIPC can do automatically, but it might be a good idea anyway to uninstall the X-56 completely, unplug both parts, uninstall it in the Windows Device Manager (including drivers), and plug them back in and re-boot the system so they install properly as normal devices. Pete

Yes. And please ALWAYS post support questions to the Support Froum! Pete

What variables are you talking about, and why is it you expect them to be "reset"? If you mean values which are from Prepar3D values, naturally they won't be "reset" just because you restart Lua plug-ins. If you mean variables local to you plug-ins, those will be "nil" (same as undefined) until you set them with a value. If you mean the Global variable facilities in Lua, those, as must surely be clear from their name, are Global. They are for communication between separate plug-ins which may not even be running as the same time -- they are also used for plug-ins which run sequentially, perhaps to retain status details of external hardware. If you are using those and you want them to start with specific values, then you have to set those values. But note that they don't "belong" to your plug-ins. Any plug-in using the same names will access the same variables. Pete

Sorry, but I would need to know a lot more before I can answer that. Have you assigned both the on and off positions ("press" and "release" in FSUIPC assignments). If not that is probably the reason. Otherwise, since I don't use PMDG aircraft myself, if you are talking about "custom control" numbers derived from the PMDG SDK files, then you'd probably be better off asking in a PMDG forum. However, there are a number of threads about PMDG aircraft in the User Contributions subforum, some of which have either assignment lists of Lua plug-ins using those controls, so you might find what you need there. Pete

With the same (actually out of date) version of FSUIPC, and the same "old" version of the PMDG, and the same programming for macros you did before, obviously it HAS to work the same -- or you have something wrong, or something has changed you've not thought about. The most likely reason for your problem with the old version of the NGX is that you didn't full uninstsll the new one before installing the old one. It puts bits all over the place, and the most relevant parts are the Guages in the Gauges folder, and the DLL's. wherever it places those. There re also entries in files like DLL.XML in your user Appdata\Roaming folder. Near the end there is a complete list of controls which can be used. They are all defined by a suggestive name, and equated to a value which is the BASE (another name) plue a normal decimal number. At the beginning pof the list the value of that "base" number is defined. All you need to do is add one to the other to arrive a a number which represents that control. You assign to "<custom control> in FSUIPC and use that number. If you and your father still don't understand this quite simple operation, either paste an example of what you want to do, and find a seemingly approperiate entry in that list, and we'll take it slowy from there. Alternatively why not ask in the PMDG support forums. I don't use any PMDG aircraft myslef and don't have easy access to the file itself. P3D3 and P3D4 9and for that matter P3D2, P3D1 and FSX) are all entirely separate and there's no possible interaction between any copies of FSUIPC4 installed in any or all of those, or with FSUIPC5 in P3D4 which isn't evben the same product! That is out of date and I ask you to update before posting again, please. Pete

I think, as I said, you need to provide more than just the code. what is going on, and where? Where is it going wrong? That's the point. The code as presented is just that, very obscure sequences of lines which mean nothing to me and I suspect also nothing to other readers. You need to do a bit more work is assisting those you hope to assist you. Yes, and that is in the loop which never ends. So it will be repeated over and over if the conditions apply. And each time it is restarted, the previous one, if still running, will be terminated and started again. The one you are starting will end when it has done the little it has to do. There's nothing to stop it. So, what is stopping your loop starting it over and over? Pete

Please ALWAYS post Support questions to the Support Forum. Yours is certainly not a "Contribution" of something useful for all to share, yet you posted it in the "User Contributions" subforum. You are lucky I noticed it! You don't need to be a programmer. If you don't understand how to work out a "custom control" number, just ask! It is far FAR easier, and more reliable, to use the tools PMDG have provided than using the unwieldy Mouse Macro system, which was only invented in desperation at those add-on makers who don't provide ways of using buttons or even keys to operate their on-screen switches. And Mouse Macros rarely work on most newer add-on aircraft. If you update your aircraft you need to scrap all of your old mouse macros for it and make new ones. They are completely dependenty on exact memory locations in the add-on to work. just a small change in an aircraft can stop them working. FSUIPC checks that the memory it would otherwise jump to is still valid and ifg not will simply not be able to do anything (which is far better than causing a crash). That sounds like PMDG, like most others, have at last abandoned the old FS2002 way of making their gauges and adopted new methods. I expect this is to be able to use the improvements with recent P3D versions and of course P3D4 in particular. So, now it is time to program your switches and buttons the better way, using custom controls! Pete

The logging you need is the Debug/Trace one, in the Logging Tab, on the left. That gives you line by line trace, by line number, and also variable values when they change. But you seemed to have posted full sources with no pointers as to what is done where or what you think is really going wrong. If it is your code you should understand what it is doing. Therefore you must have an idea where in all that code things are not going the way you expect. By posting as you did with only a vague description of a problem which i don't even understand it definitely seemed as if you expected me to analyse your work, which is why i said what i did. I am not out to hurt or insult you as you seem to think! You didn't even say how either of those Lua plug-ins are started (and there doesn't appear to be a "runlua" in either of them). One of them (FlightLog) loops forever or until its flag 0 is set, and the other simply does a series of things then exits. Well, it is nice to be treated as a "last resort" I must say! :-( I tried to help by pointing out that there are lots of facilities to help you work out what is going on. When you've done that and you think it is a problem in the Lua interpreter or FSUIPC's implementation then by all means show me why and I'll attend to it. But you need to narrow things down a lot first! As well as the built-in trace mechanisms I often simply insert "ipc.log" lines to log important information in different places, or just to indicate the code has reached this point. I make these conditional on a variable like "debug", declared at the start, being set to true or false, so I can leave them in and simply turn them on or off as needed. There are therefore some very good ways of determining the sequence and results. Pete

Oh, that's very odd. not released yet? But it was available to Beta testers as long ago as 14th April! What on Earth are L-M playing at? So I am forced to uninstall 3.4.23 and install an older one so i can perform tests! Grrr. I'm asking L-M about this directly! Pete

Assuming your "subscript" is being started by an ipc.runlua command, then it starts it its own thread and is completely independent or how it started. there's no "parent-child" relationship going on. Starting a plug-in in this way it identical to starting it directly, via an assignment or an entry in a macro or [Auto] section in the FSUIPC INI file. So your "subscript" is terminating itself for some reason. I'm sorry, but I really am not going to study your Lua code and debug it for you myself. I suggest you use either the debug/trace facilities provided to determine what is happening, or at least add some logging to work it out. Pete

Well, FSUIPC isn't interfering at all with that set to 0, so it is verty odd. are you sure you aren't runing something else which depends on FSUIPC and so doesn't do the sae things if FSUIPC isn't running? The other way to deal with specific selections for door or pushback is to assign the key press for Toggle Aircraft Exit, or Toggle Pushback, in FSUIPc assignments and enter the number as the parameter (1, 2, 3 or 4 -- you can't do combinations that way). One thing I notice from your log is that you aren't using the current version of P3Dv3 -- yours is 3.4.22.19868. I am using 3.4.23.20420. Any reason for not applying the last fix release? It could be significant. It's always best to keep up to date because things do get fixed. Pete

When "sending to FS" it is just like assigning in FS/P3D. Same controls as assigned there, and they reach the sim in exactly the same way. Doing this means FSUIPC has to intercept the control, again, within FS for calibration, then send it back again -- but at a lower level so a loop doesn't occur. Sending direct to FSUI{C's calibration bypasses a lot of this. The reason differences can arise are because different add-on aircraft do things differently. The PMDG aircraft actually do their own interception of throttle inputs (for sure) and very likely other controls like spoilers. This usually means that throttles, in particular, have to be sent to FS, and not calibrated, because otherwise two different values might then eventually arrive in the sim's simulation level engine. That produces conflicts which may be observed as unwanted movements of the throttles. If you don't see this then probably your calibrated throttle inputs correlate well with what the aircraft code modules are doing with them. Pete

It is really strange that it doesn't work for some folks. The key sequences work perfectly here. In case it is a problem with the SimConnect macro facility which enabled FSUIPC to make sure the keypresses are associated with the Door or Pushback command, you can switch FSUIPC's actions there by setting the "Time for select" to 0. I know you said that you cannot seem to change that, but that does not make sense to me either. It is a simple parameter like all the others. But you can of course just edit it in the FSUIPC5.INI file before running P3D. TimeForSelect=4 in the [General] section. Change it to 0. Pete

Left and right aileron is a single axis, so there's no difference as far as assgnment and recognition goes. So either your yoke has become defective, or you have lost calibration. Do the "IN" numbers in the Axis assignments tab vary over the whole movement of the stick? If so, try recalibrating it. Sorry, do you mean the yoke position was such as to make LNAV diengage? That would imply either a very (very) bad jitter, or a complete lack of proper central (neutral zone) calibration. That is called "spiking" and is a sign of dirt in the control, or possibly a dead zone on the potentiometer. When the 'wiper' hits that the impedance goes very high very suddenly and the reading is converted into one extreme or the other. There are spike elimination options in the Miscellaneous tab which you could try, or you could attempt to clean the innards of your control (electrical switch cleaner is very good). Otherwise it sounds time for replacement. CH do offer servicing for their devices, if you can find one of their depots or agents which do such things. I remember when I had a CH yoke and the action got very stiff I took it down to a place in Shrewsbury which cleaned it up and replaced the "collar", for a nominal fee. Pete

Not before assigning, before calibration. You need to assign first of course. Pete

Thanks. Yes, it now skips over those rogue Registry entries I mentioned. Pete