Jump to content

Tobias Dammers

Members
  • Content Count

    247
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by Tobias Dammers

  1. It works exactly the same. You fire up the simulator before connecting, then when the connection is established, it takes a few seconds to download the positions of the other aircraft and inject them into the simulation. What I do is check a vatsim map before connecting; if my current spot is occupied, I'll just move to a different one. It still happens occasionally that someone else spawns in the same location between me checking and connecting, but seriously, this isn't something I would ever make a scene about. An appropriate reaction would be more like "haha, look at that, we spawned i
  2. Indeed; for your typical IFR flight, it doesn't make much of a difference. Most of the time when I see this in the remarks, it's a VFR flight though, and for that it does matter a bit.
  3. That too. Though I believe that would ultimately be the responsibility of whoever runs the broadcasts.
  4. Of course there's also a bit of a chicken-and-egg situation there...
  5. If you're not comfortable flying in night conditions, I believe it's perfectly acceptable to set your simulator to daylight conditions and write "DAYLIGHT" in the remarks of your flight plan. I've seen this quite a bit, especially with GA flights in the European winter months.
  6. Internet radio is already a thing. What exactly would hosting it on Vatsim audio add? The protocol isn't even very suitable for it, it is heavily optimized for speech, and for simulating realistic audio quality deterioration like on real radio frequencies. Not only would this hog a network essentially running on donated servers and bandwidth for a purpose the donors didn't sign up for, it also wouldn't sound very good. If you want a VATSIM radio station, the best way IMO would be to host it independently, and just advertise it within the VATSIM community.
  7. I would suggest the following: 1. Keep an eye on a vatsim map for a while to see where and when it gets particularly busy. You probably want to pick your time and location such that it gets lively, but not too crowded - ideally, you want to be one of no more than maybe 3-4 pilots that one controller is managing at any time; this gives them enough time and headroom to be more patient with you and accommodate your rustiness. 2. Do your homework. Pick airports and routes that you are familiar with, make sure you have all the charts, know what to expect during your flight, be in a position to
  8. Yes. I do agree that option 2 is the best. It's still disruptive, but it seems the least unfair, and the most productive. It's a shame that X-Plane works the way it does, but I don't think it should be up to Vatsim to deal with it.
  9. Just to clarify one thing: This whole FPS thing is not about punishing those who can't afford top-notch hardware. It's about making sure that everyone's simulators produce realistic enough results. I don't care if you're looking at a slideshow on your computer; VATSIM position updates are way slower than visible frame rates anyway (I believe something like one position update every 5 seconds or so?). If your simulator says you're flying at a ground speed of 240 kts, and then one minute later, you have moved significantly less (or more) than 4 nautical miles, then your simulator is not
  10. Well, yes, they exist, that's why I said "more". If you look at https://www.vatsim.net/events right now, there is only one event there that is clearly not about flying IFR in an airliner - some events welcome VFR and GA flights, but they're all mainly focused on commercial jets, and realistically, 99% of those participating will be flying one of those.
  11. It's not just a wild guess; the blog post linked elsewhere explains quite a bit about how XPlane's timing works, and what the design considerations were. Anyone with a bit of experience in game dev or realtime simulation programming should be able to deduce from that more or less what I did. As far as willingness to re-engineer goes, the blog post is quite vocal about this, and basically says it's not going to happen. The path forward they state is to improve overall performance, so that FPS drops don't occur anymore, rather than changing the timing logic so that the FDM stays in sync rega
  12. You're not even going to qualify that [Mod - Happy Thoughts]ertion by adding something like "unless you have the hardware to maintain the minimum sim rate" ? Not really, no. You can get away with it, but the design is fundamentally flawed, and all it takes to derail the thing is a bit of unexpected background activity, or a more demanding aircraft model.
  13. Yes. Their blog pretty much says exactly what I described. They're not giving any convincing reasons though, other than "significant engineering effort", which, frankly, I'm not buying. Frame skipping isn't rocket science, and it doesn't require "independent" execution of rendering and logic, only changing the lock-step such that the "render" part may be skipped if the whole thing can't keep up. Sure, it would eat into rendering performance, yes, THAT IS THE POINT. You want to sacrifice rendering performance (which is at least 50% cosmetic) before correctness (which is 100% essential). The
  14. The commonly used VATSIM maps (map.vatsim.net and vau.aero/fsmap) don't update in realtime, they generally lag quite a bit behind, easily a full minute or so sometimes. The VAU one also doesn't show aircraft on the ground. So it's quite possible that you just looked in the wrong spot - when the pilot made the announcement, the map may still have shown them somewhere up the STAR, while you were expecting to see them on final approach.
  15. The odd thing about this is that other sims can do it just fine. FlightGear, for example, will always keep the FDM running at 120 FPS, even if rendering slow down to a completely unflyable slideshow. It doesn't alter the time slice, it just allocates more CPU to the FDM and less to the rendering in order to keep up. I haven't read any XPlane source code, but if I had to guess, I would wager that the logic goes something like this in FG: 1. Render a frame. 2. How much time has p[Mod - Happy Thoughts]ed since the last logic update? Multiply that number (in seconds) by 120, and perform t
  16. 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
  17. 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
  18. 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
  19. 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.
  20. 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.
  21. 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
  22. 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
  23. 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.
  24. 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
  25. 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.
×
×
  • Create New...