Pete Dowson

My code imposes no limit -- it simply creates the Window and gives you a handle (the 'hwnd' in fact). So any limit is up to Windows: maybe 65535? It isn't one of those resources which my code keeps track of, so all those Windows still exist when your Lua closes unless you close the window first. Pete

There's actually no way to pass such a parameter with the event library -- the parameters passed are defined by the type of event, and in the case of the timer event it is the time in mSecs. The value of n is available inside the function because it is a "global" -- it is declared and set outside of any function. If it was only declared within a function then it would be local to that function and not seen outside. Pete

I moved this out of the FAQ subforum, where it won't be answered, to the correct place, the Support Forum. Please post questions here. What's "wideangle"? Do you mean WideFS (which is my program) or WidevieW, which isn't? What do you mean by "the area"? Do you mean on your PC, or on the Web? Have you lost your registration? If so you need to go to your account at Simmarket to retrieve it. FSUIPC and WideFS are both available from the usual sites -- www.schiratti.com/dowson, where it has been now for 15 years, and also in the Download Links subforum above. Next time you £clean up" your computer, I suggest you make some backups first! ;-) Pete

First off, you don't appear to be referring to the Lua library documentation at all. how can you possibly think “Alt_inc(n)" is the actual function name? The (n) part defines its parameters, it isn't part of the name! Surely you can see that "Alt_inc" is the name? There are plenty of examples provided in the package and a load also posted in the User Contributions subforum. I shouldn't need to have to code things for everyone. Just this once, but please try to do things for yourself next time. Why is "80" a guess? Isn't 80 what you wanted, as shown in your original? Surely you stated that n was determined by earlier code in your program, right? So assuming n has been determined, all you need after that is: function Alt_inc() ipc.control(65823, 77) ipc.control(65823) n = n-1 if n <= 0 then event.cancel("Alt_inc") end end event.timer(80, "Alt_inc") Pete

All assignments are done in the FSUIPC menu -- axes in the Axes tab, Buttons in the Buttons & Switches tab and Keys in the Keys tab. It is no different for throttles or trim than any other function you may wish to assign. The user guide explains it, and there are pictures to help. But if your aircraft won't work with default FSX assignments it is unlikely to be any better with FSUIPC assignments. Pete

Ah, so you aren't using FSUIPC! :???: So why are you writing your questions to this forum, which is support for FSUIPC? :???: FS = Flight simulator, of course. FSX = Flight simulator X. Have you never seen these abbreviations before? If you cannot use an add-on aircraft with FSX's own facilities then I'm afraid it is a bad or corrupted add-on. you either need to get support from the maker, or, maybe, try reinstalling it in case it is simply corrupted. Regards Pete

How do you mean? Change what FS settings? All I am saying is that if the Wilco aircraft cannot be operated correctly without FSUIPC, then there is something wrong with it. maybe it's a bad install? Unless you test it with FS as it is you cannot really know whether it's your FSUIPC settings which need to change. So you've not even assigned anything to operate throttles and trim? I don't understand why you'd assign to reversers first. Are you using different levers for reversers and assigning to FSUIPC's "direct to calibration" reverser controls? Without assigning throttles there's no other way, unless you mean button operation via "Throttle decrement" controls. Just obvious things, like are you assigning in FSUIPC, and if so what to? You seem to have answered that by saying you've only used it for reversers. So, until you assign throttles and trim how can you know whether it is okay or not? I'm not really clear why you are reporting here before doing anything? Regards Pete

Have you tried just using standard default FS settings? Are you trying to use FSUIPC? Best to test with normal default settings in FS first. For FSUIPC help, there's really not enough information here for me to advise. Regards Pete

Yes, all understood. Considering all three Registry entries pointed directly at your P3Dv2 installation, I would agree that the unwanted two were placed there by the migration tool you used. Evidently, whoever wrote it, thought best that to install FSX and P3Dv1 add-ons into P3Dv2 they would be fooled by these entries. Unfortunate that it also fools FSUIPC's installer, which is well aware of all three programs, into wanting to install into all three. However, the outcome is not fatal, it is just confusing. Regards Pete

