Pete Dowson

Why, is this Aerosystem a built-in DLL, withingP3D4, like FSUIPC? Or an external 64-bit program? Are you the author? If so, just compile it with the SimConnect.lib file provided in the P3D4 SDK, and it will interface directly. If your program is 32-bit, then it can use any of the heritage SimConnect.dlls as installed with P3D1 and of course FSX, FSX-SE and ESP. Pete

In P3D3 I can capture the SimConnect style menus, like those from GSX and ProATC/X, but never the default ATC. With P3D4 I am waiting for L-M to implement suitable facilities, which are sort of half-promised. Whether they'll also cover the default ATC is unlikely, however, as the easiest implementation would be to intercept and pass on the data from the SimConnect calls. Pete

I don't think it works on my system. i'm not had much luck with any PMDG aircraft and so it is lucky I don't actually use any. Are the offsets adjacent or working as docyumented? Have I just made an error transferring their list, from the SDK .h document, to my documentation? The data provided is all there, it is all I get given by the aircraft code. It's just one Simconnect notification with a pointer to the data block which i simply copy into the offset space. So either it's a PMDG bug, or a documentation error on their part, or one on mine copying the stuff over and labelling them with offsets. In the latter case, if I have the sizes of any of the fields wrong and so miscalculated the offsets positions following, then everything after those would be worng. So that's where to chek first. If the result of your check is that it is one of the first two possibilities, then you need to report it to PMDG. I'm going to be a bit too busy this week, but letme know if it is my error and i will fix the document. Pete

I don't know how they search for things. They obviously don't look in my documentation or installed files like most users do! ;-) Pete

What are they doing there? No one has asked permission to uploaad them anywhere! If you read the Install directions for FSUIPC when you downloaded the ZIP you would have seen the 747 file clearly listed. Both that AND the FSUIPC User Guide tell you where the files are placed! Pete

I think they should all be there, but as with FS control names, they often aren't easily recognisable. Pete

Yes, the file is in the FSUIPC Documents folder. It is called "Offset Mapping for PMDG 747QOTSII.pdf". Why don't you just look!!? Pete

You cut the first lines out of the Log. PleaseNEVER do that. I need to see those details! You are using the PMDG 777 and trying to use it with FS controls. PMDG aircraft operate very differently from default or less sophisticated ones. test those control assignments on a different aircraft. PMDG aircraft do support a large number of "custom controls" which they list in their SDK folder, the .h document. You can use those. Or you can try assigning your buttons to keypresses. Pete

Bit late, but thanks. The PMDG 747 has been supported for quite a while now, up to v3. Pete

The name is too long. it breaks the rules (max 16 characters). The only purpose of that list is to enable button or keys to be assigned to those Lua files. If that file is never used in such a way it doesn't matter. But adding it manually won't do any good. it will make no difference. Pete

I've been checking the Window saving, and there are some inconsistencies between use in a maximise / whole screen and normal windowed P3D4. The "docked" values saved are not Window coordinates but proportions of the P3D4 window size, as a portion of 16384 (so 16384 = 100% of height or width). I'll check that this works correctly. The idea was to keep the SimConnect window in proportion and relative position in P3D4's window no matter what happened to it. Maybe I should only do this with the position not size -- though both would need adjusting if they don't fit the new P3D4 window size. But the undocked values should be screen coordinates, with negative values for screens to the left of the default, as so on. That seems to work pretty well here but needs more testing. I'm going to be very busy with other things in the next 3-4 weeks, so I might disable this new facility for now so I can make a release with the Lua fix which you are testing so ably for me! Pete

I don't know this product at all. Is is documented as an FSUIPC client application? The SimConnect DLL modules used by P3D2 and P3D3 versions of FSUIPC4 is only there because Prepar3D did not install a SimConnect package automatically, though FSX did. Most FSX and FSX-SE users would not have really needed the SimConnect modules FSUIPC installed in any case, as the existing ones they had would be fine. FSUIPC4 interfaces to FSx, FSX-SE and P3D1-3, so it needs a Simconnect interface compatible to all. P3D4 is different in that it is a 64-bit package needing 64-bit DLLs, and it still doesn't install library DLLs. And since FSUIPC only has to interface ot P3D4 and nothing else, the interface ot the simulator can be built in -- which it is! Pete

