Pete Dowson

As John says, you should enable joy lettering -- either AutoAssignLetters=Yes, or choose your own. There's a chapter about this in the User Guide -- see the contents list. Well, to start you off, I compared the old and new [JoyNames] sections of your INI files. Here's the results: NEW: 0=T-Pendular-Rudder 0.GUID={2CF885A0-88A8-11EB-8001-444553540000} 2=Joystick - HOTAS Warthog 2.GUID={362ABA00-88B5-11EB-8001-444553540000} OKAY, SAME: 1=T.Flight Stick X 1.GUID={49404110-361D-11E9-8008-444553540000} CHANGED: 3=Throttle - HOTAS Warthog 3.GUID={DA1BF960-84A8-11EA-8001-444553540000} to 4=Throttle - HOTAS Warthog 4.GUID={C1582410-6F74-11EA-8001-444553540000} GONE: 2=Logitech Extreme 3D Pro USB 2.GUID={DD5DA7F0-9065-11E9-8001-444553540000} 4=Flight Velocity Trim Wheel 4.GUID={C1582410-6F74-11EA-8001-444553540000} 5=Logitech G HUB G920 Driving Force Racing Wheel USB 5.GUID={1756C4A0-28DC-11EA-8004-444553540000} which you say should still be seen? But it isn't! however, it's ID is not used by any other device so it should be okay if you connect it again. ------------------------------------- So, it may not be as bad as it could have been. Unless you try to add back those three which are disconnected, the only problem is the Throttle unit. Both the ID and GUID have been changed by Windows. Try changing the 4= and 4.GUID= to 3= and 3.GUID=. i.e. 3=Throttle - HOTAS Warthog 3.GUID={C1582410-6F74-11EA-8001-444553540000} FSUIPC will try to force the ID to change to 3 from 4. This should work if no other devices have that ID, which I assume is true with those three removed. -------------------------------------- THEN enable the Joy lettering. Pete

Did you move that connection? Aren't you using Joy Letters (letters assigned to joysticks)? either can mea that when Windows sees new or changed devices and assigns different ID numbers, your assignments in FSUIPC won't match the new arrangement. It may be easy to sort out. Please show us the FSUIPC6.INI and FSUIPC6.LOG files, which you'll find in the same folder in which you installed FSUIPC6 itself. Pete

The documents for WideFS are within the ZIP you must have downloaded -- the one containing WideClient. Just download another copy if you've lost it and its contents! FSUIPC.com. WideServer has been incorporated in FSUIPC since FSUIPC4 days. You only need that with FSUIPC3 and earlier, for FS98, FS2000, FS2002, and FS2004! There "server details" are either the NAME of the server, or it's IP address! The protocol you can choose yourself. UDP is faster than TCP but its transmissions aren't checked and may not arrive in order. Pete

Within FSUIPC you assign to the list of controls (== Key Events) in the assignment facilities. From a Lua plug-in you'd use the ipc.control function, and from an external program interfacing via the offsets you'd use the facilities at offset 3110. For the latter see the supplied document FSUIPC Offsets Status. For the numerical equivalents of the Key Events you need to refer to the list of current controls. I'll have to ask John about the FSUIPC7 one. Pete

Sorry, that was actually irrelevant. My error. The names are provided in text files called locPaks to enable MSFS to be 'localised'. These are in the Official\OneStore\fsBase folder, and the one MakeRwys refers to is en-US.locPak. The entries for Paderborn there are: "AIRPORTEK.EDLP.city": "Paderborn\/Lippstadt", "AIRPORTEK.EDLP.name": "Paderborn\/Lippstadt", "AIRPORTEK.EDLP.state": "NO STATE", So, if anything was corrupted, it would be that. Even so it doesn't explain the varied 'corruption' you appeared to be getting (other than in the Aerosoft version). Pete

WideClient is waiting for Broadcasts from the server to give it the details it needs. For some reason those are not getting through, some something has certainly changed. Please just follow the advice given in the Configure your Network section of the document and provide the details (IP address and protocol) in the INI! If you persist in not bothering to do this we cannot help further! You are just wasting yours and our time! Pete

Aren't K events the normal Key Events known in FSUIPC as assignable controls? (Sorry, unlike John, I'm not familiar with all these Panel XML codes). Pete

But then the order was wrong -- MakeRwys was processing the Aerosoft one first, before any default scenery. So the odd characters were from the default. That's why I told you the date/time and size of my APX BGL so you could compare with yours. I can still compare the binaries for you if you like -- but you'd need to email it to me. That's because now your Aerosoft version is processed last, after all of the default and Asobo and Microsoft scenery layers, just as it would be if it were in the Community folder like mine. Anyway, I've released version 5.124 now, and put a Red warning in the doc about not being able to get data from encrypted hidden BGLs. Pete

