Posts by aroos

    With refinement, after sending George back to flight school - and a reduction in salary - George the co-pilot could demonstrate real-world procedures as skilfully & accurately as possible, at least in some scenarios but hopefully available at all times to demonstrate gold standard airmanship.

    That's a very interesting idea. However, given that no commercial aircraft manufacturer has managed that yet - if they had they would be offering single-pilot cockpits - it's perhaps more a subject for doctoral research than a realistic feature request for IPACS. FS2 would be an excellent platform to demonstrate such an AI copilot, in the same way that DARPA recently demonstrated a (fairly basic) AI fighter pilot.

    In mine, these are subsequent lessons so "completing" lesson 13 (Power for climb and descent) by editing the file then unlocks lesson 14 (Climb). Presumably completing this will then unlock 15 (Descent). I'm using the alpha version but I would expect the release version to behave similarly.

    I'm a beginner. Therefore, I want to be trained. I have successfully completed lessons one through twelfth. Lesson 13 - Controlling the engine when pitching and diving. After the coach gave the command "full throttle" and I executed it, nothing happens. I left the simulator for several hours. He rose to 15,000 feet and continued to fly across the continent.


    What needs to be done so that the coach would command "We are going down!" ?

    I tried this lesson and the aircraft only climbed a few hundred feet (to altitude 3470 ft) before the trainer says "I descend now" and instructs me to reduce throttle. The aircraft descends to 3200 ft and the lesson ends. I also tried with reduced throttle on the climb, thinking that perhaps your controller wasn't properly calibrated, but then she just moans at me about not using full throttle but still descends.


    I don't know why your system is behaving differently. However, if you want, you can save a backup copy of file mission_progress.tmp in the "Aerofly FS 2" directory under "My Documents". Once you have made a backup copy, you can edit the original (while FS2 is not running) using notepad and find the following lines:


    <[mission_info][climb_descent_power][12]

    <[float64][HiScore][0]>

    <[int32][Stars][0]>


    Then change the HiScore and Stars values for this lesson to 1 and 3, like this


    <[mission_info][climb_descent_power][12]

    <[float64][HiScore][1]>

    <[int32][Stars][3]>


    save the file and restart FS2. You have just given yourself 100% and 3 stars for the lesson, so it should allow you to continue!


    Good luck with your training,

    Andrew

    C90 GTx flew KEGE to KMRY fine, except that the AP flew a few degrees west of course from takeoff RWY 25 until the right turn at SXW. The pic shows the track compared to the visual course markers (she was dead on course when I engaged the AP). It's possible that she was flying 253 true instead of 253 magnetic (262 true). She got on course after the right turn and flew fine on AP until final approach when I took over.




    Struggling to control the new beauty using my ancient black widow joystick. It was set up fine for the R22 but does not work too well now with the EC 135. In particular the tail rotor control mapped to the rudder does not allow me to stop the machine spinning. Anyone got any tips on setting this up right? Many thanks. Paul

    I had the same problem and solved it by ensuring I get some forward speed before applying full collective/throttle to prevent the spin. I assumed the tail rotor does not have sufficient authority to prevent the helicopter spinning under the torque of full collective and throttle.

    @aroos: Good observation, thank you! We identified indeed a much higher temporary memory usage and this seems to strongly impact shared memory systems. We just uploaded a new version ( V2.05.00.08 ) to Steam please give this a try, GPU memory usage should be reduced and you might see a slight performance increase on your system. Systems with enough GPU memory are not affected by this update.

    Thank you for investigating my observation, and for the excellent progress that is being made with the alpha release in general. I do indeed see that on build 2.05.00.08 the amount of shared memory used has returned to the same as it was on the release build, or perhaps a bit lower. Unfortunately this has not made any significant difference to performance with HQ AA.


    After some experimentation with graphics settings, I think what is happening here is that a fairly small increase in graphics memory requirement by the alpha - perhaps around 10% - is causing a dramatic (67%) reduction in performance as my graphics card runs out of dedicated RAM and starts using shared system RAM. This is because I notice that changing either texture quality, or terrain image quality, or building density from HIGH to MEDIUM immediately pushes the frame from 16 fps rate back up to about 48 fps with HQ AA still ON. (Setting terrain mesh quality to MEDIUM does not have a significant effect; and shadow quality and building density are already MEDIUM but setting them to LOW also doe not have much effect). So it's a classic "falling off a cliff" situation, where a small change to the independent variable causes a sudden, dramatic change to the dependent variable :)

    @aroos: Thank you for the tm.log file. At least no relevant issues are found. Your GPU seems to offer only 2 GB of memory. The huge drop you see between the different AA settings is probably related to a GPU memory issue, e.g. Aerofly FS probably needs more than 2GB and if we need to access memory not on the GPU things slow down considerably. We haven't optimized Aerofly FS for those scenarios. High quality shadows for example might already consume almost 512 MB a quarter of your available GPU memory. And also keep in mind ORBX KPSP and LOWI by itself are very detailed and will consume over 2.5GB with Medium quality.

    As a test, can you fly over a region with low buildings and 3D objects. Do you see the huge difference there as well?

    Thank you for looking at the log files for me.


    In monument valley I see less difference - 53 fps with HQ AA OFF and 85 fps with HQ AA ON, so about 60% improvement turning HQ AA OFF, which is much less than in areas with high res scenery.


    While I understand what you are saying about the speed penalty of using shared (non-GPU) memory, this does not by itself explain the consistent speed difference between the alpha and the release version. I do see, however, that the alpha release is using about 50% more shared memory than the release version (see below, identical scenarios, first is alpha and second is release). Perhaps it is this additional memory requirement that causes the lower frame rate.


    Just a thought, I don't suppose the alpha builds are development as opposed to optimized release builds? If so, that could explain it :). Anyway, not to worry, there are more important issues for the development team to focus on at the moment!



    I flew the King Air from KMRY to KPSP following the same route as #168. Again it followed the route until the base turn, then turned the wrong direction. Here are a couple of pics at the point where it should be turning right onto the base leg, in case they are helpful in diagnosing the fault.



    @aroos: No changes to the AA setting have been made in the Alpha. Could you please provide a tm.log so we can check if everything is alright and no errors show up.

    Same but with HQ AA disabled, 61 fps. Note that the alpha version incremented between previous post and this one!

    Files

    • tm.log

      (22.87 kB, downloaded 24 times, last: )

    I'm seeing a substantial performance loss in the alpha compared to the release version when Vulkan High Quality AA is enabled.


    With the aircraft at the standard takeoff location for 31L at Orbx Palm Springs (KPSP), I am getting only 16 fps with the alpha, compared to 46 fps for the release version (i.e. with alpha channel disabled in Steam). See attached images, alpha first, frame counter lower left. In both cases I rebooted the PC immediately before doing the measurement to ensure a consistent environment. Graphics settings: 1920x1280, Vulkan, High quality AA ON, graphics quality HIGH except shadows and trees MEDIUM. Graphics card NVIDIA MX150 with 2GB graphics RAM.


    Turning high quality AA OFF increased the frame rate in the alpha to 60 fps, which is a much greater increase than normal. An increase from 46 to 60 would be about right, not an increase from 16 to 60. So I suspect there is some performance issue with the Vulkan high-quality AA in the alpha, especially in high resolution scenery. I also tested on RWY 10R at Orbx Monterey, and saw a similar result (20 fps with HQ AA ON, 57 fps, with HQ AA OFF) as did Orbx LOWI (night) which gave 15 fps and 54 fps. However RWY 07L at LAX (default scenery) gave a much smaller difference: 22 fps (HQ AA OFF) and 31 fps (HQ AA ON).




    Damn! The Turbo Arrow flew this route perfectly from KMRY for over 3 hours all the way to the right base turn for KPSP (next waypoint after PSP), and then turned the wrong way! It did a small "S" turn- turning left and then right onto the heading shown in the screenshot below. I continued on AP for a few more minutes, but she just kept going in a straight line.



    Here is the cockpit view with the a/c in the location shown on the Nav screen above. AP is on, and coupled to the GNS 530. GPS DTK is 078, TRK is 123 - both are incorrect!


    • Fixed C90GTx airspeed indicator now receives data again

    The advanced autopilot (A320, B777, LJ45, etc. - not the C172, B58 autopilot) should now be able to fly the entire route laterally without any issues.

    Please test this as well with longer routes as we can't test every possible combination.

    C90GTx ASI working - thanks!


    The JF Turbo Arrow GNS 530 seems to follow the Nav course fine (KMRY->KPSP via several waypoints), except it still won't fly the SID, so I didn't try the arrival either.


    However, I note that the GPS displays "28L", which was the takeoff runway, where the next waypoint should be.



    It also appears that the ETE field is now indicating the time to the final destination, not the time to the next waypoint, as it did before. After checking the Garmin manual, I believe it should be time to the next waypoint. The manual defines ETE as the estimated time to the "destination waypoint", but it consistently uses "destination waypoint" to mean the next waypoint in the flight plan, rather than the final destination.


    And while I'm being ridiculously picky, the arrow between MQO and the next waypoint should not have a "D" in it, as the next waypoint is a standard waypoint, not a direct-to destination :)


    But other than that, it's an almost perfect facsimile!