Pete Dowson

A "multiline" display is produced by you sending a string containing "new line" or "return" codes. It is sent to SimConnect like that. No processing in FSUIPC, it is all part of Simconnect's display function. You mention "slow down the scripts" as if you are sending one line at a time, adding to the string each time. If that if what you are doing you could get a flicker too, as each would result in a separate request to SimConnect. Without seeing the script I can't really offer any other thoughts on this. Pete

I'll take a look. The original reason it was added was because FSUIPC3 and 4 allowed different configurations, which involved renaming the FS EXE and the KEY file, which made FSUIPC read a similarly differently named INI file and FS to use a similarly renamed CFG file. Such an elaboration was not only not needed once Profiles were introduced, but was also rather incompatible with the way things were going with all the ancillary files and other addons needing to retain normal naming. However, if the message still has a use I'll certainly add it back. Pete

It appears as if iVap it intercepting the Windows keyboard messages sent to the main Sim Window procedure, thus stopping the sim seeing them. FSUIPC does the same thing when you assign a keypress in FSUIPC. This, however, is simply inaccurate. That shows the button being released, for which you have no assignment (the P on the assignment means "pressed"). Pete

Sorry, it is exclusive to SimMarket. I've no idea why you've had a bad experience with them -- they are a lot better than some! Pete

FSUIPC saves nothing whatsoever*! It simply calls the SimConnect facility to save a flight, providing a filename. You can do the same manually by pressing ; and entering a filename or title, or using the Scenario/flights menu options. And try saving a flight manualy too, by either easy method. *Unless you select the option to save the FSUIPC data (offsets) too, which creates an ipcbin file. That was added for Project Magenta, so that a crashed flight could be restarted with the whole of the cockpit setup being re-established. Pete

