Pete Dowson

Okay. Having looked it all over there are some conclusions. First is that those __gc functions are called regularly in any case by the Lua interpreter. They will also be called by the "lua_close" function when it finally tidies up and frees the main Lua stack memory. Second is that FSUIPC cannot call "lua_close" from its main thread. It has to be called from within the thread in which the Lua program to be terminated is running. The only way FSUIPC's thread can get that to happen in a running or looping or stuck Lua thread is to set a flag in the main Lua state structure, and change the interpreter to check that flag between every statement or block, aborting the statement or block is it is set. This should make it ultimately ignore all the following statements and blocks till it exits and tidies of its own accord. Unless you have any better ideas, this is what I am doing right now. I still need to place a time limit on this before forcibly throwing the thread off. Since the interpreter will be rushing through the statements like a dose of salts, ignore every one, I think 10 mSecs should be sufficient (elapsed) time for even the most complex programs. What do you think? I will also implement that event.terminate facility, which will be given longer. not sure how much longer at present (maybe 30 mSecs?). If such an event function is provided, it will of course be called before the "abort" method mentioned above is used. Regards Pete

Assuming you mean WideClient (WideFS7 is really the server part of FSUIPC4) that wouldn't make any difference. There was nothing wrong with the last install except that you weren't actually running the program at all (hence no log), and the INI file had not been configured to do what you want! You not only need to install WideClient on the client PC, but you have to edit the INI file in order to tell it what to do when it sees your KeySend. All you've posted are files showing that at least this time you actualy rann WideClient, but that you still have not done anything to make your PTT work at all. It isn't surprising, is it, when WideClient has no idea what you want to do because you've not told it anything at all? Regards Pete

I have the GoFlight SDK version 2, which should cover the WP6 but only mentions "GF-WCP". I assume that must be the same device? 6 buttons and 6 indicators, each of which can be set to almost any colour? I just haven't had time to do it yet, and it didn't seem urgent because until now no one even asked. I'll raise its priority a bit now. :-) HOWEVER, I've looked through the information I have for the GF-WCP and I don't think it can be the same device as the WP6. So i cannot start on it yet. I've written to my GoFlight software contact to see what the story is. Since there is no code in FSUIPC at all for the WP6 at present I'm not sure why you would expect it to even recognise it? I've no idea why it would blink, except possibly FSUIPC switching all the other GF devices off and on makes the USB power dip? FSUIPC doesn't recognise the WP6 and cannot possibly be talking to it. Pete

