Jump to content
The simFlight Network Forums

Gil

Members
  • Posts

    38
  • Joined

  • Last visited

Posts posted by Gil

  1. Windows is a strange animal when it comes to path length. Some parts of the OS seem to allow paths of any length (NTSF doesn't care), but others balk at anything over a certain limit. MSFS has exasperated this problem by putting its data files in a folder that's already long:

    D:\WpSystem\S-1-5-21-1756615077-2606723803-1545869702-1003\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe

    I've had any number of programs complain about path length when trying to install software within those directories.

    If the program allows me to specify the install path, I have a sym link defined to shorten the path to something a lot more reasonable. For example:

    mklink /D D:/msfs "D:\WpSystem\S-1-5-21-1756615077-2606723803-1545869702-1003\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe"

    That creates a soft link in the root of the D drive called "msfs" that looks and acts exactly like the long path name. The path to the community folder becomes"

    D:\msfs\LocalCache\Packages\Community

    That helps a lot of programs, but doesn't complete solve the issue. It's still possible other programs will create long directory paths that exceed a program's limits.

    I think your method is the best method. Checking for possible overruns and excluding those directories that are too long shouldn't hide too many scenery files or else other programs would he having these issues already.

  2. Pete,

    I am fairly sure that I know the cause of my problem, now that I've been able to reproduce it. It was at least partly due to an error on my part, but I think my error may have exposed a problem with the MakeRwys.exe utility.

    Somehow (though it escapes me how this happened) I ended up with a copy of the WorkingTitle source files in my Communities folder. So when MakeRwys searched the directories within the Communities folder, it recursed the folders with those source files looking for files it would normally read for runway data.

    The folder structure within those source files is deep.

    The last folder MakeRwys searched was 294 characters long:

    D:\WpSystem\S-1-5-21-1756615077-2606723803-1545869702-1003\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\Packages\Community\fspackages-main\src\workingtitle-vcockpits-instruments-navsystems\html_ui\WorkingTitle\Pages\VCockpit\Instruments\NavSystems\Shared\Templates

    MakeRwys did a directory query on the directory and found four child directories:

    1:    Altimeter
    2:    AttitudeIndicator
    3:    HSIndicator
    4:    XMLEngineDisplay

    The next directory the program would have searched would likely be 304 characters long. I'm just guessing here, but that might be a problem. Is it possible a variable field overflowed? That might have corrupted other data, or even the stack, if the variable was stored on or near the stack. If so, that could have caused the fault that was reported.

  3. It took almost a whole day to download MSFS, but that's done, and MakeRwys.exe now runs just fine.

    As to the cause, I'm stumped. The mangled reg key call still exists even when MakeRwys works, so that apparently was a false lead. The only thing I can think of now is that perhaps a file that MakeRwys depends on was corrupted. I noticed this morning when I looked at the Procmon log from yesterday that MakeRwys had opened a file within fspackages-main within the Community folder last before the fault, so maybe there was a bad file there.

    I haven't reinstalled that package yet, so that hasn't been tested.

    If anything else comes up, I'll let you know.

  4. Pete, I thought I'd let you know my status as I'm working to resolve my issue. I used procmon.exe to see what MakeRwys was accessing when it stopped working, and it appears that it was trying to read a registry key named

    HKLM\Software\Microsoft\Windows\CurrentVersion\Appx\PackageSidRefMicrosoft.FlightSimulator_8wekyb3d8bbwe

    Of course there is no such key since it appears that the name is missing a slash between "PackageSidRef" and "Microsoft.FlightSimulator_8wekyb3d8bbwe." There are other similarly named keys, but even that one does not exist. 

    Snag_68d9eb.png.0223e258c731e6f889a3a6b0050c81cf.png

    I guess that Windows is trying to access a file that MakeRwys is requesting through a sym link, and is coming up short. I couldn't find where the mangled registry key name came from, but I suspect some registry magic going wrong.

    So, I'm reinstalling MSFS to see if that will correct the problem. The reinstall seems to be taking longer than the original install because the download speed is a little sluggish. So far I have about 10 out of 154Gb downloaded, so it's going to be a while.

    I'll let you know how it goes once the program is fully restored.

    Gil

  5. Just now, Pete Dowson said:

    I don't know. Did you run it "as administrator"? If not you'll need to.

    And please check with the Windows Event Viewer. Look in the Windows logs -- Application to see if there are any entries for MakeRwys. If so, copy the details to a reply here for me, please.

    Yes, I'm running as admin. And I was just looking at the event log and see two entries each time I run the app. One event is at an "Error" level:

    Snag_1251d1.png.380d7b760553517f6760e3beb70abc16.png

    The other is at an "Information" level. I had to take two screen shots for it to get all of the "General" data.

    Snag_136d05.png.5e0512ea6e3c46314d706dbd8fcf3f06.png

    Snag_13933b.thumb.png.cfbbe4af0cbea78cbd5a3b8233dbee2e.png

    Gil

  6. MakeRwys 5.12 is failing to create files from MSFS 2020 system.

    When I run the application a dialog box appears that looks like this:

    Snag_580d0.png.d23d0b61d5227a8e93f06a6fb5cb2115.png

    This dialog box promptly disappears. (The first run after resetting the system seems to go a little longer than subsequent runs before the next reboot.)

    The application creates a zero length Runways.txt file in the current directory, but nothing else.

    I may be the only one having this problem, but what can I do about it, if so?

    Gil Yoder

  7. I am having a problem using FCR MSFS in which recordings are not being saved. This happened after installing the update to v. 4.5.2102.26.

    While in a flight I press the red circle button to start a recording. At the bottom of the window I see "Recording..."

    Snag_58aa73b.png.0dbf6f8ef76f8acf56983fddad93f1fe.png

    Then I can press either the red circle button or the white square button, and then I see "Load Flight file for play a situation."

    Snag_58c0062.png.94df95e0f8220a183e8ecf9371e5f575.png

    There is no prompt anywhere at anytime to save a file or give it a name.

    This occurs whether or not I run FCR MSFS in admin mode.

    What can I do to fix this?

  8. @crbascott, It's not so much something I know of that I want or need. Rather it's something I noticed that I'd like to know what it does. If it satisfies a need so much the better.

    It took me awhile through experimentation to determine what all of the other dials did. I am just wondering if there is something I've missed with this dial or if it's simply nonfunctioning.

    Gil

  9. 11 minutes ago, blacklabelbraai said:

    @Gil, does the user manual not make any mention of this?

    I don't think so. The manual mentions the Control window, but does not describe each option.

    13 minutes ago, blacklabelbraai said:

    @EliGrim's suggestion is a good one.

    I agree. I suspect it is the right answer.

    15 minutes ago, blacklabelbraai said:

    Please let us know how it goes.

    Unfortunately, it doesn't go well.

    I set the range rings to 10 miles and the variable range to 15 miles. This is the result.

    2020-01-02_9-55-26.thumb.png.600692b1e35a65e87b23166ed98c95bc.png

    If the range ring exists it would show between the 10 and 20 mile rings, but nothing I do makes it appear.

    Gil

  10. Thanks to everyone with all the suggestions. I just handled about one hour at LAX at 1600 and managed to land all of the aircraft during that period with only one or two goofs. Slowing the planes at first to 200 kts helped me to build up confidence at the final sequence of commands.

  11. 21 minutes ago, DeltaVII said:

    Apart from just reducing the traffic load, do you slow them down? I know it's difficult to find the right timing on the ones coming in hot at 240 kts as slowest practical speed, when you have slowed down the other traffic to around 160 to 180 kts. A useful command that I - unfortunately - hardly make use of is the CROSS XXXXX AT AND MAINTAIN XXXXX command. And you can, of course, send planes into a holding pattern and stack them up at a waypoint. I've done this primarily when it gets so busy that I might lose control over my airspace.

    Reducing speed is a good idea. I hadn't thought of that.

    As for traffic so far I haven't been successful enough with a little bit of traffic to allow more than a small handful of approaches to be generated. It might help though for me to create a very light schedule similar to Mark's second approach tutorial. That might help me become more familiar with the terminology before dealing with more traffic.

    Mark mentioned the CROSS AT AND MAINTAIN command in the third approach tutorial, so I have been using it. 

    Thanks for your suggestions.

  12. It's surprising to me how difficult doing approaches is in Tracon!2012 compared to departures. I just tried really today for the first time, and I just couldn't understand why it was so difficult to say the right things at the right time to land the aircraft.

    It's occurred to me though that it's probably due to @Mark Hargrove's excellent tutorials on the subject. I must have listened to them a dozen times to get ready for my first try, and it seems so easy for him, I guess I thought something of his expertise would rub off. 😏 Of course I have no reason (other than human nature) to think that.

    I am enjoying the challenge of Tracon!2012, but I have to admit, it beat me today.

    The hardest part of the approach for me are the events right at the end when a plane is turned in toward the ILS path. It just doesn't seem like there is enough time to give the commands. One missed word throws the whole thing off, and there's no time left to recover.

    I would appreciate any tips that people have to mitigate against that.

    Gil

  13. 12 hours ago, mechajames said:

    Just managed to fix it by snapping the ADRIS to the right hand side of the window and then selecting the strips as the second portion of that screen from the snap option. then just had to resize the window so that i could see what was on the strips.

    I'm sorry my methodology didn't help, but I'm glad you were able to find another solution.

    I've never had this problem with Tower3D Pro, but I have and the problem with other programs, and my methodology always worked for me. Tower3D Pro must create windows in a non-standard way when in full screen mode that render's the method I described ineffective.

    Gil

  14. 1 hour ago, LarryJ2112 said:

    I know in the end I need a new PC, but I am holding off for as long as I can. I am running Tower 3D pro and using voice.  I run dual monitors and like to put the ADIRS window to the second screen.  When I do that my frame rates drop dramatically.  I have turned all video settings down to the minimums and it doesn't help.  My video card is a NVIDIA GeForce GT 710.  PC has 12GB of ram. CPU is a an AMD A10-7800 Radon R7.  Any help would be great, thanks in advance.

    I have read where this might occur with hardware acceleration. It has been suggested that turning it off, if it is on, or turning it on, if it is off, might resolve the issue.

    Gil

  15. 5 hours ago, crbascott said:

    Firstly, that's one heck of a desktop background you have there.

    Isn't it? Reminds me of a Peacock. It's just one of many backgrounds I get from a Bing wallpaper app.

    5 hours ago, crbascott said:

    Secondly, I definitely see your issue now. Fortunately, I do not have nor have I ever experienced that problem. Unfortunately for you, it is probably something specific to your system. Considering the age of Tracon, maybe your system is too good. Who knows, but an obvious troubleshooting step would be to adjust graphics settings to see if that changes anything. 

    I finally found the right settings to make it work. I just hadn't gone back for enough in the compatibility modes. This setting did the trick.

    12.14.2019-05.40.51

     

    5 hours ago, crbascott said:

    Thirdly, I got nuthin'. Just wanted to say thirdly. 

    It's always good to have a third point. 😀

    Thanks for the feedback.

    • Upvote 1
  16. The "SHOW:TRUE" attribute causes objects to be show only if the "SHOW:TRUE" custom parameter is set for it. Otherwise objects will be show even if that custom parameter is set. Waypoints is what I want to see, only not as clutter.

    I can clear the clutter by minimizing and then restoring the Window as I demonstrated in the video, but that shouldn't be necessary.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.