Pete Dowson

Not really talking about additions. I'm looking for the same information as I always did -- only stuff in airport records, nothing else. The ID codes for the Runway entries and the TaxiPath entries are different. I can see that. They are also different sized structures. So this certainly means a different structure format. Whether there's additional information there I do not know, and I don't think "materials" figure in basic airport data, do they? This is only with a pre-P3D4 BGL re-compiled with the new BGL compiles, after using ADE 1.75 to decompile the original. With a scenery designed explicitly using new facilities, I might not even get the parts I can currently see. I just don't know at present. I will be looking into it, of course, but if things aren't reasonably quickly discernible I would have to shelve it for a while, and preferably wait either for some young hacker to decode it, or maybe get L-M to suply documentation. Pete

Can you please tell me the VERSION number of the FSUIPC4 you use in P3Dv3? Maybe you aren't up to date? The scanning in version 5.102 is identical to that in 4.968, the current supported version for P3D3. A similar problem was reported by another poster here, in another thread, but with FSUIPC 4.968. I asked him to do a little test for me with certain extra logging details added, but instead of that he retreated back to 4.962. Very strange behaviour. I cannot support him. All I need is extra logging to show me WHY it decided to leave devices out. The JoyScan file shows me they should have been retained. If you can work with me on this I am sure I can fix it. First step is that extra logging: Add these two lines to the [General] section of the FSUIPC5.INI file: Debug=Please LogExtras=x200000 Then just run it as before. Show me the resulting LOG and CSV files, please. If I can see something that helps, I'll fix it and send you a link to download a version to test for me. If not I may have to add more logging. Okay? Pete

I don't think FSUIPC INI files have anything to do with FlightKeeper. I suspect FlightKeeper just doesn't recognise the P3D version. What "fix"? I don't use FlightKeeper. Sorry. Pete

Try the AVSIM FSX or P3D Forum, as appropriate. Pete

My tests here with pre-P3D4 sceneries recompiled with ADE 1.75 using the P3D compiler are in direct contradiction to all the reports above. The resulting Runways.TXT file is certainly not bereft of all information. Everything is found AND the same as in original (pre P3D4 compiled) file EXCEPT, crucially, all the Runway data, and the Taxiway paths. The basic Airport Data is there (name, country etc), as are COM frequencies, TAXIPOINTS, GATES and TAXINAMES. If this is the case with BGLs specifically designed for P3D4 (rather than a recompiled P3D3 compatible format) then the amount of work trying to decode the binary is a lot less than if there’s no clue at all – as appears to be the case in your results. It won’t be something I would be willing to tackle without format information being supplied. I might ask L-M if they can supply this, otherwise it will wait for some of the clever person with much time on their hands to do the job. Meanwhile, for my use of P3D4 I will stick to my P3D3 sceneries used in P3D4 by using effectively the same SCENERY.CFG (after the defaults). Pete

You can just copy over your FSUIPC4.INI file and rename it as FSUIPC5.INI. Nothing is deleted. The default INI has no assignments or calibrations, in any case, and few weather parameters in the [General] section. User weather filtering facilities aren't provided in FSUIPC5. Pete

It makes little sense to me that it can wor in FSX, let alone P3D. But the differences between what it does for FSX and P3D version 3 are non-existent. It just detects which Sim it is by the version of FSX.EXE or Prepar3D.exe in the directory it is running in, using this information to determine the ProgramData folder name to use, Maybe it is AddOnOrganizer which cannot cope. For P3Dv3 you shouldn't be using it in any case. To use AddOnOrganizer for P3Dv3 a new version is required AND an update to MakeRunways. Additonally, I've now found that L-M have changed the scenery formats for P3Dv4 and new P3D4 dedicated sceneries arriving cannot be decoded using the information I have. It will be a very big job, because there is no documentation of the new internal formats. Decoding by hand takes many hour of intense detective work and there's simply no way I can do this in any reasonable timescale. That is a more pressing need too FSDT, for example, press ahead using the new tools. Pete

