Pete Dowson

Have you tried right-clicking near the top of the display and selecting 'close'? Pete

I am sorry, but I cannot make any sense of the translation provided. Are there any French speakers here who can explain what this is about for me, please? Pete

The normal way internal modules like gauges and DLLs prevent calls to other parts of FS (such as FSUIPC) is by receiving the notification that things are closing down and then immediately start tidying up and not calling them. Otherwise you could get similar problems, or even crashes, by calling other parts (gauge functions and SimConnect) after they've closed. FSUIPC's response Window handle is valid until well after the SimConnect call to end things -- it has to be to allow its notifications to WideFS clients to be distributed. However, I'll make a note to update the FSUIPC SDK next time it needs a set of changes, but meanwhile could you post these details with a suitable thread title to the "User Contributions" subforum, please? Interesting that this would be the same in all previous versions of FSUIPC too, dating back to FS98, and it hasn't cropped up before! Thank you. Pete

Sorry, that last part confuses me. "version 4.90 as it was the last version i had that worked and upgrade it all the way to 4927b it seems to work". are you saying 4.927b works for you once you installed 4.90 then updated? Because that makes no sense unless you mean you also deleted your settings (INI file) and started again, in which case it was something to do with your settings. Pete

Your problem was entirely due to your use of some installation fiddle to make P3D look like FSX for those add-ons which don't recognise P3D. The writer of the main one of these was supposed to be fixing it so it worked correctly. FSUIPC's installer cannot do anything about it because of your renaming of the P3D file. You may well encounter other problems because of this, and even random crashes in P3D. I'm afraid I cannot support FSUIPC or WideFS used in such circumstances. Pete

Enable Key/Button logging in FSUIPC and it logs start and end of Lua plug-ins. Pete

Sounds like your FSUIPC is out of date. Install the current version. Pete

Yes. Got to go now ... back on Jan 9th... Pete

Sorry, I'm not really sure what you mean, but if you want me to find error messages then the only ones I see are the two crash reports you included. Pete

Er, it is pretty abvious, I would have thought, that (3.0/90.0)*(10001750.0*65536.0*65536.0) is 3 times bigger than: (1.0/90.0)*(10001750.0*65536.0*65536.0) which would give the correct conversion value. If that's not "multiplying by 3" then your understanding of multiplication is not the same as mine! Writing your sum in a different way, it is identical to: (3.0*10001750.0*65536.0*65536.0)/90.0 which may let you see how you are, for some reason, multiplying by 3! Where do you get that 3.0 from? It doesn't appear in any documentation for the offset you are dealing with, so why is it there? Did you not yet bother to check your work using the logging, or the Monitor facilities, in FSUIPC? Pete

Unfortunately not as neither of the crash reports you provide actually identify a module. I've usually found stackhash type errors, as one of yours is, are a result of overloading in FSX -- either memory corruption when the memory use is nearing a critical point, or some complex add-on or scenery. If you believe it is related to ASN + FSUIPC, which you appear to imply, please make sure all weather options are turned off in FSUIPC and ASN is running before you start FSX. From what I've heard from HiFi this helps. I think they are looking at assorted reports like yours at the moment. I've also supplied them with an updated FSUIPC, which you can also try if you wish (link: FSUIPC4927e.zip) but I don't this will have anything to do with actual crashes, at least not from the FSUIPC side of things, so it may not help. I don't know -- HiFi are looking at it.. I'm just preparing to leave for a short holiday -- back on January 9th, so I'm afraid I won't be able to evaluate any more results in this matter for a while. Certainly ASN + FSUIPC 4.927a have behaved impeccably for me and friends on all flights since they were released, so I'm sure it is not a general problem and may actually not be attributed to either product. Whenever I've had the stackHash type error, which is rarely, I've found solutions lie in the direcxtion of reducing some of the loading on FS. Regards Pete

I don't have any A2A aircraft and I don't know about these files so they are not automatically handled. You would have to edit the FSUIPC4.INI file to add them as "AlsoManaged". for deletion -- se the FSUIPC4 advanced user's guide, there's a section about it. These options were added for just such cases. However there appears to a problem with A2A, because it is corrupting the filenames, so that even the "AlsoManaged" facility cannot work. It is not FSUIPC which saves the files (it has no idea about the add-on files) but the add-on package itself -- it does it when it sees a flight being saved. You need to report this to A2A so they can fix it. Seems they expect the filename supplied to SimConnect to include the filetype (.flt) which it doesn't need to do at all -- the A2A code should check for the presence of the '.' before removing characters, not just remove them without checks. You can, temporarily, force FSUIPC to add the .flt part by setting "P3Dv2Fiddles=Yes" in the [General] section of the INI file as described in the "Changes" document for recent FSUIPC4 releases. However, this is only a temporary measure -- FSUIPC is only then adding the ".flt" part in order to make sure both a .FLT and .FXML file is being saved -- currently, in P3D v2.0, the FSUIPC option to reload flights doesn't work with FXML files because of a P3D bug, but when it is fixed (in 2.05 or 2.1) the "fiddles" will be removed. Regards Pete

I think you use Squawkbox4 with FSX, and SB4 doesn't use FSUIPC4, only SimConnect (I think), so it won't use WideFS. Pete

I don't know the language you are using, so I can't comment on that or whether you are using the correct variable types, but I would just ask why you are multiplying by 3.0. Since the FS units are designed so that the max possible value (90.0 or -90.0) just fits exactly into the 64 bits, I would have thought that multiplying it by 3 would make it too big to fit. Did you think of trying the assorted logging facilities in FSUIPC to check your work. That's why they are there. Regards Pete

