Jump to content

crisk73

Members
  • Posts

    202
  • Joined

  • Last visited

  • Days Won

    1

crisk73 last won the day on February 25 2017

crisk73 had the most liked content!

About crisk73

  • Birthday 04/28/1973

Profile Information

  • Gender
    Male
  • Location
    Most Serene Republic of Venice

Recent Profile Visitors

4,783 profile views

crisk73's Achievements

Newbie

Newbie (1/14)

  • Week One Done
  • One Month Later
  • One Year In

Recent Badges

82

Reputation

  1. Hi excellent news, as a v4 owner I'll get this for sure. Currently using default though because of better fps in VR. V5 hopefully will take the lead. One question, what about weather transitions between metars? Will it be smooth? What I hate about default xp clouds is the complete sky redraw. Tx.
  2. Hi, first I have to say that this is an issue common to all planes using navdata in the X-Plane native format, so I've posted the same at the .Org forums. The IXEG 733 has its own format but it is affected as well (maybe because it gets frequencies from XP data?). Basically, when you select the ILS Z 07L (IFNE) approach at Frankfurt the plane takes the ILS frequency from the ILS Y 07L (IFEL) approach that is 110.30. The correct frequency should be 111.75. Here the relevant lines in the navdata text files (using Navigraph current 2007 AIRAC cycle). From wpnavaid.txt file in NavData folder: From X-Plane the earth_nav.dat file: For sure @Litjan can help cause he plays home here Thanks. Cris
  3. Hi@sundog clouds appearance and performance are very good on last v4.7, thanks for the efforts to continuously improving the product. One thing I noticed is that in TS conditions the sky is way too bright imho. Are you planning to darken clouds or sky colors whenever those conditions are set in future updates? Tx.
  4. Hi, I've found that the vortex option is responsible for the same bug with 11.30b. It's fine once it's switched off.
  5. Many other threads already have the answer to those questions, please read them. Ixeg is not dead, devs will get back to work on the plane when they will have time, they've already acknowledged there's a lot of stuff to take care of, prioritizing the FMC of course.
  6. Is it possible to kwow which one of the routing codes between Aerosoft and Navigraph is currently used? I'm asking this because recently I have had some problems with Aerosoft data completely omitting some route waypoints, particularly in the continuous descent procedures newly implemented in the US. Thanks.
  7. Marked as solved, but my question is: what's the problem, ixeg interpreting Aerosoft data or Aerosoft data themselves? Tx.
  8. Ok, thanks Claude for checking. Seems that Navigraph is getting it right (or that IXEG is reading Navigraph data correctly).
  9. Thanks @daemotron for your help. NavdataPro is structured differently, Runway Transition is set apart from the main STAR, but I don't see particular issues here: <Star Name="HYPER7" Runways="01C,01L,01R,19C,19L,19R"> <Star_Waypoint ID="0"> <Name>DELRO</Name> <Type>Normal</Type> <Latitude>39.965475</Latitude> <Longitude>-76.625344</Longitude> <Speed>0</Speed> <Altitude>0</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </Star_Waypoint> <Star_Waypoint ID="1"> <Name>LIRCH</Name> <Type>Normal</Type> <Latitude>39.826767</Latitude> <Longitude>-76.922231</Longitude> <Speed>0</Speed> <Altitude>14000</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </Star_Waypoint> <Star_Waypoint ID="2"> <Name>BINNS</Name> <Type>Normal</Type> <Latitude>39.785061</Latitude> <Longitude>-77.010994</Longitude> <Speed>0</Speed> <Altitude>0</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </Star_Waypoint> <Star_Waypoint ID="3"> <Name>HYPER</Name> <Type>Normal</Type> <Latitude>39.683933</Latitude> <Longitude>-77.225094</Longitude> <Speed>250</Speed> <Altitude>10000</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </Star_Waypoint> <RunwayTransition Runway="19C"> <RwyTr_Waypoint ID="0"> <Name>COVUR</Name> <Type>Normal</Type> <Latitude>39.359072</Latitude> <Longitude>-77.453469</Longitude> <Speed>0</Speed> <Altitude>7000</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </RwyTr_Waypoint> <RwyTr_Waypoint ID="1"> <Name>DIMKE</Name> <Type>Normal</Type> <Latitude>39.309106</Latitude> <Longitude>-77.454383</Longitude> <Speed>0</Speed> <Altitude>0</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </RwyTr_Waypoint> <RwyTr_Waypoint ID="2"> <Name>HOOSR</Name> <Type>Normal</Type> <Latitude>39.226192</Latitude> <Longitude>-77.455597</Longitude> <Speed>0</Speed> <Altitude>0</Altitude> <AltitudeCons>0</AltitudeCons> <AltitudeRestriction>at</AltitudeRestriction> <Flytype>Fly-by</Flytype> <BankLimit>25</BankLimit> <Sp_Turn>Auto</Sp_Turn> </RwyTr_Waypoint> </RunwayTransition> The fact is that those waypoints (LIRCH, BINNS, HYPER) are never used (or they get overwritten by other transitions) in the approach sequence. Only devs know how the Approach code is interpreted by the FMC and if any issues exist either on IXEG or Aerosoft side. Cris
  10. Mmm.. Claude, good catch thanks! And I thought that Aerosoft worked better with the IXEG than Navigraph... I had previously flown the same leg with other aircraft (same navdata) and it worked fine. I'll check in the IXEG format if something is broken. Another reason to switch to Navigraph when my yearly Aerosoft subscription expires. Edit: wait... Claude. You selected the DELRO4 arrival. Would you please try with the HYPER7?
  11. Hi, herewith to report an issue I've run into while flying my KJFK-KIAD leg on VATSIM. The controller gave me a constraint over a waypoint I wasn't able to find in the flightplan, with the Arrival-Transition-Approach already selected in the FMC. After I've found that the HYPER SEVEN arrival at KIAD is not correctly read by the FMC as some published waypoints (which were relevant to the above ATC instructions) are actually missing. From point DELRO a straight line to COVUR is drawn for the ILS Rwy19C approach, while the fixes LIRCH, BINNS and HYPER are left out from the star depiction. My flightplan: KJFK KENNEDY FOUR RBV.HYPER SEVEN ILS RWY19C KIAD - FL240 Using Aerosoft NavDataPro cycle 1802. IXEG_FMS_debug.txt Thanks for your attention. Cris
  12. Hi, that's a known issue since the very first release. See a dedicated thread in the FAQ section. It seems like it depends on the way Gizmo manages the Lua garbage collector. More or less noticeable depending on specific rig configurations. The developers are aware of it and said that there is room for improvement over the next releases. FYI - take it as a workaround - using v-sync adaptive mode half refresh rate seems to mitigate or even eliminate the effect.
  13. Yeah.. and when the ATC starts telling to descend to XXX METERS QFE YYYY?.. Not only STARS are a mess but you also have to mess up with conversions... (I love flying to Russia by the way).
  14. In addition to what Jan said, I'd suggest with the current version to always follow this sequence on selecting Arrivals: STAR - TRANSITION (left side) - APP - TRANSITION (right side) this should work fine, and that is in fact the "classic" way (US) to fill arrival procedures. Now I recall it's been said (Jan please correct me if I'm wrong) that the next release of the FMC will allow for more flexible SID/STAR selection and to get a number of acknowledged bugs fixed.
×
×
  • Create New...