FSUIPC version 5.102 fixed some problems in COM, VRI and HID functions, related to handles in 64-bit more being 64-bit and Lua numbers all being floating point, with less than 64-bit numerical capacity. Please always look for updates first when you have a problem. Solutions often arrive beforehand. 5.102 replaced 5.101 on the 12th, 9 days ago! And further improvements and fixes (including one for event.com) were included in the interim update 5.102a, released today in the Download Links subforum. Pete

Two ways. If you want to just wait and detect when it is set or cleared, use event.offsetmask with the mask set to 2^5 (i.e. 32, or 0x0020). If you just want to read it and test the bit, just read it then using logic.And to isolate bit 2^5 (i.e. "and" it with 32 or 0x0020). If the result s non-zero the bit is set. I suggest you explore the library facilities a bit further than the first few pages, and maybe look at some of the many examples. Pete

So you refuse to help me make it work with 4.968? Why is that? I'm not able to support you if you retreat into using old versions. All I asked for were for you to run it with a couple of lines added to the INI file and show me the LOG file resulting. Why are you refusing. I am not able to help you with any old versions. I don't understand your attitude. Pete

I thought I'd explained that. Seee this, repeated from above: The problem is that those swap buttons use a sequence of 3 events ending with "FREQUENCY SWAP", which doesn't work. It seems the code is supposed to convert this into the correct specific swap event (as the radios in other aircraft do in the first place)), but for reasons unknown it does not do this if FSUIPC is monitoring events, as it always does so it can log them and provide user facilities through them. The work-around is for FSUIPC to perform this action if it sees nothing else do it. This does induce a small delay (a third of a second), but it cannot be immediate in case it is fixed elsewhere and you get a double swap action as a result. It has to wait and see if the correct action is taken first. Note that the proper events when sent using keypresses or buttons do work. You just should not assign to "FREQUENCY SWAP" which seems to be broken.

I understand that, but I've got no other answer. Sorry. Maybe it is timing related, because the random number generation is seeded from the elapsed time in milliseconds when the facility is initialised. I can look to make it a bit less repeatable by adding time of day and date and so on to the seed, if it will help make more sense? Pete

Yes, inthere, not in another PC. The reason it is not possible should be obvious. You'd have to share your ProgramData folder on the Server (which is not allowed by Windows), and all the folders containing scenery, because when you run a program from nother PC it is running in that PC, NOT in the PC where you are getting it. All you were doing is getting Windows to fetch a copy of the EXE to the other PC so it could run it there. Pete

No, it was just in the "not yet available" list, awaiting Active Sky's implementation for P3D4. Then they released the Beta AS for P3D4 and I was able to update FSUIPC5 and test. Why dont you read the documents wghich come with FSUIPC5 telling you these tings. It would save botyh of us a lot of wasted time! Well, I think you should remove the spaces, as I said. And then it is perfect PROVIDING THAT the top level ProSim737 foldere is shared for writing as "ProSim737". You never confirm this. Pete

The 64-bit solution for external 64-bit programs interfacing to FSUIPC5 is now available in Download Links subforum, and in the main SDK package also downloadable through the Schiratti "Dowson" page. It includes a working "Hello" demo program. Pete

You CANNOT run it from anywhere but the base folder of the simulator program you wish to generate files for. That has always been the case and it will remain the case. Please do read the document supplied with it! Pete

Well, if the ProSim737 folder on F is shared as "ProSim737", yes, apart from unwanted spaces. But in that case why are you teling me about drive F and its name 'programs'? Why are you saying that? It is NOT true! It was added just after ASN for P3D4 came out in a Beta release, in FSUIPC 5.101. The current release is 5.102 and there's an update available to 5.102a. Pete

Please download version 5.102a from the Download Links subforum. It fixes this problem. Pete

Please download version 5.102a from the Download Links subforum. It fixes this problem by using a work-around. The problem is that those swap buttons use a sequence of 3 events ending with "FREQUENCY SWAP", which doesn't work. It seems the code is supposed to convert this into the correct specific swap event (as the radios in other aircraft do in the first place)), but for reasons unknown it does not do this if FSUIPC is monitoring events, as it always does so it can log them and provide user facilities through them. The work-around is for FSUIPC to perform this action if it sees nothing else do it. This does induce a small delay (a third of a second), but it cannot be immediate in case it is fixed elsewhere and you get a double swap action as a result. It has to wait and see if the correct action is taken first. Note that the proper events when sent using keypresses or buttons do work. You just should not assign to "FREQUENCY SWAP" which seems to be broken. Pete