Certainly not practical. Sorry. I was only thinking of the 4. Yes. Again, it just won't fit into my current code. Quite honestly I think you are trying to force things into a simple Lua provision which it isn't intended for not suitable for. you'd be better off doing it all as a simple VB.Net program, using the Paul Henty .Net interface to FSUIPC/WideFS. Pete

How many variations of text in the four positions are there? Maybe you could make a set of bitmaps with the right texts and colours, one for each possible display need, then display whichever bitmap is appropriate? Possibly 16 small bitmaps covers all conditions for the 4 indicators? Pete

You simply need to abort the FSX part of the installation -- i.e. press "Cancel". It is asking you to find FSX.EXE because your Registry still says it is installed. You cannot install for P3D in the FSX part of the installer's sequence! This shows that your FSX has not been properly uninstalled, or maybe that something else has re-added the FSX install data: Looking in registry for FSX install path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator\10.0 Parameter"SetupPath" ... >>> OK! FOUND FSX! <<< ... The path given by the Registry is the same as your P3Dv2! INSTALLATION FOR FSX: SetupPath="E:\Prepar3D v2\" which seems very strange. Maybe you've used some fiddle to get FSX programs installed into P3D? Actually, before both of those you would have seen this: Your FSX installation has not been found, even with your help. No changes have been made for this by this program The "cannot edit" and the DLL.XML alert messages are both for Prepar3D, not for Prepar3D version 2! Again, your Registry says you have FSX, Prepar3D (version 1) and Prepar3D version 2, all installed. Therefore the installer tries to install FSUIPC for all three of them. Look: Looking in registry for Prepar3D install path: HKEY_LOCAL_MACHINE\SOFTWARE\LockheedMartin\Prepar3D Parameter"SetupPath" ... >>> OK! FOUND Prepar3D! <<< ... and INSTALLATION FOR Prepar3D: SetupPath="E:\Prepar3D v2\" again, the same P3Dv2 path!!! But that registry entry is ONLY used for version 1 of P3D!!!! I don't know how you got the Registry into this mess, but it hasn't really done any harm except confuse you. Even then, if you actually read EXACTLY what the messages were saying you'd see that the only one you care about, P3D v2, was completed successfully -- something which is clearly shown in the log. You would have certainly got a message which you had to acknowledge that such installation was successful. Do you not believe it? Please, next time do take note of what is actually stated in the messages you see. The way Lockheed Martin have constructed things, "Prepar3D" paths refer to version 1. All the Registry and User Data and Flights folders have the v2 added. I think they did this so you could have v1 and v2 both installed and operational with different data files. Your having all three sims apparently installed (and in the same folder!) is strange and will continue to confuse you if you are not careful. Pete

The default flight is whichever flight is loaded initially, it isn't necessarily named "default". In your case it looks to still be the initially installed default flight, i.e. D:\FlightSim\FLIGHTS\OTHER\FLTSIM.FLT Ah, so it isn't just FSUIPC which is being clobbered! Seems either your FSX instalation is corrupted, or one or other of your add-ons is somehow managing to get SimConnect screwed up. All this: 133771 ### MENU: EV_MENU [15] received: dwMenuEvent=0, fInScanJoy=0, fInOptions=0 135659 ### MENU: EV_MENU [15] received: dwMenuEvent=15, fInScanJoy=0, fInOptions=0 143412 ### MENU: EV_MENU [15] received: dwMenuEvent=15, fInScanJoy=0, fInOptions=0 etc indicates that the menu entry is seen, but when SimConnect is requested to go into dialog mode, so that the dialogue can be displayed, it isn't responding at all. It may require a complete re-install of FSX, but first, in case it is one of the add-ons, I would suggest stopping them all running except FSUIPC, and see if that then works. Then add them back, one at a time. To do this you'll need to edit the DLL.XML and EXE.XML files, in the same folder as your FSX.CFG file. Regards Pete

The event system uses a function which is called when the event occurs. You don't use any loops. You simply cancel the event when your value of n reaches zero. Pete

