Jump to content

KiloJuliett

Members
  • Posts

    475
  • Joined

  • Last visited

1 Follower

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

KiloJuliett's Achievements

  1. I'm assuming you are not using the EFB file format for MSFS. Just because the MSFS export works doesn't mean it's an EFB issue. I've tried already to point out the missing waypoint in the routing string of the EFB file. The situation for your latest flight plan is exactly the same. I'm afraid but there seems to be an issue with SimBrief creating incorrect formated EFB files. If you change the marked part to Routing=ASMUS ROSRA LAVBA everything is fine. So I would encourage you to bring this issue to Dereks (the developer of SimBrief) attention, preferably via the SimBrief forum. This function I already mentioned is using a different export from SimBrief, so this might work even if the EFB file is formatted incorrectly. Give it a try.
  2. Thanks for the example, Bob. Comparing the flight plan exported from SimBrief and one created by EFB itself, I can see that the route string is different, and explicitly lacking the waypoint LAVBA in the version from SimBrief. So my best guess currently is that the route string and wpt list is compared by EFB and only waypoints are considered that are included in both places. If this is the case, something is not right with the export by SimBrief and it might be necessary to advise Derek. Did you try to use the option to directly download your latest flight plan from SimBrief yet (Tab "Internet" in the "Create flight plan" window)? Maybe this works better.
  3. Strange story. Can you reproduce the behaviour for specific flight plans? Or will the same flight plan work correctly once and then not again another time? Also, if you have specific examples of flight plans where you observed the issue, may you provide the details, so I can test it on my system? Do you use the integrated SimBrief connection from EFB to load the flight plan. Or do you export the file from the SimBrief Downloader and then select this plan in EFB?
  4. Exactly the issue I tried to explain. While center is actually using the correct/raw frequency, vPilot puts a 5 there when the 25 kHz channel spacing requires it. But this is just a vPilot thing. And it seems vPilot also requires you to use the adapted frequency to connect it back to the original channel, which is technically without the 5. I thought vPilot would also accept the actual/correct frequency (ending with the 0), but maybe this is not the case for the MFS client. I'll check with my setup for P3D and let you know.
  5. What simulator do you use? I seems then you are able to fool the VATSIM pilot client and bypass the correction logic. Technically seen, there are no actual .xx5 frequencies on VATSIM. It's all just made to look alike. See here the extracts from the AFV configuration. This is what the controllers use when connecting on these positions.
  6. It's basically VATSIM still living in the 25 kHz times. Back then, there was no need for 3 decimals and you were fine with 2. Old simulators also still have this kind of display. So it would show 129.42 or 119.72. You could only tune that and a RL equipment would know that 129.425 is the frequency to be tuned. So the precision basically doesn't need a 3rd decimal. And this is exactly what VATSIM askes it's facility engineers to consider and enter data only up to a precision of 2 decimals, which basically means that the 3rd decimal always is a 0. Not all facility engineers though work according the requirements, which might result in EFB eventually showing also a 5 at the 3rd decimal. VATSIM software generally does all the cosmetics by itself. So it will complete the 3rd decimal according the actual 25 kHz scheme and display it that way. This kind of "auto-completion" is also done by many addon developers. VATSIM servers will then ensure that people tuned on 129.420 and 129.425 will hear each other, even if that wouldn't be the case nowadays in RL (because there is already 8.33kHz spacing). Simulators not yet ready for 8.33 kHz will automatically add a 5 for the 3rd decimal according the 25 kHz channels, and so will the VATSIM clients. For simulators supporting 8.33 kHz, you can tune both. However VATSIM servers will reroute these to the same "channel", disregarding the precision of 8.33 kHz channel spacing.
  7. A revision of the same data cycle is usually only issued if there was an issue with the package in question. This seems not to be the case for the EFB 2.0 one, so everything is fine. E.g. for my FSLabs Airbus, also no second revision of the cycle 2102 has been issued.
  8. Looks like a priority issue of the different EFB windows. Did you hover over the EFB symbol in the task list and then select every of the EFB windows after each other to check whether this brings the ATC Ribbon on top of the main window?
  9. The Update of the EFB DB needs to be done via the DbBuilder. Refer to Manual 4 Database, ยง2.4.
  10. This is the location where you will see the call sign if a SimBrief ICAO flight plan has been correctly imported.
  11. Virtual Airlines usually are a hobby as well, so this is not contradicting. I'm not aware of any other discounts nor of the conditions, under which Virtual Airlines share such a discount code.
  12. I've created a pull request to change the VATspy file accordingly. Once it has been approved, APP should show up correctly for RKSI.
  13. Is your scenery also using the same frequency? The problem usually not the navdata, but the scenery that still uses old data. And if they don't match, you get the "outdated" message.
×
×
  • Create New...