To help me with further testing of the SimConnect window saving facilities, can you tell me a few things please? 1. Are you running P3D4 in full screen? 2. If not full screen mode, if P3D4 maximized? 3. Do you have other screens where you move undocked windows to? So far I cannot make any docked or undocked saved window parameters go wrong. They all seem to restore correctly on reload -- not necessarily in docked or undocked state, as I don't control or save that. Just positions and initial sizes (the vertical sizes of the Windows can be lenghened when needed for additional test or lines -- i'm not in any way involved in that). Pete

FSUIPC is only reading the positions when it sees that the windows are created, moved or resized (whether visible or not). The undocked ones will probably be screen coordinates. Not sure about the docked ones -- probably not. I'd have to check both. The facility you are worried about is not finalised yet. I'm still testing it on different PCs. I've not yet tested the undocked windows. The docked ones are behaving perfectly here on two systems so far. Don't forget you are using an as-yet unreleased version of FSUIPC5, for the purpose of checking that the LINDA stuff (plus additions) don't crash the sim. Pete

Well, after trying to reproduce the problem in all sorts of ways, and failing, I decided to try using your INI (MP2A version). And, lo and behold, I got the same as you! I checked what was happening, and it is an original bug which has always been there! The problem was that several of the axes assigned in the [Axes.C182] section were not connected:. This from the MP2A ini: A=Saitek Pro Flight Throttle Quadrant << MISSING JOYSTICK >> A.GUID={6B5A2B40-5A5C-11E4-8005-444553540000} B=CH PRO PEDALS USB B.GUID={E0590200-6113-11E4-8001-444553540000} C=Saitek X45 << MISSING JOYSTICK >> C.GUID={6B5A2B40-5A5C-11E4-8003-444553540000} D=Saitek Pro Flight Yoke << MISSING JOYSTICK >> D.GUID={6B5A2B40-5A5C-11E4-8004-444553540000} E=Logitech Dual Action << MISSING JOYSTICK >> E.GUID={6B5A2B40-5A5C-11E4-8002-444553540000} The bug was that this caused a premature exit from the function checking for the Profile name. I'll fix it in an interim update during the week. Pete

Excellent. Okay. Let me know. It looks like I can make a new release in the week, Monday or Tuesday. Thanks, Pete

Seems that you unplugged, or at least powered off, your joystick connections and when re-connected Windows assigned difference numbers to them. You need to use JoyLetters so that FSUIPC can handle this. There's a Chapter about it in the user guide. Sorry, do you mean keys assigned to buttons? Buttons are on joystick devices. Pete

ConsoleWindow will be in the [General] section and it is where FSUIPC remembers the console window size and position for the Log. You must have checked the Console option in the Logging tab at some time. I assume those other entries are in the [LuaFiles] or [Macros] section? They just list the files you have in your Modules folder. Looks like you made copies of those listed there! These are where FSUIPC records the size and position of the different types of SimConnect window, so it can restore them in the next sesion. It's part of the enhancements which will be documented for this release when I have heard from yo that it fixes your Lua problems. Pete

Just scrolling through that. there are two different sections named: [Axes.Boeing B-17G "Fearless Fosdick" Test] There are [JoystickCalibration.c121] and [JoystickCalibration.Lockheed C121A] Which one comes up in Calibrations when you have that aircraft loaded? I skipped most of the rest because there's so much, and they seem to be fairly mised up (one of the reasons for the "Files" option in Profiles mode). However, the ONLY sections with "172" in at all are:all withh C172R as shortname. Assuming you really meant C182 as in your earlier report, there are these sections: [Auto.C182] [Axes.C182] [Keys.C182] (empty, so really a non-section: windows ignores it) [Buttons.C182] [JoystickCalibration.C182] and your [Keys.C182_VH-DLL] [Axes.C182_VH-DLL] so, the only one which seems wrong is the Axes one. Right? I'll try to reproduce it just for 'axes'. Pete