Please download version 5.102a from the Download Links subforum. It fixes this problem. Pete

Overworked for sure. Just about finished catching up after my (short) break, and investigating and fixing some bugs or P3Dv4 problem solutions. Will just get 5.102a, or maybe 5.103 out, then next on my list is the 64-bt user library, and sorting out MakeRunways to deal with the new airport data formats -- that might be a big job. Maybe tonight or if not, tomorrow morning. Pete

The source for the LIB is provided. Why not just use that directly? It's small enough to just cut and paste into your code. And you have full control then. I've no idea what "NetBeans" means. The stuff I provide all assumes you use Visual Studio. If you are using some sort of .NET managed code you must use the .NET DLL by Paul Henty -- please see the subforum above dealing with this. Sorrry, but that's unreadable nonsense to me. If you want me to read things please make sure it's at least readable. Pete

The PMDG 777? My understanding is that all three PMDG Boeing products, 737, 747 and 777 use the same methods for their throttle axis control inputs, so the same methods in FSUIPC should apply and work with both. Assign to Axis throttle1 set (etc) in FSUIPC, do NOT calibrate -- i.e. press "RESET" for each throttle in the 4 throttles page in the Calibration tab both with AND without your profile selected. Then, if it works with your P3D assignment, it works through FSUIPC because it will then be doing identical things. That is the way it works in FSUIPC for every one else. It will work for you unless there's something wrong with your 777 installation. Post your FSUIPC5.INI file when you've done, and I'll check it. In your previously posted one you had all your axes assigned Directly (not good for PMDG) AND all Calibrated (not good for PMDG) -- and all without any Profile specific selection at all. In fact, if I now understand you correctly and you actually had problems with no assignments in FSUIPC but all in P3D, then it obviously is a 777 problem. Try uninstalling it and reinstalling. Pete

Well, the INI entries look different. It certainly doesn't match either the Log or the CSV file! Are you sure they are after the same session? Ignoring the INI file and just going by the two files in agreement: 172 Device acquired for use : 172 Joystick ID = 2 (Registry okay) 172 2=Joystick - HOTAS Warthog 172 2.GUID={8868DD00-21F4-11E7-8007-444553540000} 172 Device acquired for use : 172 Joystick ID = 2 (Registry okay) 172 2=Throttle - HOTAS Warthog 172 2.GUID={8868DD00-21F4-11E7-8007-444553540000} The problem as you can see above is that both the Throttle and Joystick are registered with the same joystick ID and the same GUID (which is supposed to be unique). The registry entries for these devices are corrupted. The entries for the Rzer Orbweaver Chroma look rather stange too: Razer Orbweaver Chroma, {4B768EC0-21F3-11E7-8004-444553540000} Razer Orbweaver Chroma, {4B735A70-21F3-11E7-8001-444553540000} Razer Orbweaver Chroma, {4B752F30-21F3-11E7-8002-444553540000} Razer Orbweaver Chroma, {4B75CB70-21F3-11E7-8003-444553540000} Razer Orbweaver Chroma, {52F97860-21F3-11E7-8006-444553540000} Five entries for the same device seems rather, er, excessive, especially with two of them being completely unresponsive, but it is just possibly that devices can make those sorts of connections I suppose. I'd strongly advise unplugging them all, then going into the Windows Device Manager and removing every instance of both those devices, along with drivers if the option arises, Then re-booting the system and reconnecting them so they will be re-initialised in the Registry along with their drivers. Pete

Sorry, that was a typo (see FSUIPC4 at the beginning of the reply and just 4 lines above, where it should have been obvious it was a typo). So, it's the same request but with the FSUIPC4.LOG I've yet to see. Please just update the INI first as stated. Pete