Jump to content

virtuali

Commercial Member
  • Content Count

    2,476
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

4,446 Excellent

7 Followers

About virtuali

  • Rank
    Member - 2,000+

Profile Information

  • Gender
    Male
  • Location
    Switzerland:LSZA

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    IVAO
  • Virtual Airlines
    Yes

Recent Profile Visitors

14,821 profile views
  1. If the parking brakes works before a restart, it means it is configured correctly in the airplane profile. That is assuming you ARE using a custom airplane profile. Since none of the Prosim airplanes are internally supported by GSX, it means you must create an airplane profile, and the parking brakes test can be customized, in the case the airplane doesn't use a standard variable to test it. So, the first question would be: are you using an airplane profile (you should) and if yes, how the parking brake test is set to ?
  2. You click it on a Cargo door, to indicate the loader type. GSX Manual. Paragraph "Cargo Doors options" at Page 64.
  3. I said the airplane profile, that always takes precedence over the airport profile
  4. They are high enough for the FMC15 ULD loader, but of course, in order to see it, you must tell you want to use ULDs (AKH, the only kind allowed in an A320) in the airplane profile.
  5. you omitted the most inportant thing: the airplane used. If the airplane can’t use cargo loaders (for example because its cargo door is too low), GSX will use belt loaders, no matter what you set in the airport profile.
  6. And it had an "AI copilot" which was able to perform a complete flight, from take-off to land. In 1990. I'm obviously biased here, because I took some part in its development, not the original ATP, but its two follow up successors, Airline Simulator and Airline Simulator 2.
  7. I find bizarre you are saying I'm "missing" the important point those data can only be used by those with a subscription, and you just quoted me saying *exactly* that (the "those who pay for add-on sceneries)" part of my sentence you just quoted! Another point I made too in a previous post. When I said that, on Vatsim, where a human give instructions, there's no choice other than having the human using the latest charts (controllers can't be expected to give different instructions depending which scenery the user has installed), but an ATC software CAN choose to use different data, that's a key difference where the AI ATC here has a chance to be even better than Vatsim. This is your opinion, which I don't agree with. Of course, in an "ideal world", the scenery should match real life charts, and it always did, we won't having this discussion. Reality is they sometimes they don't and, given a choice, I'd rather be able to taxi as in real life, by looking at ground markings and vertical signs, instead of having to be forced to open a moving map (assuming my airplane has it and it *is* connected to Navigraph) and disregard the outside world, because I *fear* the scenery might be outdated. Your initial point about "real data can only be used by those with a Navigraph subscription" only makes my point: what about those users? If they don't even *have* real world charts, they'll just hear confusing ATC directions without even knowing why. Which makes even more useful to have the OPTION to just use Simconnect Navdata, which will ensure taxi instructions from the ATC will always match the scenery. Again: it's should be an OPTION between: - Real-world adherence, which comes with a chance of confusing instructions. - Internal coherence, which means always getting instructions matching the actual visible scenery, which might be less "realistic", but less confusing. With the added bonus it doesn't even need an extra subscription to that data.
  8. That's because, if you are looking at the TAXI_PATH definition, it doesn't really make much sense to have coordinates for a "path". A path is just a segment with a start and and end (the START and END parameters) which are just integer indexes to a list of TAXI_POINT elements (they are just before the path in the SDK docs). The TAXI_POINT have coordinates, which are expressed as offsets in *meters* (BIAS_X and BIAS_Z) from the Airport reference point, which is finally in Lat Lon. So, assuming you wanted to "draw" a map of taxiways, you need to: - First get the basic Airport record (from ICAO), which will tell you basic things, like Lat/Lon of its ref point, but also how many taxi points and paths there are, which you'll surely need https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/API_Reference/Facilities/SimConnect_AddToFacilityDefinition.htm#airport - Get all the TAXI_POINTs and store them away in some table. - Get all TAXI_PATHs and use the Start and End as Indexes into the table of TAXI_POINTs, so you can draw the individual segments. If you only work in Lat/Lon, since the taxi_point data is expressed as an offset in meters from the airport center (as many things in the Navdata API are), you'll need some formula to add a linear distance to Lat/Lon, like the popular GeographicLib (Open Source and available on many platforms and languages), to get the actual Lat/Lon coordinates of the various points. You can also get a list of TAXI_NAMES, which the TAXI_PATH references to, as indexes.
  9. You can say exactly the same in reverse: if you don't extract data from the sim, the instructions received won't match what users SEE in the *actual* scenery, if that scenery is not up to date to real world, which happens very often because, while it's reasonably easy to get updated Navdata from various providers (you either pay, or require your users to pay by having a separate subscription), updating sceneries is way more complex, and it's even more complex the more detailed they are. Default airports, with all their flaws, are *easier* to update (and we'll see it after World Hub comes out), because the "data" directly drives the visual generation, so you add/move a taxiway, and will be moved both in the navdata and visually (you'll only need to fix vertical signage), but fully customized 3rd party add-ons, which feature completely custom background photoreal images, with multiple layers of custom ground textures, ground markings and vertical signs (possibly fully customized), take much longer to update, so it's very common for the scenery not to be up to date to real world. In these situations, not taking data from the sim, will force users to taxi basically ignoring what they see outside, and stick on the map, assuming the airplane *has* a moving map feature which is connected to updated Navdata, like one with Navigraph integration. Taxiing this way, even if might be "realistic", is not very fun, and it's quite frustrating not being able to rely on the various ground markings or vertical signs, because you KNOW that, if the ATC gave you a taxi routing based on real world, you can't be 100% sure the scenery will match. What I can tell you for sure is: if you stick to the decision of using only real world data, lots of users (those who pay for add-on sceneries) will only be frustrated by having a bad experience on the scenery they bought, and saying "the ATC always says the truth", even if it's technically correct, it's not helping to improve the usability, and if you think all hundreds/thousands of add-on sceneries will be eventually updated, it's really a lost battle: scenery developers are usually busy with the next scenery rather than update the old ones, because it's the next scenery that brings money to stay alive, and in some cases, it might not even possible to update, because new aerial images might not be available yet, there are many reasons why sceneries are out of date but, regardless of the reasons, they usually ARE. That's why I suggested to offer the OPTION to use Navdata from Simconnect, at least on ground, where the relationship with Navdata with the actual visible scenery (and its eventual disagreement) is more distracting.
  10. I never made a judgement on the quality of the taxiway data in MSFS, we all know it's lacking. But, this is might be fixed with add-on airports, which are usually accurate to they day they came out, so the issue of those scenery being constantly updated might be relevant or not, depending on the airport: some airports haven't changed their taxiways in years, others change them very often so, whether the airport developer will keep up (assuming it's even needed) it's another matter but, it's clear that updating an airport is more complex than updating the Navdata. Fact users will see different data in the sim (because of different sceneries they have installed) compared to real world is not really a side issue. It's THE issue, the point I was trying to make was, do you rather have: - Accuracy to real world charts, but possibly confusing ATC directions because that taxiway is just not there in the scenery? - Internal coherence, so you'll get less realistic taxiway routings, but they will MATCH what you see in the sim, so you will get consistent (albeit not "real ) taxi routings ? My *personal* preference would be internal consistency, but that's just me, that's why it should be an option between Navdata API or external data.
  11. If they are not encrypted ( no Marketplace, then ). The Navdata API solves that.
  12. Yes but, as far as I know, LittleNavMap reads the airports .BGL files and then creates its own database, and that comes with both advantages and disadvantages: - Reading scenery files works offline, so there's no need to connect to the sim (required if you need to use the Simconnect Navdata API), which is an advantage for a flight planner, since you might not necessarily run it together with the sim. - On the other hand, not using the Navdata, means you are not compatible with Marketplace sceneries, which are encrypted, and the only way to obtain their data, is the Navdata API. We experienced both situations, because GSX *used* to read .BGL files before the Navdata API came out, so it didn't work on Marketplace airports *unless* the scenery developer provided you with an unencrypted version of the airport file, now it's no longer an issue, and we always get the data from the sim directly, no matter if it's encrypted or not.
  13. Listened to the video (the part about taxiways), and there are some information which are definitely inaccurate. Somebody on chat asked "how GSX follow me car can get taxiway data from the sim", and the reply was that yes, GSX get taxiway data from the sim, but it won't get the names, which is not a problem since it doesn't need to show the names, while an ATC cannot possibly work without knowing the taxiway names. This is factually incorrect, since GSX DOES get full information about taxiways, including their names, because it IS provided with Simconnect Navdata: https://docs.flightsimulator.com/html/Programming_Tools/SimConnect/API_Reference/Facilities/SimConnect_AddToFacilityDefinition.htm#taxi_path This can be seen at work in GSX, when you are doing a custom pushback route, and you press the "Label" button in the pushback slot: GSX will try to recognize if the pushback route ends on a Taxiway and, if it does, it will automatically create a label saying something like "Facing West, on Taxi N", so it clearly knows about taxiway names from the sim own Navdata. This opens up the old issue: it's best to get data from THE SIM or from an (usually better) EXTERNAL SOURCE ? While for normal navigation, it might work in either case (your FMC might contains data more updated than the actual scenery, but it will still fly the airplane), when Airports are involved, both default or 3rd party, if you use updated real world data, it might be "better" than the scenery you are using, and with taxiways it might be very confusing. A known problem for those flying online: the Vatsim controller has updated charts, and shows some taxiways, which might not exists or might have changed in the scenery you have installed. This because, updating a 3rd party scenery with probably fully custom ground textures is MUCH slower than "just" getting the latest AIRAC, so your 3rd party scenery will almost always be behind the real world, particularly in those nasty airports which are "forever" under construction. I think I know that very well, since all the work we had to do (and we STILL need to do) to keep our KORD scenery up to date, and right now it isn't, and some *taxiways* need to be updated. While it's difficult to suggest another approach when flying online, an AI ATC which is supposed to be an alternative to flying online, might have the chance to decide to be COHERENT with the scenery you are using, by just sticking to the Navdata from the sim, which I believe it's the more reliable approach, even if might not be the most realistic approach. I'm thinking about the upcoming World Hub: one of the main thing users are supposed to do with it (since it's not very powerful) is precisely to FIX taxiways and parking data on default airports, which is a workload that would just be impossible for Microsoft to do themselves (and keep it updated), hence the idea of the World Hub, which in a few years should allow MSFS to provide with better airport data. If I were the developer, I would consider giving users the OPTION to either use the Navdata API from the sim (so the ATC will just use and show what you are seeing in the sim) OR a better external data source, like Navigraph, so users might decide if they'd rather had coherency with a scenery they might *know* is not fully updated, but they would still prefer to use it.
  14. Maybe it might have been easier to understand if they just said "We use the standard Navdata API", that is extracting data directly from the simulator through Simconnect, whatever that data might be (which includes Navigraph if you installed it in the sim).
  15. With today's update, the Wingwing FCU is now compatible with DX12: I made a complete flight today with the Fenix, in DX12, zero issues.
×
×
  • Create New...