There are all sorts of examples of different Lua plug-in methods in the ZIP file in your FSUIPC Documents about Lua plug-ins. You will probably also find lots of different examples in the User Contributions subforum. I would help you once you make a start and try things, but my time is very limited until I return from holiday on the 9th -- I am not actually away yet, just preparing. ;-) In any case there are others here who will be able to help. But be specific in your thread title so you attract the right responders (start a new thread). Pete

FSUIPC's drop downs only list controls which are built into FS, or added by FSUIPC for functions which can be implemented easily for FS. Add on aircraft very often implement their own way of doing things. You will need to refer to their documentation. There is a program "iFly2FSUIPC" which maps iFly data and functions to FSUIPC offsets so you can use FSUIPC offset controls, but I don't know if that works on FS9 or only FSX. Also you may find that mouse macros can be made for that aircraft -- I don't actually know. Alternatively some folks may well have made some Lua plug-ins which do the job, and it may possible also using.local panel variables (L:vars). Sorry, there's no way for me to know as I don't use iFly (nor FS9 for that matter). Macros and Lua plug-ins places in the FS Modules folder alongside FSUIPC will also be listed for assignment in the dropdowns in Buttons & Switches, Axis and Keys assignments, but you need those files first. Check through the threads in the User Contributions subforum -- someone may have already done it. Regards Pete

FSUIPC4 does not work in FS9. You need to install FSUIPC3. Within the FSUIPC Documents folder you'll then find a "Programmer's Guide" document which contains the offset list and more information, much of which also applies to FSX. These documents are also provided in the FSUIPC SDK. Pete

What version of FS? What aircraft? Which "drop down bar" -- do you mean FSUIPC's Buttons & Switches assignments, right-hand side? There are several add-on controls for EFIS provided by FSUIPC for FSX default 737 and A320, but FS itself provides none. The control seems to be internal to the gauges. Pete

No! The name of the macro is Magneto1. That's it. The number, 0-4 is passed as the parameter. It is NOT part of the macro name. At least that's what the documentation says! Without delving into the code I'm 99% sure that's correct. The words in the documentation actually do say that. So you only have ONe (1) entry: 1=Magneto1=Cxxxxx You don't specify the parameter for the control because that's provided by the switch value. If you provided a parameter value it would override the switch value so making all positions do identical things. [LATER] I can delve into the code when I get back from holiday, on the 9th January, but I won’t have time before then. Maybe if the way it currently works makes it difficult I can make some alternative arrangements in the code, but meanwhile you’d probably need to use Offset controls and/or Lua plug-ins to do clever things with multiway switches. [Odd all this cropping up after several years with no questions about PFCHid arising at all!] Pete

No, not a silly question. I don't use this software and haven't really looked at it for a few years, excepting a couple of minor changes to fix a problem one user reported (to do with multiple profiles and not changing correctly when the aircraft was changed). So I don't remember, and have to look things up in the documentation just like yourself. The example it quotes which is a multi-position switch similar to the transponder is the Magneto switch (or switches, Magneto1 and Magneto2). As you'll see there the five possible switch positions are 0-5 and this number acts as the Parameter passed for the control sent in the Macro -- all macros are like button assignments and have a control value and an optional parameter (see FSUIPC assignments). The parameter will be 0 to n for n+1 positions. Pete

Of course. I only suggested you looked at a shortcut (ANY shortcut) to see what I meant about "current folder", as I explained. The folder in which the EXE is in is not really so relevant, it is the CURRENT FOLDER which is relevant. i.e. the one the EXE gets files from if it specifies just the filename, no path. I'm pretty sure that if it works okay when executed with the FS9 folder as the current folder (which will be the case automatically if you double click on the EXE in the FS9 folder, or double click a shortcut to it made by using the right-click "create shortcut" option in Explorer), then it will work in exactly the same way if you simply ensure that the current folder is set to the FS9 folder. If you really do not know how to do that in VBS, or if it is not possible, try placing your VBS file in the FS9 folder and executing it there. Pete

No! The parameter would be supplied as the parameter to the control. And you can't have two macros with the same name in any case. I'm not sure what you are trying to do which isn't already done inside PFCHid. All those FSUIPC transponder mode controls do is set values to the offset 7B91 for Squawkbox attention, and this is exactly what PFCHid does itself, already! So you aren't accomplishing anything different. There are no transponder modes in any default aircraft, and even with add-on aircraft they wouldn't do anything unless you are flying on-line. Regards Pete

Ugh! If you are using Lua, why not simply have a resident Lua plug-in (loaded by an [Auto] section) which uses event.offset to watch for changes to a selected user offset (such as 66C0) where your IOCARD driver can write a number for action? BTW with strings you must write a zero at the end to terminate the string as well (this is actually included when you define strings like "string"). The facility to execute a macro operates immediately you write to 0D70, which is why you are supposed to write the whole string at once. Otherwise you'd need to write to 0D70 last. Pete

I think the answer is fairly obvious from your first post: There is absolutely no way anything on each users systems can do that. It must be the Server. FSUIPC gets the blame for many things, but magically affecting numerous user's systems simultaneously is a first! ;-) Pete

You have the format for macros wrong. I'm not sure where you got that from. The format is EITHER 1=Nav=C66239 OR 1=Nav 1.1=C66379 In the latter case you can have further lines, 1.2, 1.3 etc for additional actions. In the former case, that's it. Again the format is wrong. The [Auto] section can execute Lua plug ins or Macros, but there are no direct assignments in such a section, only macro calls ("file:name"), or Lua calls ("Lua name"), as documented. Pete