Pete Dowson

Isn't there some parts of the SimConnect SDK providing details for managed languages. I'm not the right person in any case -- my languages are nly C, Assembly code, and even machine code. Pete

Okay. Thanks. That sems to imply that offset 3102 isn't working correctly. I'll take a look. Pete

There is the original crude text display (basically using the same one as the scrolling ATIS one, but possibly multilined if new line or return codes are implanted. That window can be resized and even undockey but otherwise, by dfault stretches right across the top. I will be pressing L-M hard to enable the few remaining features I need. Obviously they were more occupied with getting the 64-bit conversion working and making a release. Yes, colours might be nice but I probably won't press my luck -- just a mention rather than a "demaind" i think. ;-) Pete

INI files can only have one parameter with the same name in any one section. Those parameters are "UpdatedBy", "FSversionUsed" and "SimConnectUsed" and get written every time you start the program -- it's just a way of me seeing what you are using even if you don't supply a log file. Pete

Does the FSUIPC log file show any problems. Note that I have about 600 layers of scenery files, and it takes at least that for me even on a fast PC with SSDs. Pete

No, the offsets are part of FSUIPc, populated by information from FSX. The point of FSUIPC is to allow folks to interface to FSX in a compatible manner across versions of FS. If you want to interface directly to FS, it isn't anything to do with FSUIPC. You need to refer to the FSX SDK. Pete

I don't think I understand the "issue" well enough to fix it What would FSUIPC have previously seen when you operate the BAT switch? Is it a button numver? A virtual button perhaps? I really don't know what SPAD does -- maybe its author or support can investigate whether it is something I can do. I see Thomas found the same, but without knowing more I'm not sure what I can do. I was planning on releasing version 4.966n properly next week as 4.967, along with the 64-bit version for P3D4 at the same time. I would rather fix it before then than have to change both soon after. Well, trying that would probably tell me all I need to know, so it is important. Otherwise it just won't get fixed. Bumping this thread "so it won't get lost" is a bit pointless without doing that first. Pete

All your profiles are in the INI file UNLESS you opted to use separate files. If you did then they are in a folder called Profiles in the Modules folder.If you didn't, or just don't know what I'm talking about, don't worry, just use the INI. Pete

Looks like a corrupted P3D install., so reinstalling P3D then FSUIPC is a good idea. Pete

I've now checked. The SCENERY.CFG file for P3D4 is identical in format to P3D3 etc and in the appropriate ProgramData folder as the others, so the changes to MakeRunways were minimal. Releasing as version 4.70 now ... Pete

Well, FSUIPC will be doing the same thing each time. Is this with all aircraft? Always test things with default aircraft. Pete

The programming interface always was and always will be free to users (the commercial programs using it pay a fee normally). The folks who purchase FSUIPC do so for the User facilities, not just for its interface, which fewer and fewer programs use. Pete

Thanks. I can't easily do that with SimMarket, which is a commercial business and involved in VAT, Tax etc. But personal contributions can always be made via PayPal, just to petedowson@btconnect.com. Yes, the whole FSUIPC4.INI file could be renamed FSUIPC5.INI and copied into the P3D4 Modules folder. Pluse copying the complete 'Profiles' folder if you are using separate files. That is exactly what happens in any case. FSUIPC registers its interest in all the variables just the one and SimConnect sends then when they changes (and by more than a given delta value for many -- e.g. you don't need IAS to the .001th of a knot, etc). AI Traffic are a bit different. SimConnect notifies when it adds or removes one and then FSUIPC has to act on that -- requesting the traffic data on add and removing it from its lists on remove. Polling was performed in FS9 and before when FSUIPC was ferreting in the sim's memory for data so it could be mapped onto the FSUIPC offsets. That was te only way then. SimConnect changed all that for almost all values in 2006. Polling is used for joysticks and buttons -- those need reading via DirectInput calls regilarly (but only one call per device, all values come together for up to 8 axes, 4 POVs and 32 buttons. Are you seeing degradation with FSUIPC running? You shouldn't. Pete

Anyone with multiple controls should use JoyLetters so that FSUIPC can retain the same assignments over changes like unplugging devices and updates to Windows. Well, I know nothing except hardware malfunction which could make things "suddenly" stop working. If you aren't using it for a while and it stops then that's different -- probably power saving on the USB hubs. Check the power management settings in the Windows Device Manager. It sounds like you are mixing assignments in FSX and FSUIPC. DO NOT DO THIS. Assign all in FSX or all in FSUIPC (and disable controllers in FSX), otherwise you will have conflicts. And why, exactly, is it "too long"? Why have you enabled additional logging? Anyway, please see the Download Links subforum above and give 4.966n a try. That will make a .csv type file which you can attach here. Pete

RC4 should work fine if it is okay in P3D3. The saving and reloading of flights might be a problem -- it probably wants .flt files not .fxml files, but that's the same in P3D3. I might be able to "fiddle" that but no one has mentioned a problem. MakeRunways will not have to be 64-bit, but will need changes for folders and file formats. I'll get to it in due course. There are other things too. My PFCHid.DLL and PFCFSX.DLLs will have to be converted to 64-bit -- that's a bigger job. I can't do everything at once, FSUIPC5 being the priority. If you are using the same scenery in P3D3 and P3D4 then the same MakeRunways results files should be fine for RC4 in the interim. Well, MyTraffic6 works okay, as does most sceneries from FSX/P3D3. There are problems with UK2000 sceneries which have assembly code internally, like Heathrow and Manchester. Maybe all of them for all I know -- not tried them all yet. Pete

