Pete Dowson

Yes. In the INI file there will be a section with a heading like [Profile.Single Engine] (or whatever the profile is called). In there will be a list of the aircraft assigned to that profile. Just delete that line. If you do this whilst Fs is running just be sure not to have the aircraft loaded at the time. Safer probably to do the editing before starting the sim. Not for FSUIPC, but you will get all osrts of strange tihngs happening. And there's absolutely no need. Assigning in FSUIPC to the FS controls (Axis ... Set) and not calibrating is exactly the same as assigning in FS and not calibrating. You can calibrate either way. Without knowing what upsets the A2A aircraft I couldn't say. Pete

I don't know of any more outstanding problems with the VRI facilities in FSUIPC, so LINDA must be looking at that themselves. No one has contacted me since the FSUIPC VRI problems were fixed in 5.102. Thanks for the logs. Why is the whole CSV file crossed through? And it certainly is no larger in any case than when youfirst successfully posted it as a file. What, no ZIP capability? How did you unzip the update? Pete

For anyone else reading this thread, who doesn't want to retreat to an old version of FSUIPC4 and hence not be able to get support, please note that thanks to another report in another thread, and the cooperation there to identify the cause, it will be fixed in an update for FSUIPC4 by the weekend. Looks for updates in the Download Links subforum. Pete

Please do always check the Download Links subforum for updates. That was reported and fixed in version 5.102a. Pete

Thanks to your log I think I've discovered the problem. It was miscounting the devices when those of the same type (your Button Box) were split. The Registry scan details shows that the HID scan results sees one of those first, then the other two later, with other joystick devices in between. The other two were being counted against the wrong type of device! A silly error, in fact, but one which hadn't had any known consequences until the two reports here, this week. Unfortunately the first reporter didn't bother to do the logging I asked for and just retreated to an old version of FSUIPC4. Pease download this file, and copy the FSUIPC5.DLL from inside the ZIP into your P3D4 Modules folder. FSUIPC5102b_TEST.zip Please confirm one way or the other. Don't remove those logging lines just yet, I'd like to see the Log and the CSV file after you try it, successful or not. If successful I'll apply the same fix to FSUIPC4. Thank you! Pete

That's am p;der and unsu[[prted version. It was before the revised Jostick Scanning, a change which was made necessary because of undetected devices, like both parts of an X-55 or X-56 system. It also, first the first time, then detected both my Bodnar cards. The change was a complete re-write of the scanning -- necessary because the old system, born in the previous century, had over the years become cumbersome and too weird and complex to change 9even i no longer understood what it was doing!0. So the reason some of your devices don't work with the new system needs my urgent attention. They are plain text files and ZIP up to very small ones. That's always the best way. (the CSV file would have been no bigger that it was last time, where you did succeed). Anyway, thanks. i'll try to use them the way they've arrived. I'll be in touch as soon as I have a clue about the next step. thank you very much for helping to resolve this issue. Pete

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