I'll annotate the code to show where you are going wrong. [bTW, why, in all your examples, do you have "if ipcPARAM == 0 then"? What about other parameter values? If you aren't using the parameter, why bother to test it? if ipcPARAM == 0 then LVarSet = "L:MCP_HDG_Disp" LVarGet = ipc.readLvar(LVarSet) if LVarGet &lt;= 359 then ipc.writeLvar(LVarSet, LVarGet+1) else if LVarGet &lt;= 359 then -- This will NEVER be true, because if it was you'd be doing the part above instead, don't you see? ipc.writeLvar(LVarSet, LVarGet-359) -- So this code is never used ipc.readLvar("L:MCP_HDG_Disp")-- Nor this (and why read it again here when you've just written it? Makes no sense! end end ipc.sleep(50) -- Why this sleep? end Surely you ALWAYS want to add 1, and then simply see if the result is >= 360 and if set subtract 360. so LVarSet = "L:MCP_HDG_Disp" LVarGet = ipc.readLvar(LVarSet) + 1 if LVarGet &gt;= 360 then LVarGet = LVarGet -360 end ipc.writeLvar(LVarSet, LVarGet) The "fast increase" version is exactly the same except adding 10. With a decrease you'd check for < 0 and if so add 360. This is simple logic more than programming. To check your work just pretend you are the computer and see what happens to values line by line. This is called "dry running". Pete

Sorry, I don't really know, not knowing either SIOC or the Wilco 737, but "mouse macros" are only a way of making an assignment which calls the code inside a gauge which would be called by the mouse click on the switch on screen. Nothing else. There is nothing to read back about what was changed. Depending on how the gauge is written -- whether there's a Software Development Kit or user interface provided by the authors, as for the Level D 767 -- it could be a matter of hacking into the code to find out where to get the data from, or, possibly, finding if they used local gauge variables (L:Vars. Though I suspect that if mouse macros work they won't be using L:Vars as those tend to be associated with XML gauges, not C/C++ ones. If all you mean is to do something else at the same time as using the mouse macro, then you can of course have the one button or switch executing both the macro and any other assignments, but you'd need to edit the INI file to get multiple actions. Are you sure that aircraft doesn't use the default FS A/T switch? If it does then just read the offset for it in FSUIPC. Regards Pete

Version 2 had no key file and no registration. It was free. It's main purpose was to allow applications to interface to FS. Most of the later features, for version 3, those in the Options dialogue, were added as user benefits for paying for it when I was forced by circumstances to start charging for it. I honestly can't remember what was supported then and what wasn't. Didn't you find any documentation to go with it? All I have is the History document which you'll find was installed with FSUIPC 3.99. In any case, FSUIPC never provided any sensitivity facilities -- that was always a slider in FS. Not sure about CFS1. Unless you mean the "slopes" facilities, but they were certainly a much later addition. Regards Pete

There's probably something that's changed in all these years that's somehow made it incompatible. I try to maintain compatibility with everything FS-like since FS98, but I have only been able to re-test in FS2002 and FS2004 (and of course FSX, ESP and Prepar3D) for several years. I can't support such old programs now. But try deleting the INI file and let it resort to defaults. You might be calling upon something in the INI which isn't accepted. You could also try without the KEY file initially, just to see if it carries on running in complete unregistered default mode -- which is how the original version for CFS1 would have run. Otherwise all I can think of that maybe if you search on the Internet you might find a Version 1 or 2 of FSUIPC which should surely work, at least as good as they did back then. But I can't really help with that. Sorry. Regards Pete

Yes, there's a very good chance that will fix it. When you uninstalled FSX in order to reinstall it, it wouldn't have uninstalled the newer SimConnects. That's one of FSX's "uninstall" problems. Regards Pete

Okay. Please remind me during the week and I'll try to hook it back up. Unfortunately I do not have either Airbus X or CaptainSim 757, so I just don't know. If you have a question on driving the GoFlight gear I can maybe answer, but I don't know what the aircraft are doing. Sorry. so, have you experimented with those? Can you read them as well? Why not just choose the correct minimum and maximum values and checking those? Or simply never turn the dial beyond what is reasonable? I don't know what you mean by "have a noter that would increase 1000ft", but if you want to stoop "LVarSet" going below zero, whay not just check for it. In other words: if LVarGet &gt;= 100 then ipc.writeLvar(LVarSet, LVarGet-100) end Regards Pete

FSUIPC4 never closes FSX on its own. You have something else going on, maybe with another add-on. However, there is certainly a serious problem, as illustrated by this entry in the FSUIPC log: This implies that you have a mis-installed FSX. This part of the Install log shows what it is: So, whilst you have the original, unmodified, version of FSX installed, you also have all three versions of SimConnect -- including the latest, the one installed with SP2 or Acceleration. Naturally FSUIPC wants to use the latest version as that provides all the best facilities it uses, and is relatively bug-free. I don't know how you got FSX into such a state, but you either need to somehow uninstall SimConnect SP1 and SP2 (and I don't know how without reinstalling Windows), or install FSX updates SP1 and SP2 (or Acceleration). Regards Pete

Well, I expect the minimum change is about 64, or even more, so that's the same a not having a null zone. If you are over-controlling try using a slope with a flattened centre. Taxiing straight is something learned with practice. Both brakes together are via the "." key on the keyboard. If you want to lose the ability to use toe brakes for differential braking (better cornering), the I suppose you could assign both toe brake axes to both left and right brakes. The axis assignments facility does allow up to 4 assignments to each axis, after all. But it is a little wasteful of having toe brakes in the first place. Regards Pete

What "your device also light up whit out driver by pressing APP button (the led + led at A/T would light up)?". I asked if it was serious because I can't imagine what circumstances you'd care what the hardware does when only powered and not connected to any software. Perhaps you could explain? So, is this a question I can answer without any driver for the MCP Pro? What exactly are you asking? I don't know anything about the Captainsim 757 I'm afraid. Ah, perhaps "without driver" you mean only "without the GoFlight driver, GFDevFSX or whatever? I have never used any Go Flight drivers, only GFDev.DLL to allow FSUIPC to access the devices. Could you please formulate a question that I can understand and answer, bearing in mind I do not have your aircraft and know nothing about it? And this is the code to do what, precisely? just reduce the altitude by 100? How is this related to the MCP Pro question? Regards Pete

That's the default INI file. If you've not added the required parameters to send your keypress it cannot do it! In that case you've never even run WideClient, as it ALWAYS makes a log file when run! Regards Pete

I cannot supply old versions, and I cannot support you if you find one. Any add-on software needing recent additions will also not work. I'm afraid Windows 2000 is far too old to support most of the software developments of the last 10 years. Regards Pete

No. What will be happening is that whichever input is providing that X axis is jittering like crazy and preventing any other axes being seen. Apart from getting the hardware fixed (cleaned or better power supply), there are two ways to deal with it: 1. Find a parking position of the lever (or yoke?) which doesn't produce jitter or 2. Use the facility provided in FSUIPC specifically to deal with this difficulty -- the "ignore" button. The documentation covers it. The ignore axis facility just ignores then on which is interfering, until you return to the assignments tab or clear the ignores. Regards Pete

When you say "NUL zone" do you mean the centre zone, around the area where the pedals go when you take your feet off? That's what you need to get right. I see from your INI file that you have Filtering enabled on the rudder. Why? That is generally not advised unless you have a really badly behaved set of pedals. Try turning it off. Do you have the FS realism set high? If so, check some of the sliders. most of them need to be near centre for realistic torque and ground effects. You'll ALWAYS need to use rudder to keep staright when taxiing, though, and the twisting effect is higher with more throttle, so keep the throttle low. Also take care of side winds by ailerons into wind. Steering tiller is nose wheel control, but FS uses rudder input for both in any case. If you have a steering tiller, separate from your pedals, you can use that with different calibration to suite ground steering, and FSUIPC will balance the two depending on airspeed. Regards Pete

I don't know. The MCP Pro isn't connected at present. If this is a serious question, remind me next week some time and I'll try connecting it, if i can find it in all this junk ... <G> (sorry, things are a bit of a mess here after some serious upgrading of my cockpit). Pete

I didn't need the FSUIPC log, but I need to see the WideClient log, please, and also the [buttons] section of the INI which has your Keysend assigned, and the WideClient INI. Rather than place links to uploaded files, you can paste them into your messages here. It would be less work for both of us. Attachments are suitable for long files, or non-text files, but otherwise just paste them in. If you like you can use the "code" quotes (the <> button above) to delineate them and maintain their formatting. Oh, BTW, first check that you set "UseSendInput=Yes" for WideClient. As stated in the WideFS technical guide, in the section on TeamSpeak, this appears to be needed for that program. Regards Pete

You posted your support question in the FAQ subforum, which is the place where I give answers to "Frequently Asked Questions". I've moved it for you into the proper place, the Support Forum. Lucky I noticed it -- it is easy to miss new posts in the subforums. You've not provided me with any relevant information I'm afraid. To start with you've not even said whether the client is connecting to the server okay. I also need version numbers of FSUIPC4 and WideClient, Log files for WideServer and Wideclient, and details of the parameters you've entered to use KeySend. Regards Pete

This isn't FSUIPC4 crashing or displaying that message, but it is a bug in SimConnect which only occurs during first time loading, and more usually when there are several programs being loaded at the same time. It's to do with timing in the way SimConnect operates the Windows "trust" system for third party programs. FSUIPC4 is not even getting loaded -- SimConnect is crashing when it goes to load it and verify its signature via the Windows trust system. Please see the thread on this subject in the FAQ subforum. There are number of hints there for getting around the problem. Another one, in your case with FSCopilot and FSInn also installed, is to make a safe copy of the DLL.XML and EXE.XML files, then install FSUIPC4 again (just re-run the installer) and run FSX at least once, maybe more times, till it is clear FSUIPC4 is okay. Then rename the original DLL.XML and EXE.XML files back. Really it is best to only ever install one thing at a time, get it working, then exit FS and install the next. That way clashes in SimConnect are less likely. Regards Pete

I don't think there are any LEDs 5 and 6. There are 17 LEDs and I think they are numbered 0, 1, 2 ,3, 4, 7, 9, 10, 14, 15, 16, 17, 18, 19, 20, 21 and 23. but I'm not sure. The way to find out is to try each possible number from 0 to 31 in turn and see which one lights for which number. Regards Pete

You'd need to decode the way SB4 uses its SimConnect "ClientData". I know how to read and write its data because I do this for the Mode switch, but since I don't have or use SB4, nor understand the use of those other things, I cannot decode the ClientData for them. You'd need to analyse its client data whilst switching the things which influence it. That sounds very complicated and I'm not sure I understand it. Why would the FMC integrate with ATC? And I thought ACARS, in real life, is something used by the airlines themselves, not ATC. Sorry, I don't understand this part. Are you asking me about how to program for VATSIM? I'm afraid I know nothing about any of the on-line flying side of FS. Regards Pete

They should also be okay in the FS Modules\DLL folder, because i add that to Windows search list for DLLs. This is where your Saitek and GD DLLs should go too. The Lua folder is for non-FSUIPC-loaded Lua files, i.e. those modules loaded by "Require" but not intended for FSUIPC loading. The folder I add to the Windows DLL search list is the modules\DLL folder. Note that the "SetDllDirectory" facility I am using only allows one such addition, else I would have added both. Each time it is used it replaces the last named one. Also note that the earliest version of Windows which supports this function is XP + SP1. Regards Pete

But if the garbage collector only deals with allocated memory, not other system resources like files and devices, then I don't think it is needed in this environment, because the thread is killed along with all of its allocated memory. It isn't like a normal Lua environment where the Lua program is part of the main program. the Lua threads are like little processes. I will double check to make sure there are no memory leaks, of course I assume this means calling some Lua routine from C? I'll check. Next week. Any information would be useful. I'm a tad confused at present I must admit. Regards Pete

But judging by your code and advice, you are most certainly a lot more "expert" than me in Lua. I think you misunderstood. the timeout to "exit" would start when FSUIPC sent the event to the program. It was an adjunct to what I had said just previously! What else could it mean? There's no point in just inserting a time out otherwise, of course,. Er, are the allocated objects simply all assigned memory sections? I think all of those are freed automatically when the thread is terminated. Are you seeing a gradual increase in memory use indicating some sort of memory leak? The whole stack system used by Lua is involved, all in allocated memory objects, not just items you allocate yourself later. I've not yet had time to look at the code, but as far as I understand the action should just be similar to that which occurs when exit() is executed? I thought the concern was more for system resources like devices and files which might have been opened by modules not directly being controlled by FSUIPC or the Lua interpreter, like DLLs. Sorry, no, not really. What is a "__gc" function? How is FSUIPC supposed to know about these so it can call them? I'm a bit lost in all of this, I must admit. I shall try to find some references to all of this in the Lua books I have. But I won't have time till next week. Regards Pete