Pete Dowson

When there's a syntax error in a plug-in you will get an error message in the FSUIPC log pointing to the line in error. That's where to look whenever something doesn't work as you'd hoped. I always test with FS (temporarily) in windowed mode and the FSUIPC log console window open to the side so I can see what's happening in real time. Regards Pete

The only answer might be you get SB up and connected before "climbing into" your cockpit. I have a 737NG cockpit and make sure FSX and ASN are up and running, and all 7 of my client PCs are set and ready, all before getting into the pilot seat. From then on I have normal 737 controls available to me. Perhaps the on-line ATC organisation you fly with has a Forum on which you can seek more help? Pete

Obviously you install FSX before you install any add-ons for it. And make sure it all works first. Then add things one at a time and test each time, with a separate reload of FSX. I'm afraid I don't know SPAD, but as I think it needs to use FSUIPC you want FSUIPC installed before actually running it. Though I'd expect it to tell you that it needs FSUIPC in any case. I doubt whether Saitek stuff needs any specific order of installation -- at least I can't think of any reason why that should be so. But if you are worried it would be better to ask on Saitek forum. I can't support their devices. BTW I am 71 years old this year. Age is really not relevant to computer literacy. And very very few visitors here are computer programmers. Incidentally, whilst I am here most of the time to give help with FSUIPC, WideFs and related matters, I do go away quite often (eg from Saturday for 8 days), and in any case I am not so good at giving general advice. Your best bet for such is probably the FSX forum over on AVSIM.http://forums1.avsim.net/forum/121-ms-fsx-forum/ Pete

Ah, you are talking about SB3 and FS9? If you are using SB4 and FSX then there are none as SB4 doesn't use FSUIPC at all. And as you have seen, the offsets are only related to "push to talk" and "ident" and related cockpit actions. Starting and connecting SB is really not an "in-cockpit" action (there's no real world equivalent, obviously), so it seems it isn't considered for such implementation. Surely there's some documentation for SB which tells you its keyboard shortcuts if any? Are you saying it can only be operated with the mouse? Pete

I don't know SquawkBox, but if it accepts keystrokes to do as you wish then you should be able to do it through WideFS. You assign to a KeySend value in FSUIPC on the Server, and edit the WideClient.INI on the Client PC to respond to that specific KeySend by sending the required Keystroke to Squawkbox. Which method of those available for directing keystrokes (see the WideFS documentation) depends more on Squawkbox -- the way it detects the keypress. It might be better is you had WideClient loading Squawkbox as then it can direct keystrokes more specifically and reliably. Pete

Do you think you could post these details, maybe with our working plug-in, as a User Contributions subforum? That way it will remain a useful reference. Thanks! Pete

There's no "Team", just me, Pete. ;-) The FSUIPC4 installer doesn't care where your FS is installed, as long as it is installed correctly it will find it and install correctly. The FSUIPC installer doesn't touch anything on your system outside of the FS folder, and all of its files and documentation are installed in the Modules subfolder, which, if not already there, will be there after you've run the installer. It doesn't matter where you put the Installer itself in order to run it. One you've run it you can delete it. Take note also of the Installing and Registering document included in the download ZIP file. Pete

Okay. It took a lot of delving. Simple interlocking did not help at all. But after a lot of hacking into Windows.DLL assembler code and finding where the windows handle is stored in the structures (via a pointer to a pointer to a pointer!), I think I've cracked it. Please download FSUIPC4.929h.zip and try it with any Lua plug in displaying a window.. I've been testing it on both FSX Acceleration and P3D v2.2 Beta and have not made it hang yet. Regards Pete

Sorry, that's not easy to tell without doing a binary comparison -- they all have different date stamps so I assume they've all been recompiled. Ceretainly differences are known to FSUIPC, but sometimes it handles these differences by going through a sequence of tries -- i.e. try this address, try that, till a fit is obtained. These are the differences which matter to FSUIPC4: SIM1.DLL for wind smoothing hack and the frictions/braking tables API.DLL for SimConnect text and menu diversion for WideFS G3D.DLL for the most common G3D crash patch ATC.DLL for the nearest airports list Pete

Yes, very strange. Glad it's sorted. Pete