Your subject title says you are using FSUIPC4, which cannot be used with P3Dv4 -- FSUIPC4 is for FSX, FX-SE and P3Dv3. If you really meant FSUIPC5 or FSUIPC6, then you need to know that FSUIPC does not support FFB. For that you need to assign axes only in the Sim. If you really want to use FSUIPC for axis assignments and do away with the FFB aspects, then it is best to disable controllers in P3D, not merely de-assign things. For help deciding what's wrong with your FSUIPC5 or FSUIPC6 assignments and calibrations you will need to show us your FSUIPC5 (or 6) .INI and .LOG files, from the same folder are the .DLL module itself (P3D Modules for FSUIPC5, or wherever you chose for FSUIPC6. Sorry, I don't know XP Force. Is that to do with X-Plane? Pete

No, I don't think so. That was always with the default APX.... BGL. as I said. The result you have now is only because your Aerosoft version is overriding the default, as it should. If you switch that off you'll still get the problem with the default, which is why I suggested that you need to reinstall or at least repair your MSFS installation. Anyway, thanks for testing. I note that your other two MS-Store 3rd party addons still do not appear -- not surprising with hidden BGLs -- which looks like making MakeRwys rather irrelevant in the not too distant future. Pete

Okay. Please try the attached version (5.124). I've removed the XML hack for now. The main change is that is allows for 3rd party addons in the Official\OneStore folder as well as in Community. It now orders them like this: Official\OneStore\fs-base* Official\OneStore\fs-base-nav* Official\OneStore\asobo-* Official\OneStore\microsoft-* Official\OneStore\* (other than those above) Community\* Of course only folders or subfolders containing .BGL files are included. If "FindFirstFile" finds no *.BGL files then the folder is not included. I tested by copying my Aerosoft-Paderborn scenery as Aerosoft-PaderbornX in the Official\OneStore folder, but please let me see the scenerylist.txt file when you've run it. Thanks. BTW, looking at the "content.xml" file in the LocalCache folder, which is used to disable official layers if needs be (MakeRwys takes note of this), it doesn't include non-MS/Asobo sceneries in the Official folders. Interestingly it also isn't in the order used by MakeRwys. It appears to be only in the order they've been added by Asobo or MS. At present I have to assume the processing order doesn't affect the data I extract, that the data represents what you see. Pete MakeRwys.exe

That's why MakeRwys doesn't even list the area -- it is looking only for folders containing BGLs. Payware scenery goes into Community as well -- Orbx stuff bought from their site and installed by Central for example. As you say, I can't really do anything about it. I thought they'd only be encrypted to non-owners, that the decryption was automatic if the owner used the file. Did you run Explorer "as administrator" when looking at the folders? Were you logged into Windows as the Administrator? (I think maybe both levels are needed). If I try to copy files out of any of the MSFS folders Windows asks for confirmation that they should be unencryped in the process. I think the folders are marked for auto-encryption, but it sounds like that's a different thing. but it is why MakeRwys needs to be run "as administrator". Anyway, if BGLs don't look like BGLs (or aren't even there ????), then If folks want to use MakeRwys data it looks like they need to get their scenery from anywhere but the MS site, just in case. Else using things like external ATC programs with known defined gates, taxiways, etc, is going to be tough. they'll have to bumble along with default data. Anyway, later today I'll attach a new build of MakeRwys with the ordering of the searching and processing changed. If you can try it and let me see the scenerylist.txt afterwards it would be useful, please. Pete

So how do we see the Paderborn one,? The only reason i don't have the Aerosoft one in the final data is that I a processing the FS-base version afterwards (whichj I can fix). Maybe whether they are so encrypted or not is a vendor choice? If i can't even access the folders they are in I've no chance, encrypted or not. don't forget, it's the folders I'm not seeing, not necessarily the files -- unless the encyption disguises BGLs as something else. Can you see them? Pete

So it was in the scan to find the correct folders to look in, as I expected. It wasn't in those then found to contain BGL files (as you also surmised). Pete

What were the last lines in the log (Runways.txt)? I'll check, but I think the fault offset is in an API function. It may just be that requesting the File find functions to look for the next matching file will cause it to crash unless the provided owning folder has enough room within the MAX_PATH size to accommodate the actual BGL filename. If that is the case i'm not sure what i can do. set my path limit to MAX_PATH - n where n is the maximum likely file name? and what would that be? If may be that your only solution is to make that Registry change so those API functions don't crash. Pete Pete

Very strange, and I don’t understand how it could omit those folders in the enumeration using the regular Windows functions. Are you sure they have normal properties like the others? Are they freeware like Paderborn? If so I could try them here. Making sure I scan fs-base first is easy. Finding invisible folders a lot less so.

So how the heck can I find them?

This is awful! Why bothering with a Community folder if they install marketplace addons in the “official” folders? I could change MakeRwys to make sure all of the Fs-base stuff was processed first, but what on Earth has happened to your other two addons? MakeRwys merely enumerates all folders in each of those two main folders — Official\Onestore and Community. It uses the regular FindFirstFile and FindNextFile, so how can they be missed? Sorry. I don’t know how to proceed. And what about your original problem? File corruption or what? Have you check or repaired? Pete

How on Earth does it get there? It isn’t official scenery? Being processed before the Base scenery means it is overridden by that. The MakeRwys output will have never used it. It is your base scenery which is corrupted and producing those odd characters, not the addon. There’s no way MakeRwys can determine the proper processing order with files being installed in different folders seemingly at random. Maybe you can show me the Scenery list file please. I’ve no idea what’s going on. Pete

Yes, EVENTS as described in the picture you sent! Same as "controls", not offsets as both John and I have already told you! Offsets are data repositories. Events or controls are instigators of actions in the Sim -- those actions you assign to in the Sim or in FSUIPC. You can assign them in FSUIPC as <custom controls>. Enter them as x110B0 and x110B1 (i.e drop the fist 0). Please do read the replies you get here properly. Otherwise we cannot help. Pete

Well, I'm not sure I've done this completely. But I've gone through the code using strcpy_s and strcat_s, specifying MAX_PATH as the maximum, rather than my older simple code. This should avoid overruns in my code and also avoid calling the FindFirstFile and FindFile API functions with an overlong path -- I would guess the latter would have been causing the 409 crashes as the stack overrun wouldn't have been detected till the exit from the containing function. I've not been able to test the changes with an overlong path as Windows stops me adding more subfolders when it detects the path would be too long. So, I have attached the latest version (5.122) for you to check for me, please. If the program does get one where it cannot append the *.BGL for the individual search, or the path plus a specific BGL file name is too long, there'll be a message about "too long" in the Runways.txt log. It logs the length of the longest path used for a BGL search in any case -- my attempt to make one too long resulted in that being 253. Windows wouldn't allow me to lengthen any of the folder names beyond that. I assume because it needs at least 7 for some system added file just in case. Pete MakeRwys.exe

Further to my message above, I have seen that the QW787 models place an enormous load on Simconnect. For some reason they fire hundreds of events every minute. Logging the Events in FSUIPC reveals them. It's worse than the PMDG ones which do similar things. If Simconnect is stalling (see the FSUIPC4.LOG) you can make FSUIPC wait longer by changing SimConnectStallTime in the [General] section of FSUIPC4.INI. see the Advanced User's Guide, page 12, for details. You could also try adding UseAIClient=No or UseAIClient=Yes to the same section 9or change it if it is there). As I final resort you could just stop FSUIPC supplying AI data to RCV4 by changing (or adding) this: ProvideAIdata=No Pete