I need more help to understand exactly what your problem with aircraft Specific is, because i cannot make anything go wrong here. With "Profiles" all sections -- Axes, Buttons, Calibrations, Keys -- they are all selected by the same profile name. You can't have a different Profile for each type of setting. With "aircraft Specific", each of those 4 sections are completely independent, ad each can have it's own airxraft using it by different "specific" short names. This is because there's no "Profiles.<name>] section to tie them together. In your problem, were there already settings in the sections you are making assignment changes to? If not, then what you are getting is correct behaviour for aircraft-specific. there's nothing in common between the names associated with each section type. Pete

That's a typical poor calibration. Please folow the numbered steps in the Calibration section of the User Guide. Make sure your Rudder Trim is set correctly too, in P3D. They'll just be the input values. You need to calibrate. Once calibrated it will opeate correctly. Sorry, I don't even know what Sim A is! Didn't you get as far as the Chapter on Calibration? It sounds like you only looked at assigning, nothing else. Pete

Well I'll be looking at it, ad hopefully sorting it out soon. because it no doubt also applies to FSUIPC5 and I am hoping to get a new release of that out before I go away. If i fix it in FSUIPC5 then FSUIPC4 will be similar, so I can give you a link to an interim update then. No, but really "Aircraft Specific" is a small subset of Profiles, in the sense that your current Aircraft Specific settings would be applicable with Profiles too. Okay, maybe not used in the 'spirit' of what Profiles was about, but having one type (i.e. short name same) of aircraft per specific group is the same as having a profile by that short name. The main difference is there's a Profile section which lists the aircraft applied to that Profile, (including by short name), so in your case there'd just be a "list" of one aircraft short name for each. Anyway, you are right. It was for such cases I didn't automatically 'upgrade' all existing INIs to the Profile system -- though that's done for you, quite well I think, just by changing the UseProfiles setting to 'Yes'. Whilst I can understand that, you could just make a safe copy of your INI and try just setting UseProfiles=Yes and see what you get. think 9and hope (?) it will work fine for you. Though whether it solves the problem is another matter. I'm having to look into that. Wow! It IS large! It was to make configurations like this easier to manage that "UseProfiles=Files" was implemented. That's something else you could try without danger if you backup your INI first. With the 'Files' option you'd get an INI type file for each "Profile" (which in your case would be a short-name identified group of aircraft). The files are still kept together, in a sub-folder, but it does make each easir to deal with when/if you ever want to manually edit any. Anyway, thanks for the file. I'll see what I can find. Pete

Okay. After you'ver confirmed with a few flights I'll build a new use release. Thanks. Pete

Ah, sorry! You deliberately use the old system, just aircraft-specific, not Profiles! The latter were really meant to completely replace the much older system, which is a bit archaic in design -- but I couldn't actually discontinue it because folks might not be changing over quickly, if at all with 'settled' setups, and I can't support old versions. But I must admit that no attention has been paid to the older system recently. Sorry. But also any change in any part of the entire mechanisms for both must date back a few releases now. That's why it would have been useful to know closer to when it was first going wrong. Out of curiosity, can you tell me why you don't even want to use the Profile method? It isn't very different, but a bit smoother in use and operation. Anyway, I'll try to fit in time to test out an Aircraft-specific configuration here and see what is going on. I could still do with seeing your INI file please. Pete

Sorry, you have profiles defined but you aren't using profiles? I'm confused. Well it would have been far better to report it before a new major issue. I am pressed to find any time to make any changes to FSUIPC4 for several weeks now. 4.97 was a consolidation of preceding interim updates so I could press on with other urgent things. Apart from the confusion your "UseProfiles=No" presents, for obvious reasons, the more relevant data seems to be completely missing from your report. The Profiles sections themselves, in particular, though with UseProfiles=No they shouldn't be used at all in any case. You seem to be saying that even with Profiles turned off, it is still operating as if they are enabled. Perhaps the complete INI file might make things clearer? Pete