No idea what will happen. All functions in those DLLs are there to be called by other functions in other DLLs. And most of FS these days is object-oriented, so you need the pointer to the object. I have hacked into many parts of FS using a disassembler and use a fair number of them, but I've never managed to get into ATC.DLL. With a disassembler and an thorough understanding of assembly code and OOM techniques you can maybe fathom out the simpler functions which you could use. But it is a long long job and takes a lot of patience. For FS98 to FS2000 (the first NOT to have the Globals I could refer to) then to CFS1, FS2002, CFS2 and FS2004 (=FS9) each time took months to find what I needed to populate the FSUIPC offsets and to enable me to make things happen. Really, months! It was a good job I got onto the Microsoft Beta list so I had early access. FSX introduced SimConnect after I had talks with Microsoft over in Seattle. I provided a list of everything it should do so I could stop hacking into code and deliver an FSUIPC with mainly user facilities, NOT "offsets" etc. Unfortunately they stopped developing FSX before delivering it all. Now I am 74 years old and too old and incompetent to do any more serious hacking, so I'm grateful for SimConnect and most of the offset values are obtained from and set via SimConnect. In that sense FSUIPC4 is just a "compatibility layer" for programs originally written before FSX. Pete

Yes, identically, except that the Lua Display on screen options will be rather limited until I get more facilities from L-M as that area is via digging into the code in FS9 - FSX- FSX-SE and 32-bit P3D (all similar in that area). (That was one of the exceptions I forgot to mention). Pete

I think you misunderstand. It isn't so much whether they use offsets defined by FSUIPC -- hardly any aircraft uses FSUIPC. The FSUIPC offsets hold values from FS, so it is simply whether they use default FS systems or implement their own. Simpler add-on aircraft use FS values for everything, slightly more sophisticated ones use FS for some parts, but do their own thing for others where they think the FS system isn't suitable, and some implement nearly all their own systems -- PMDG, FSX and, yes, some of the later more complex Aerosoft ones fall into this last category. The earlier simpler Aerosoft Airbuses probably use FS values. Pete

"Offsets" are locations in FSUIPC, not in FS. They've not been in FS since FS98! All the offsets you might ever want are listed in the Offsets lists provided. They have served folks well all these years! What is it you are missing? The BOOL value was originally 4 bytes. it's only ever 0 or 1 so it can be 4, 2, or 1 byte. There's a bool too which is different, and how it is defined depends on the language and the header files you use. In FS98 days, which is how far offset 0264 dates back, it was 2 bytes in the FS98 "GLOBALS.DLL" which is where all the really old offsets come from. FSUIPC's job is to maintain continuity, compatibility from release to releases. Keys aren't needed for Add-Ons these days. I learned to trust folks to own up for payware. Pete

You either need the FSUIPC SDK, or Paul Henty's .Net DLL. I recommend the latter. Pete

Does FSUIPC make a log file? If so, please show that. And please try FSUIPC 4.966n (in the Download Links subforum). Pete

The log shows a perfectly good session, not one which crashed at the start but one which ran through to then end successfully. What looks more likely is that FSUIPC isn't even starting now -- the crash details you provide show that the crash occurs at its entry point. Your DLL.XML file shows one possible reason. The FSUIPC entry should come last -- that's where its installer puts it. seems you've installed the PMDG 747 subsequently. Try re-running the FSUIPC installer, which will fix the DLL.XML for you. Pete

I didn't need to "reconsider" as I hadn't decided way back at the beginning of the year. There will be an FSUIPC5 for P3D4, but first release won't coincide with the rather rushed (in my opinion) release of P3D4 on Tuesday. And FSUIPC5 will be a new product, not an upgrade. It's been too much work to have it as just an upgrade. The user weather stuff is stripped out, and some other facilities do not yet work (mouse macros, menu diversion, frictions just to name three). They are dependent on further P3D development. Pete

FSUIPC won't know whether what's calling it is 32- or 64-bit. The IPC part of the name means "inter process communication", and 32- and 64- bit processes can talk using its protocol just the same as 32- and 32- etc. If you are using that old LIB (going on 19 years since it started!), then the small source is provided in the SDK. You'd need to recompile it as a 64-bit version, adjusting things in it to match. The structures which get sent should be identical though, as FSUIPC won't be able to handle 64-bit pointers etc. I have a 64-bit version of FSUIPC now running, and all 32-bit client applications work fine with it. I think it should be reciprocal? Have you checked out Paul Henty's .Net DLL interface? I think he did a 64-bit compatible version. Pete

Are you developing a program to interface to FSUIPC? Actually, for PMDG aircraft it would have to be by control -- a PMDG added control 9custom control). You'd need to work out what that looks like from the NGX SDK details (see the .h file). With default aircraft and most add-on aircraft you can send controls or write to the appropriate offsets. Cutoff is simple a zero Mixture level, and there are offsets for the mixture for up to 4 engines. For a jet, "idle" would be 16384 in those (the equivalent to 100%). You can send any controls via offset 3110. Please read about it first. Sorry, I never found a way to do that. est to use one of the ATC add-ons in any case. The default one is very poor. Sorry, I've forgotten (I blame my old age and files dating back up to 17 years). I took a look in the provided LIB source to check, and it only contains FSUIPC_Read. Certainly there's no difference at the FSUIPC end -- it must have been something in the LIB once. Does it link ok? Most folks these days use Paul Henty's .Net DLL, which is constantly improving still. You might like to check his subforum above. Pete