I've now managed to reproduce the hang which can occur when restarting this, and other Lua plug-ins which use the display facility. It appears to be a problem occurring deep within FS when an existing display is being updated whilst being created or destroyed. I'm working on interlocks in the calls being made, to try to prevent this, but I don't know if it is solvable at present. I know that if i change FSUIPC to never close the display there is no problem at all, you can kill and restart Luas as much as you like. However, it does obviously need to be closed when there's no further need -- so maybe that will be the answer but it makes it more complicated keeping track of it as a separate resource. I will see what I can do but do not hold your breath! ;-) Pete

Looks okay now. I hadn't noticed the G3D patch being missed in the last one -- that's evidently another FSUIPC action not possible if it doesn't get the correct EXE. Sorry, I didn't go all the way through my code to see what else might be affected. I was really more concerned that there would be real conflicts between your EXE and the mismatched DLLs. Pete

Two points. First, you appear to have set LVar1Set twice, but you have never set a value for LVar2Set. I assume that's a typing error? Second, just because a gauge records a value in an L:Var doesn't mean it reads it in order to handle the related function. It may not be possible to control the action this way at all. You could experiment with the order in which you write those three LVars.in case it's critical in the way the gauge is processing. Pete

Yes, the GetHidButtons line you show is okay, but you also want to shorten the loop. Change while i <= 8 do to while i <= 2 do. And if you are keeping the logging, change the logging line a bit later to: ipc.log(string.format("Buttons= %X %X", buttons[1], buttons[2]) On the matter of getting a count of buttons, I'm having second thoughts about that and may implement a new function, com.GetHidButtonCount. But maybe not this week. It's on a list. Pete

I am pretty sure that the protocol used for On Top is not the same as the native PFC protocol and will therefore not be recognised or handled by any of my PFC drivers. I think you need to contact PFC, who may be able to convert them for you -- at a price, of course. Regards Pete

Yes, I think that is so. My memory is not too good these days, and it was over six years ago, but I think the Beta releases themselves, the ones I tested with, were in the order you'd expect, but the actual release to users was different. The payware Acceeration was probably available before the SP2 download became available. Probably a marketing decision. My SP2 modules including the EXE are all dated 10/12/2007, two days earlier than your EXE. Not sure why. Probably mine was a slight pre-release for Beta testers. Pete

I don't think so. Yu could make a safe copy of your FSX.CFG file, and maybe your SCENERY.cFG file, but I can't really think what else could be disturbed at all. You should be able to. I don't recall the name of the unpacker at present. Google should find it -- aren't they just packed with slight variations on the filenames, like a final __ or something? Have a look on the disk. i don't think it's a monolithic ZIP, I think all the files are separate but compressed. The frictions can't be patched because it can't locate the correct place in memory. I am not aware at present of any other difference which would affect you, but if you can't resolve it I'll check for you. I would be more concerned about the inter-compatibility of that EXE with its DLLs. I would expect problems to arise because of incompatible functions, links, and so on, in both directions -- the EXE calling the DLLs and vice versa. It is simply not a desirable situation at all. For sure, I know for recent experience with P3Dv2, even different Beta's for the same release can have different function entry points in DLLs from one week to the next. Pete

You've re-assigned the keypress to Ezdok. I assume it isn't really the keypress you want (because that's chosen as needed by you, if you wanted to use the keyboard) but the correct FS control? The normal way of determining which control is which is to use the default FS keypress for it when Event logging is enabled in FSUIPC, then check the log to see which control it invoked. But if the keypresses A and S no longer invoke those, because of Ezdok, then it isn't so easy. However, I think they are these Next view Next sub view but i'm not sure which is normally A and which S. The shift versions would be Prev view and Prev sub view. There is a list of controls installed in your FSUIPC Documents folder which you might find useful. Regarding your INI file, here are some observations: You have just one button assigned and no axes assigned or calibrated for anything but the one specific aircraft. This is most odd. it is really best to do all the general assignments and calibrations and only do specific things for specific aircraft when they need something different. Then, when you add aircraft, you can use the generic setup as a base and merely make the specific changes you find you need. The way you have it you would be starting from scratch every time. A minor thing. In the JF A319 calibration section: Throttle=-16384,16256 Throttle1=-16380,-512,512,16380 The generic throttle calibration (Throttle=) covers all engines. Not sure why you have a single throttle 1 calibration as well, though by the look of it you've not actually gone through the calibration process -- the values are defaults. You don't actually have a separate Throttle 1 axis assignment so it has no actual effect. Best to delete that "Throttle1=" line now in case it comes into play one day. Regards Pete

I was expecting details of the CTD you reported. That report is not for a CTD of any kind, but a hang in Prepar3D.exe. I'm afraid there's no useful information for me. A CTD would be a proper crash -- a hang is not decipherable without using tools at the actual time. In this line: x=ext.run(c:\\Prosim\\ProSimMCP\\ProsimMCP.exe) you've correctly changed the single '\' characters to '\\', but inexplicably have removed the " at either end of the string which are needed to denote the string! Why? All you needed to do was double the '\' characters as I explained! Why change things which were correct and as per documentation? There's nothing wrong with the ext.close. Obviously it won't work till you get the ext.run correct! It really isn't complicated. you just need to be more careful. Programming is like that -- computers are stupid, they can only process things you tell them precisely and correctly. I'll try it here, but this is a well used plug-in which has always worked perfectly in FSX so i'm concerned it is specific to the LVars in your particular aircraft. Is it an add-on, and if so, which? Oh, and how did you restart it and why? Pete

I don't really know what edition was what, but certainly you have the Acceleration version of FSX.EXE installed. I'm surprised there aren't other problems. Try renaming the FSX.EXE and re-installing the SP2 update -- it should put the correct, matching, EXE in. Well, nothing has changed on the Lua side of things. But I can't really help without knowing what this Lua is doing. I don't know what you mean by "abnormally triggered". FSUIPC is not an active component, but one that responds to requests. Pete

Hmm. I'm now really puzzled. FSUIPC is looking in the location in SIM1 applicable to the Acceleration version. Yet the version number returned for FSX by Simconnect is correct for SP": 11060 Running in "Microsoft Flight Simulator X", Version: 10.0.61472.0 (SimConnect: 10.0.61259.0) So I'm a bit concerned. The only way FSUIPC can use the Acceleration values is if it sees the version number of FSX.EXE reading 61637. Can you look at the FSUIPC INstall Log for me please, find the section like this: INSTALLATION FOR FSX: SetupPath="E:\FSX" Checking version of the FSX EXE: ... Version 10.0.61637.0 (Need at least 10.0.60905.0) That's my Acceleration install, of course. Yours should show 61472. Sorry, is this something for me? Why would an aircraft not taking off affect what a Lua plug-in does? Pete

Please download and install FSUIPC4929g.zip. There will be some extra lines in the log telling me why it can't provide the frictions access. Pete

I think you must be using a newish version of Windows Explorer. There's some option you need to change to allow pasting. Most folks find they can't attach files. Odd how things differ. Anyway, I can't see anything wrong which could cause the frictions access to fail. It is most odd -- and I can't reproduce this here. I'm adding some extra logging to tell me what it is stopping this. Later today I'll provide a link to an interim update for you to try and show me the log again. Pete

Yes, please use the SimMarket problem ticket system. I'm sure they will resolve it for you. If not, email me your details to petedowson@btconnect.com, with both sets of registrations. Pete

Your comment had me puzzled for a while, but then I realised you didn't mean an increment f 8 but a omultiplier of 8. And, yes, it is a bug. It should be 4. Thank you for pointing this out. I never had a HID device with more than 32 buttons so it never resulted in any errors! I'll fix it ready for the next update. You mean 32 buttons x 8, not 8 buttons x 32. Each value returned by com.GetHidButtons is a 32-bit word. So if a device has say, 48 buttons, you'd get 32 in the first and 16 in the second 32 bit word. It allows up to 8 of these 32 bt words. Why would I want to split the returned values down in to smaller pieces when I can so efficient;y merely store them into the offsets 32 bits at a time? If you want to use some of the virtual buttons offsets for other devices then you need to alter the program, obviously. You need to limit how many words or bytes you store and adjust the starting offset appropriately. If you only want to handle 8 bits or less, then you'd use a Byte write, and so on. At present there's no way to get the number of buttons actually provided. That's a fair point. It is something I could might be able add if needed.It could be returned by com.gethidcount with the axis name omitted. I'd need to check first. [LATER] Actually, just getting the number of buttons for the device is a lot more complex than I thought -- a lot more code. I know how to do it (it is done, for instance, in my HidScanner program), but at this stage I'd really rather not mess with the current Lua library code in this area. Sorry. Pete