StefanA

Members
  • Content count

    5
  • Joined

  • Last visited

Community Reputation

0 Neutral

About StefanA

  • Rank
    Flight Student - Groundwork
  1. Hello together, each time when I'm cleared to ILS approach 07L (unfortunately all the last times I remember), I'm instructed to descent to 1800 feet (!), that's really not a very good idea for a B747-400, the GPWS wouldn't like that. Additional I've the impression, that the descent out of FL370 starts too late. I've the impression that I need a helicopter to land or to throw down the B747 like a stone. Reducing speed in a normal way of approach procedure isn't possible. It's standard FSX ATC and I never had it with EDDF V1. Last flight, even IFR was cancelled because of the stupid descent profile (I guess), didn't experience that in the past too. Same problems with Level-D B767-300 approaches. From "25" side I remember to be cleared to 4000 which is fine. Does anybody have similar problems? Route KBFI - EDDF: (initially planned for 25L because of forecast, but with 0 wind during approach ATC assigned 07L) YDC DCT 8N DCT YSF DCT YXN DCT YXP DCT METIL DCT OBA DCT TD DCT TOLSA DCT SPY DCT UNKAR UT149 OTSOP DCT LIPMI DCT ROLIS ROLI1B Perhaps there's another reason. Temporary used MCE and PF3, but not during these last flights (standard ATC). But why did it work really fine with EDDF V1 on the other hand?
  2. Hi again, did a lot of tests now and a lot of different approaches with PMDG B747-400 V2. With following settings it is close to VAS limits but it works! [Graphics] TEXTURE_MAX_LOAD=1024 [Scenery] IMAGE_COMPLEXITY=4 // Affecting VAS [Terrain] LOD_RADIUS=3.500000 // Affecting VAS MESH_COMPLEXITY=84 MESH_RESOLUTION=24 // Aerosoft recommendation, original 22 TEXTURE_RESOLUTION=27 // Aerosoft recommendation, original 25 AUTOGEN_DENSITY=3 // Aerosoft recommendation 4, original 5 // Affecting VAS WATER_EFFECTS=4 // Aerosoft recommendation 3 // Affecting VAS TERRAIN_MAX_AUTOGEN_TREES_PER_CELL=1500 // Affecting VAS TERRAIN_MAX_AUTOGEN_BUILDINGS_PER_CELL=500// Affecting VAS // Affecting VAS = means that there's a visible difference. Some higher settings of other parameters didn't affect the VAS during the tests at least. Regarding some other environments, the difference isn't such high, but: - KLAS and KMIA have a detailed environment and use 3,5 GB (KLAS) and 3,7 GB (KMIA) at all. - KLAX and TNCM have lower values because of the missing detailed city environments. ----> There may be some more optimizations, would be glad to check the above mentioned LOD settings. ----> Some more experiences by other users/developers to improve?
  3. Hi all together, after upgrading from EDDF V1 to V2.10 I experienced the OOM's with the new PMFG B747-400 and did a lot of investigations now. First to avoid any questions about my background, I'm IT engineer since 30 years and I'm familiar with OS systems as well as with programming C++ and assembler. So I know about the limitations of this awesome 32-Bit FSX and all depending advantages and disadvantages of a Windows 10 64-Bit environment. The FPS isn't any problem with my 6 core machine and GTX 780 TI, but the OOM is one since installation of this Version 2.10. I didn't have that before although I've some really detailed addon airports like KLAX, KLAS, KMIA, LEIB, LEPA, TNCM. Currently I created a standard test environment with the PMDG (IRS initialized, radar on, typical gate status of the cockpit) parking on gates at each of the above airports. I set an outside view with approximately 45 degrees and most possible distance to get a view over a big distance of the scene. This ensures that there aren't any effects during a flight on approach and allows to compare in an objective way. There aren't any (HD-)scenery addons except the listed airports. The weather is always clear and the time is set to daylight. Then I'm retrieving the VAS just after loading (ASN off, UT-Live off, standard traffic off) and as second measurement the VAS after a 360 turn with the joystick hat switch. Additional I found the Version V2.11 now and did some screenshots with V2.10 and V2.11. It seems that there's a little better VAS consumption but I'm not sure if the suggestion made by "thokle" has affected the new release. The area file is still a single file. From my knowledge, I agree that this may be a useful solution. Additional I'll try to disable the terrain for testing. Perhaps there may be the possibility to reduce the forest density. It looks really nice, but that can't be a reason to reduce the rest of the world into bad looking year 2000 environments. Especially regarding the fact, that I agree to all guys only having these problems in EDDF. And with EDDF V1 it worked really fine. Downgrading back to V1 would be a bad option, because of the manually changing the navigation data only for EDDF in that case. Not to forget that we paid for the new version. - EDIT: Readme.txt found (expected it in installation package, not in installation folder). Suggestion by "thokle" not included. That's what I hoped, because there isn't any improvement with VAS consumption in version V2.11. So we may still hope that this suggestion will help. - And yes I really appreciate that you forwarded this suggestion by "thokle" to the developers. But is there already any status or report? Now I continue with testing, the screenshots may be send to you when I finished it. OFF-TOPIC: I can't imagine that there isn't any successor being able to substitute this 32-Bit version, although everyone notifies that the community is waiting for it since 7 years now and the addon market is running very well. All attempts seem to be busted-flush. We don't need a game, we need a simulator: - 64 Bit - Current graphics engine (for example that one from GTA-V, A GAME!) - Improved ATC - Improved airport procedures - Improved weather engine - Same open architecture for that really great addon developers (Aerosoft as well!) OFF-TOPIC-END Please improve your handling with customer reports. Some posts aren't really nice and it's no doubt for every one knowing such complex and different settings, that you only can improve the software by these reports. That's not to blame you, that's only to help improving the product for everyone and experiencing a most realistic simulation. Attachements: *-01.png --> before 360 *-02.png --> after 360 Version is part of the file name. Other airports will be done now. But a first test confirmed the reports by other guys, that the consumption is much lower. Regards, Stefan
  4. Checked the AF2_EDDF_FSXC04.BGL with ADE and seems to be ok. I don't know, why there weren't the right parking codes shown in Traffic Explorer. Checking the UT2 database I found that there weren't assignments for B676-300-Winglet and B757-300-Winglet for Condor! But in the flight plan it seemed to be ok. Looks like it's necessary to completely check the UT2 database and correct a lot of stuff there. Additional I found that two Condor planes were positioned at dock 171 and 175, because there's a CFG entry. So if there's a lot of traffic for example with WOAI activated, the condor planes will be moved to these two positions in southern area, because only some B-gates have CFG entries too. Is it possible to give CFG a priority there, because the huge amount of LH planes has so much opportunities at other gates? It's little bad that the only two condor aren't at the right position in B area.
  5. Installed UT2 schedule 2013 and then new UT2 Schedule summer-fall 2016! In both cases I'm wondering why nearly all the Condor flights are missing at the gates, where they should be. Having a look at Traffic Explorer for the gate area B and C I found only for C2 the parking code for Condor. All others don't have any entry like CFG, CIB, CNR! Sometimes there's a Condor A320 at C2, that's all. The flight plans show, that there must be at least 2-4 B767-300 too. That's what I saw in real Frankfurt last summer and it's defined in UT2 flight plan. Without parking codes UT2 isn't able to set the traffic on it's planned positions. I fear, there are other codes missing too, because Frankfurt seems to be empty with maximum 150 aircraft, but the flight plan tells much more. It seems that's not the fault of UT2, the parking codes in UT2 are set, I've just checked it. Additional not depending on Condor, some V1xx positions have cryptic letters in the parking definitions. Please check the responsible AFCAD'S.