I received another log from you by email, but I'm not sure what I'm looking at. It doesn't close -- why not? Please ALWAYS close FS before getting the Log. What actions did you take up until the point you decided to get the Log whilst FS was still running? What exactly did you do, step-by-step, and what did you see? I think we now need to go to the next stage (exactly as in the thread you referenced). i.e. Edit the FSUIPC4.INI file and set Debug=Please (if you don't already have that there) LogExtras=x8001 You can delete the TestOptions line if that's still there. Run FSX and try the FSUIPC menu, how ever many times. If or when it doesn't work, say, twice, show me the Log file. no need to ZIP and email it, it won't be too long. Paste it here. These are the log lines you should get for every entry into the Menu and out again: 231396 ### MENU: EV_MENU [15] received: dwMenuEvent=0, fInScanJoy=0, fInOptions=0 231412 Ready Flags: Ready-To-Fly=Y, In Menu=Y, In Dlg=Y 231412 ### MENU: ST_DLGMODE received, stt->dwInteger=1, dwMenuEvent=15 231412 ### MENU: ST_DLGMODE: fInScanJoy=0, fInOptions=0 << the menu is open here (not a log line!) >> 233642 ### MENU: PropertySheet call returned 1 233689 ### MENU: ST_DLGMODE: ending dialog mode 234048 Ready Flags: Ready-To-Fly=Y, In Menu=N, In Dlg=N In the log you sent me you did get this line: 310707 Ready Flags: Ready-To-Fly=Y, In Menu=Y, In Dlg=Y which means FSUIPC thought it was actually in the dialogue -- but there was no line showing it ever exited, as there surely must have been if you were able to close FSX! Incidentally, if you read right though the original thread you will see that the problem turned out to be a corrupt FLT or WX file, or maybe the wxstationlist.bin. Here is the last useful report in that thread: Have you tried this yet? Regards Pete

Don't you need it compiled -- or is a "BAS" file ready executable? There's really no problem using anything in the SDK -- that's what it is for. Even those parts not originated by myself were donated freely. Regards Pete

You'd be better off using the event.timer facility. Each of the lines in your loop may take 0, 1 or possibly 2 milliseconds. If FS gets really busy doing other things there could be bigger changes. FSUIPC cannot give a high priority to the Lua threads, it must yield all the time to avoid impacting FS performance. If you use the timer event it won't matter about variations in the loop execution time. The timing is still not guaranteed (it never can be unless the threads are made very high priiority, which is not practical nor desirable), but it will be close and maintain the correct order of time over a longer period. No, it cannot. It is just a message sent to the Windows message queue for FS to pick up and obey. FSUIPC has no idea what the control does, so obviously it cannot check for completion. Pete

You need to add those two lines to the INI file before starting FSX. The log you supplied shows nothing wrong at all. There's no useful information. I'm sure you must have some application which is interfering with Simconnect's ability to respond correctly to menu requests. Once FSUIPC see's such a request the rest is all standard Windows stuff, completely out of FSX or other Apps ability to interfere. Pete

FSUIPC version 4.936b, just uploaded to Download Links subforum, retains comments in Keys sections just as in Buttons. Incidentally, you don't actually need ;// at the start, just the ; will do. The same 64 character limit applies, including the ; and a zero terminator. Pete

FSUIPC 4.936b, just uploaded (see Download Links subforum) now tidies up the .PNL files automatically, even without additional parameters. Pete

Sorry. I've had a good look at this, and I'm afraid it would be a complete re-write job which I'm not willing to undertake. Perhaps you could give me some details of why you would like this. Maybe I can suggest an alternative. Pete

No, you appear good to go ... ;-) Pete

Sorry, I can't really help as I have no idea what it is reading to measure things. You'll need to ask the authors. Pete

I received a log and INI file from you, but with many logging options enabled which are not needed, were not requested, and obscure what is going on. See: LogWrites=Yes LogReads=Yes DebugLua=Yes LogExtras=Yes Only these lines are correct from the original thread: Debug=Please LogExtras=x4001 However, those lines were either not there when the session of FSX was started, or were not effective because of the other, unwanted, options. The log line: 188 LogOptions=00000000 0000001D shows only the unwanted options set. Therefore I'm afraid there is no useful information in the Log whatsoever. Regards Pete

4.936 came out a few days after 11345 was released! Please always check for latest releases -- if in doubt see the Download Links subforum!! Pete