Jump to content

Tobias Dammers

Members
  • Content Count

    230
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Tobias Dammers

  1. When an airport is staffed (either directly via the TWR, GND or DEL positions, or via top-down control from an APP or CTR position), the controller responsible for it will usually run an ATIS channel on a separate frequency (e.g., right now the controller staffing EDDF_TWR on 119.90 also runs EDDF_ATIS on 118.02). So if that is available, tune in to the frequency just like you normally would, and you should hear actual voice ATIS. When you're not in controlled airspace, there usually isn't any ATIS service either, so you will be on your own. You can, however, get real-world ATIS from many
  2. I think the problem isn't the client (which receives and displays the text just fine), but the fact that you're not actually looking at the client UI, because you're behind those VR goggles, and the existing VR setups apparently don't relay text messages from the client. I think a neat solution would be to somehow add a virtual "pager" device to the virtual cockpit, and show the messages there. Ideally with a notification sound. You may not be able to type an answer, but at least you receive the messages, and you can still answer with voice (because AFAIK the vast majority of pilots, and v
  3. I'm pretty happy with the way things are in general, but I can think of a few things: 1. More VFR/GA events, possibly in an interesting / challenging environment. Island hopping, mountain flying, STOL ops, that kind of thing. 2. Events with "debriefings", or some kind of "lounge" for an informal chat after your flight. Could be a proper feedback session on your flying and communication (and controlling...), or just socializing. Other than that, my own selfish concerns are: - Good freely accessible charts available - Suitable for my favorite aircraft types (DHC6, CRJ900) - Possib
  4. I think you misunderstood. I'm not saying time dilation should be allowed on the network. Not at all. If a client turns out to dilate time, then disconnecting them is the right thing to do. A client that does this is broken, and it is the user's responsibility to fix it. All I'm saying is that "FPS" is a bad metric for this, and we should be measuring actual time dilation instead.
  5. Dutchvacc post this information on their own website, too: https://www.dutchvacc.nl/active-runways/ I'm surprised that this isn't common knowledge among those who fly into or out of EHAM.
  6. As an experienced programmer (30+ years), my gut feeling is that sampling the frame rate is the wrong way to go about this. We don't actually care all that much about the client's frame rate - I can fly at 8 fps with flightgear, and the ATCO won't even notice a difference, it just makes the aircraft more difficult to handle for me as a pilot. That's because flightgear took a different approach to dealing with insufficient system resources: instead of slowing everything down, it keeps the FDM running at full speed and only slows down rendering. So when I'm running at 8 fps, the FDM still ge
  7. re 1.: My understanding is that you *never* file SVFR anywhere. You file VFR, and then you request SVFR from ATC at some point during your flight (most likely clearance delivery). re 2.: Technically, you are right. If we want realistic flight planning, then we should follow ICAO rules, and just file VFR. But in practice, some aspects of virtual aviation can never match reality, and I think it's OK to deviate from real-world procedures in some cases. And this may be one of those, because ATCO workload is a bit different from IRL (one controller manning several positions top-down, and not ne
  8. Easy there. All I meant to say was "someone has already done it, it works, it's open source, so why don't you look there before deciding to do all the work yourself?" There may be valid reasons for making your own from-scratch implementation, but you haven't stated any, and when talk about "reimplementing the wheel", I really mean that it's a good idea to either use what's already there, or be confident about your reasons not to.
  9. This might clear things up: https://en.wikipedia.org/wiki/Special_visual_flight_rules SVFR is just VFR as far as flight plans and airspace cl[Mod - Happy Thoughts]es are concerned, and you file it as such. SVFR simply means that you get to fly VFR in IMC. You don't file a flight as SVFR, because you don't know what exactly the meterological conditions will be; instead, you just file VFR, and if the weather is such that you can't fly VFR, but you still meet the requirements for SVFR, you can request SVFR from ATC. The exact requirements vary per country, but you generally need to still be a
  10. Ah, right, yes. Might still be worth it to get in touch with the Swift team - much of their work is open source, so it might be possible to just extract the AFV parts and reuse those. Maybe even turn them into a library. I have no idea what the source code looks like though, so it may or may not be worth it.
  11. There is working AFV support in Swift, which also works on Linux. Maybe look into that rather than reinventing the wheel?
  12. You'd be surprised what people are willing to do for meaningless virtual points.
  13. It's all about the workload. There are a couple of things you can do, and not all of them are obvious. It starts with preparation. Don't blindly trust the FMS data; get the VATSIM pilot briefing and charts (if available - most local organizations will publish at least some information about what you can expect) and study them. Compare your FMS data against those charts, and if things don't match up, figure out how you can fly the advertised procedures. If you're unsure, or not comfortable flying any of those procedures, consider saying something like "NO STAR" or "APPR VECTORS" in
  14. Adding to all this: even as a pilot flying in uncontrolled airspace, I appreciate people filing their flight plans, because I routinely check activity in the area using external VATSIM maps, and knowing the destinations of aircraft in the wider area gives me a better idea of the traffic I can expect enroute. I'll still monitor UNICOM and announce my intentions, but it's nice to know that the aircraft currently on course to cross my route isn't going to descend below their current flight level, because they're still 1000 nm from their destination, or that they're going to turn from their curren
  15. My strategy: 1. Look for events. Event organizers usually do a very good job at keeping the promised ATC stations manned, so if you want to do a flight with full ATC coverage, this is your best bet. 2. West and Central Europe, especially the UK, Benelux, France and Germany, tend to have good coverage during the local evenings (typically between 1800-2200 UTC or so). UK is probably the busiest region on VATSIM, and you'll often see a handful of airports staffed throughout the day. 3. Check out vatsim maps, like https://vau.aero/fsmap/, see where controllers are currently online, how long
  16. Heads up; skyvector can also export flight plans in a variety of formats. They are aimed at RL FMS systems and the like, but they will also work with many flightsims.
  17. Real metal or virtual, I believe confirming the altitude *clearance* is more important than confirming the *current* altitude. The ATCO already gets your altitude from your transponder signal; if your reading is wrong, then so is theirs, and if there is a discrepancy between the two, it's still not obvious what exactly went wrong, or how to fix it - all you know at this point is that at least one of those readings is incorrect, which means you have lost situational awareness, which means you are now in an emergency situation. But this isn't a problem specific to handovers; altimeter failur
  18. IME a highly automated airliner like the 737 makes things easier on a lot of fronts. In, say, a Cessna 172 with steam gauges, a lot of workload goes towards flying the aircraft and executing procedures based on VOR/NDB; in the 737, you program the route into the FMS while on the ground, and once airborne, you can mostly leave flying the aircraft to the autopilot, and focus on radio communication, navigation, and managing your route. The only advantage I can think of in a small GA aircraft would be that it's much slower, so you have more time to do stuff.
  19. On the subject of #1: While I agree with the general notion that pilots should actively seek to contact ATC when entering controlled airspace, because that is how it works IRL too, there is always the problem of controllers coming online while you're flying. IRL, you would plan to make contact on a particular frequency as you enter some airspace, and you could rely on the station being manned, but on VATSIM, it is perfectly possible that the station is unmanned when you take off, but while you're approaching the sector, a controller logs on, and with the pilot setups I am aware of, there w
  20. I doubt your radio transmissions were the cause of the confusion. Upon initial contact, the departure controller already knows you're coming, they have your flight plan and clearance, and they've probably already spotted you on the scope. Whether you say "climbing" or "climbing on the SID" doesn't really matter an awful lot; the only reason you mention your altitude clearance at all is to make sure you and the controller are on the same page (i.e., you have the clearance that the controller expects you to). My guess would be that you filed a flight plan with an equipment code that indicate
  21. I think one particular issue with voice UNICOM on VATSIM is that unlike the real world, we use UNICOM a lot in airspaces that are always controlled IRL, and those include pretty much all airspaces where you can fly faster than 250 KIAS. Meaning that UNICOM on VATSIM is somewhat uncharted terrain in some situations.
  22. The procedure I use, pretty much on any aircraft type: 1. You're zooming down the STAR / Transition on LNAV (and possibly VNAV, but usually ATC will be giving you explicit altitudes rather than clearing you for the profile). 2. As soon as you know which runway to expect, put the ILS frequency into NAV1. 3. Once ATC starts vectoring you, switch A/P to HDG mode, and, if necessary, set nav source to NAV1. Verify the ILS frequency and identifier. 4. Radar vectors (or, in rare cases, the full approach procedure or transition) will get you onto an intercept course and altitude. As soon as ATC
×
×
  • Create New...