But those two are certainly known to FSUIPC and deleted automatically! The log you provided shows this for the first 5 attempts, where error 2 means that the deletion failed "file not found" (there are two such error 2/2, one for the.fxml file and the other for the .wx file. 569766 *** ERROR: Autosave couldn't delete "C:\Users\Owner\Documents\Prepar3D v4 Files\AutoSave Thu 194338" (error 2/2) 569782 ... Autosave finished I say that because there's no sign of the AlsoManged files being deleted. Then 867313 Autosave: deleting "C:\Users\Owner\Documents\Prepar3D v4 Files\AutoSave Thu 213613" 867313 Autosave: deleting "C:\users\owner\documents\Prepar3D v4 Files\AutoSave Thu 213613..FLT" 867313 Autosave: deleting "C:\users\owner\documents\Prepar3D v4 Files\AutoSave Thu 213613..mj1" 867313 Autosave: deleting "C:\users\owner\documents\Prepar3D v4 Files\AutoSave Thu 213613..mj2" 867328 ... Autosave finished showing both .fxml and .wx files wew deletred without error as well as your three AlsoManaged files. So I'm now thinking there was actually nothing wrong except that you needed the three AlsoManage lines. If not, then it is really strange. There has never yet been a case where the normal fxml and wx files have not been deleted correctly, and it is impossible to reproduce such a scenerio hare on any of my systems. However, just so i know we are on a level field, could you please download the current interim ipdate. 5.122a, from the Download Links forum above, and test again. And also please test with a non-addon aircraft, as requested. I'd rather not. Care to summarise it? Thanks. Pete

The only thing I can think of, and probably the most likely thing, is that the way the 32-bit program, WideClient, is sending the Keystroke does not work with a 64-bit program. You might need to try changing the way it works. There are a couple of different ways documented in the WideClient docs. Pete

Why? What happens otherwise? There are a great many users of FSUIPC5 also using the PMDG747. You'll need to provide a lot more details please. Including FSUIPC5 version number and whether your 747 is fully up to date (because earlier versions did crash if FSUIPC was running as it was try to execute 32-bit code, as if to call FSUIPC4, in a 64-bit process). Mostly questions where another product, like the PMDG aircraft in this case, crashes are usually much better addressed by the correct related support forum. I hand;e crashes in FSUIPC itself. Pete

Please show the actual part of the INI file, which will have those lines properly annotated so I can understand what they represent without resorting to the code! No Well, that's something internal to the coding for your add-on HSI. Let me see the proper annotated assignments please. Pete

Custom controls are assign via the custom control> entry in the drop-down lists, which is at the top of the list, and entering the number of that custom control. In the case of PMDG aircraft that is calculated by reference to PMDG's lists in the .h type document they include in the SDK subfolder of the aircraft. That just shows that a mouse macro won't work on that switch. That's why the TAB test is provided.. No, it has no idea about mouse pointers. And it doesn't even know the mouse position. It is simply trying to trap whereabouts in the aircraft code that clicking that switch calls, so it can call that place itself. It is very complex code which only works in a limited number of cases. Pete

But these entries in that "FSUIPC5" INI are proff that this is the FSUIPC4 INI, just renamed: UpdatedByVersion=4971 ... FSVersionUsed="Microsoft Flight Simulator X",10.0.61472.0 SimConnectUsed=10.0.61259.0 Those entries would be updated to reflect the P3D4 version and FSUIPC 5.122a IF you'd ever run P3D4 with that INI in place. Please check that you are placing the INI gile in the right place, replacing the default originally generated by FSUIPC. You'll need to describe what is not correct as well as what is correct. I've no idea from that whether they are misbehaving, not providing inputs at all, or a cross-aligned. Also test with default aircraft first, and state which aircraft you have any problems with. And does the "etc" bit mean the throttles, or are you talking about all the other strange axis assignments dealing with offsets 66XX and Lua plug-ins? Finally, i see you are using profiles with separate files for the profile assignments, in the Profiles subfolder, so if you've a problem with specific aircraft, the files in those folders will also be relevant. Oh, ... AND the FSUIPC5.LOG file, please. Always needed. Pete

Note that it is PMDG which changes the pointer, and FSUIPC does not "register" it. The switch won't "flip" when making a mouse macro until you test it with "TAB", as instructed. You need to follow the instructions more carefully. Pete

Why? PMDG aircraft come with a full set of assignable "custom controls". Mouse macros are not supported at all in P3D4, and aren't working for many things on FSX or P3D3. Please see the other thread near here on EXACTLY this subject! You should really try checking before posting afresh. Also you posted in the FAQ reference subforum, where it cannot be handled, You are lucky I saw it and moved it for you. Pete

You've added a meaningless request to a six-month old and dead thread, which is three pages long! If you want help with FSUIPC or WideFs, post a new thread with an appropriate title and full details, or if it is primarily about PMDG aircrft, post in the PMDG forums. Pete

I've tested by artifically making ..FLT, ..mj1 and ..mj2 files and adding the same AlsoManage lines as yours (but with me "Pete" as user not "Owner" of course), and all the correct files were deleted fine. So something else is going on there. Please double check the files do actually have ".." not just ".2. I'd also ask why a FLT file is being made. Pete

Your user name on the PC is "owner"? I've only just noticed that you have .. before the filetype, not just a single . Maybe this explains it. Do the files really have "..FLT", "..mj1" "..mj1" and not just the usual ".FLT", ".mj", ".mj2"? The files saves by P3D4 will be type .fxml. Aren't there any files of that type -- the last 5 will be? The others should be automatically deleted. I've no idea what is creating .FLT files as they are not made by P3D4 since they changed the format to XML. The only files save by P3D4 are .fxml and .wx. See what files are generated when you save a flight manually, in the P3D Scenario menu. There is some built-in logging for AutoSave operations in FSUIPC. Please enable this by adding these two lines to the [General] section of the FSUIPC5.INI file before next running P3D: Debug=Please LogExtras=x4 Also, please try using a different aircraft and see if it works with that. I'll do some tests here too. Pete .

As I said, in the SDK folder in your PMDG aircraft installation. Pete

... and to emphsis what Thomas says, you should keep your P3D4 installation up to date. It isn't as if it costs you anything, and the improvements are significant on each point update! Pete

Well, no "schema.ini" file is touched, generated, deleted or in any way affected by MakeRunways. And it certainly isn't included in an folder called MakeRunways made by MakeRunways, because no folders are made at all, ever. You made your own such folder, if you remember, for some reason. Or maybe the RAASPro installer makes such a folder for you to copy makerunways data files into? No if that is the case, and then you deleted it as you stated earlier, that's probably how you deleted the Schema.INI file! Either way, there seems to be a lot of misleading information which needs clarifying by RAASPro makers. BTW I've no idea what a "schema.INI" file is! Pete

I don't know what language you are using. If it is related to Paul Henty's .Net DLL you need to post in his support Sub-Forum above. Generally, to find bugs in an accessory program you need to use the debugger appropriate to the language, and which is provided as part of your compilation system. Pete

How is that related to Makerunways, which does nothing but produce data files from your scenery installation? Pete

That indicates that your switch is continually changing from pressed to release. Have you set it to "repeat" by any chance? Mouse macros aren't really the best way to assign PMDG controls in any case. PMDG have been good enough to supply individual <custom control>'s for pretty much everything. Just find the ".h" type file in the aircraft's SDK and follow those instructions. The list of controls is at the end. You need to calculate the control number then assign it via the <custom control> selection in FSUIPC. BTW using a subject title like "FSUIPC BROKEN" does no one any favours, and least of all yourself. If you title it properly like "Mouse macro problem with PMDG737" then you might attract more helpful and speicifc information from actual PMDG users, of which I am not one. Pete

No, you can use whatever keys you want to assign. I tend to use the defaults, which are still plain keys I think. But if the keypad is recognised by Windows as a key press, that would seem to provide keypresses within keypresses? And only using your strange assignments for 0, 1, 2 and so on? Why not just use 0, 1, 2 etc as normal. It surely works okay then? So the numeric keys don't become "dead" with other Simconnect menus? There's no difference between them, you know. They are all the same standard SimConnect mechanism. FSUIPC knows nothing about whether you are in Full Screen or Windowed mode. It simply doesn't care, or detect it. I think you need to look elsewhere about your configuration. PEte

That's the default place if the real scenery.cfg file cannot be found. It often means you are not running MakeRunways from the main FS folder. MakeRunways is not supplied with an installer nor a folder. You just open the ZIP and copy the files yourself. Pete

Ok, the "mj..." files won't be deleted unless you tell FSUIPC about them. It can't possibly know about all the possible files saved by different add-ons! Please look up AlsoManage in the Advanced Users guide. Pete