Pete Dowson

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

Well there shouldn't be any difference as long as you aren't using any global values. Didn't you manage to get the Module name and address for the CTD you were getting, so i could look and see if I could nail that one? ext.run("C:\Prosim\ProSimMCP\ProsimMCP.exe") -- does not work.?? Strings in Lua, same as in many other languages, use the '\' character as an escape, to allow non-graphics to be included, like "\r" for return, To include a real '\' you need two of them for each, i.e. \\. ext.close("ProSimMCP") -- does not work.?? As documented, ext.close needs the handle returned by the ext.run function, not the program name . Please do check the documentation if you get an error as the explanation is often there. event.offset("5034"), "UB", "MCP") -- Offset "5034" is assigned by Prosim AC gate. Which works. You've got two many ')' characters there -- the first is not wanted. Pete

That SIM1.DLL is indeed the same one I have for SP2. So there's something else odd somewhere. Can you please paste the whole of the FSUIPC log, not just the one line, please. Pete

I've moved this from the FAQ subforum, where it won't get answered, to here, the Support Forum, which is the proper place for support requests. What version of FSUIPC4 are you trying to use? What Installer version? In all recent versions different email addresses for FSUIPC4 and WideFS7 have been accepted. Only very old versions need them to be the same. However, the NAME part must be identical in both cases. Maybe you've spelled your name differently? Note that the current supported version of FSUIP4 is 4.929 or later. Pete

But you still have Controllers enabled in FS? The hat is assigned automatically (by default) to Pan View in FS, but this is listed in its Buttons/Keys table, not its axes table, for some odd reason. So check there -- in fact test if it works in all directions there. And note that if you haven't actually disabled controllers in FS then it can (and may have already) automatically reassign axes and buttons. It is for this reason you are advised to either assign all in FS or all in FSUIPC, not a mixture of both. Pete

I really don't know any way you can actually stop PAN VIEW from moving the view in all 4 directions, it is just a simple built-in FS facility. All FSUIPC will be doing is sending the control with its value to FS. Does panning work in FS if you enable controllers in FS? It should be the same. Also check for conflicts -- you did try assignments in the Button & Switches tab before. You need those deleted. If you aren't sure what to do, show me the Axes and Buttons sections from your FSUIPC4 INI file. Hmm. Test your panning without EZdok running to see if that's interfering -- you can close it as it is a separately running EXE file. Pete

As the Offsets Status documentation tells you, it is not effective for writing. You have to use the regular FS controls. Seems you are not referring to FSX documents? The FSUIPC4 offsets status document is the reference for FSUIPC4. Changes from what version to what version? The changes documents normally accompany the interim update in the downloaded ZIP. For main releases there can sometimes be a Changes document accompanying the full Installer in the downloaded ZIP, but that's only true if the History documentation is not fully up to date. The History document embodies all the changes and along with the rest of the FSUIPC documentation, including of course the offsets list, is installed in your FSUIPC Documents folder (as stated in the Installing and Registering document). Pete