I found this: https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#maximum-path-length-limitation Apparently you can change the Registry to enable paths to be longer than MAX_PATH. Only trouble there is that I don't see a way of determining what that max path then is. If there's no limit that won't work for the way MakeRwys builds its tables in memory, and I'm not changing the whole thing. So i'll go ahead with my proposal -- limiting the paths to MAX_PATH and avoiding any which appear to be longer. I'll log anything like that I see in Runways.txt, and the length of the Max Path seen along with the max actually used, at the end. Pete

That offset is a timestamp telling it when trying to read some details of AI traffic -- either which runway is in use by AI, or what the details were of other AI (tail number or flight according to your settings). The timeout could occur because either no AI traffic in range has been assigned a runway, or the AI one being requested has been deleted -- either because it went out of range or because a Traffic Limiter or other program deleted it. With a highly loaded system it could also be caused by FSUIPC not being able to get the AI traffic data for a certain time. You can adjust that in the FSUIPC INI file. Check the FSUIPC log to see if it says it had to restart traffic scanning. That means SimConnect is being overloaded. Really this should never cause a program to crash or hang, and certainly not produce an error message box. But I do seem to remember, a long long time ago, one version of RCV4 did have such a problem. Maybe there's a history somewhere of RCV4 support requests and exchanges you can check? Didn't Ray point you to a source for old RCV4 problems? There used to be quite a big forum with Ray a main participant. [LATER] Found it! It is still there, on AVSIM. Didn't you look? https://www.avsim.com/forums/forum/135-radar-contact-support-forum/ and searching there for D008 I immediately found three relevant threads! Take a look at those please. Pete

Well, those addons go in the Community folder. That's how I see Paderborn, anyway. I thought all add-on scenery and other add-ons, even John's new L:Var module) went there. Only the official release from Asobo goes into the Official\OneStore folder. Where is your Paderborn? MakeRwys produces a SceneryList.txt file (it's own constructed version of the Scenery.cfg file, replacing the one it uses in P3D generated by the Lorbi-si program). The scenery is processed in the order listed there -- all the fs-base stuff first, then the fs-base-nav files to add the frequency data, then all the other airport files in the Official\OneStore folder, and lastly all those in the Community folder in the order of the directory. Please look at that file. It seems there's certainly something really odd going on on your system. Pete