Jump to content

Tobias Dammers

  • Content Count

  • Joined

  • Last visited

  • Days Won


Posts posted by Tobias Dammers

  1. I don't know how it works with flight gear, but keep in mind that at least with vpilot, it can take several seconds for another aircraft to appear in your sim. So if you connect and then see another aircraft appear in the same location as you after a few second delay, it is highly likely that they were there first.


    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 in the same location, I'll just grab the next stand if that's alright with you".

  2. I don't even know that it's necessary to specify that you're simulating daytime in your remarks. I simulate daylight for pretty much every flight I do. Since I work a regular day job, the only time I'm available to fly is when it's nighttime locally for me. However, I don't want every single one of my simulator flights to be at night. Flying with different weather than the rest of the crowd has an effect on your plane, but, daylight is just light -- it doesn't affect your movement. Therefore, a controller doesn't really need to know what your simulated day conditions are.


    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. 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.

  4. 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 anticipate. Don't file procedures you're not comfortable flying - it's better to write "NO STAR/SID" in your flight plan remarks, or request vectors for the approach well ahead of time, than to attempt a procedure that puts more workload on you than you can manage. Worst case, you'll be asked to hold or divert, but IME this is rare (especially when it's not too busy where you're flying - see suggestion 1).

    3. Make a suitable remark in your flightplan ("Returning pilot, please be patient" or something to that extent). Not all controllers read it, but most will.

    4. Fly an aircraft that you know by heart. Most of the traffic you'll see on vatsim is airliners, but you can pick a slower GA aircraft instead, which gives you more time for almost everything you need to do. If you are going to do that, it helps to fly into an airport that uses a dedicated runway for GA (e.g., EHAM uses runway 04/22 for GA, at EDDF you might get 07R/25L, etc.), this greatly reduces the stress factor of being sequenced in between faster traffic.

    5. Before getting your clearance, just sit there and listen in to the radio communications on the delivery, ground and tower frequencies to get a feel for the communication, and to know what to expect. If 5 people before you get the same departure instructions, odds are you'll get the same ones.

  5. 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 producing correct results, and this can affect everyone's experience.


    And between the simulators flown on vatsim, I believe X-Plane is the only one that solves the "hardware can't keep up" problem by adjusting simulation rate; the more common solution is to apply the traditional method of "frame skipping", where you increase the number of logic updates per rendered frame to keep them in sync.


    Anyway, given that X-Plane exists and is popular on VATSIM, and that the X-Plane developers do not acknowledge this behavior as problematic, there is no way to win here:


    - Banning X-Plane entirely is too harsh, because if your computer is up to it, you can, in practice, fly just fine without disturbing anyone

    - Disconnecting users whose simulation rate drops significantly is disruptive for both those users and for the people around them

    - Doing nothing is also disruptive, because now those whose simulation rate is below 100% will show incorrect behavior


    One way or another, someone loses.

  6. I am a bit surprised by these comments. In Australia on Vatpac we do these things at least three times per week all starting at 9.00am Z. All these flights are VFR/GA. Wednesday is World Discovery and can be anywhere globally except Australia and Friday and Sunday are in Australia and pacific regions near Australia. Recent events on Wednesday have included flights in Papua New Guinea and if you want difficult landing strips you can look no further. On Wednesday flights we also do "themed" flights like in Russia when we flew to all the soccer venues. Being "downunder" I understand that it is nigh on impossible for global support of these events but I am sure that they must be occurring elsewhere. I know that there are clubs in the UK that do similar so as well as commenting about what you would like to do, I suggest that you all give more support to your local flying groups and less time posting about what you want to see because what you want to see is probably already out there.


    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.

  7. I'm merely reacting to Tobias' [Mod - Happy Thoughts]ertion that X-Plane is not suitable for online flying. An [Mod - Happy Thoughts]ertion that he made on the basis of how he believes X-Plane works internally and his [Mod - Happy Thoughts]umption about Laminar's willingness to re-engineer the sim. It's a blanket statement that ignores all the people that fly X-Plane on VATSIM without causing issues, such as yourself.


    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 regardless of rendering frame rate. It's not an [Mod - Happy Thoughts]umption, I'm just paraphrasing Laminar's own statement.


    When I said that X-Plane is unsuitable for online flying, I mainly meant that the timing model is fundamentally unsuitable.


    The problem is that any frame beyond 50ms will cause the simulation to lag, and that lag is never caught up on, it just keeps accomeulating. So even a fairly undisruptive performance problem, like a background process stalling the machine for 100 ms every 2.5 seconds or so, will accomeulate to several minutes of drift after a few hours of flying (more than one minute per hour of flying). And the simulator makes absolutely no attempt to compensate. The time you lost on those frames is lost forever. Now imagine a 7-hour flight where, by the time you contact approach, your clock is out of sync by 8 full minutes. You're arriving 8 minutes later than scheduled, and any Zulu times you receive or report will be off by 8 minutes. Fortunately, things like ETAs and such are usually communicated in a relative fashion, and ATC normally doesn't care much about the arrival time scheduled by your flight plan, but it's still plain out wrong.


    You can try to not have any of those stutters ever, but I don't know of a truly reliable method - other than using a simulator that makes an attempt to stay synched with the wall clock time (i.e., an actual realtime simulation).

  8. My personal [Mod - Happy Thoughts]essment would be that this means that XPlane is simply not suitable for use on an online multiplayer platform like VATSIM.


    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.

  9. Read the blog post I linked as to why they do it that way. They actually explain it in great detail. Besides, it's their choice to make, not ours nor anyone at VATSIM's. And it's not going to change anytime soon no matter how much we kvetch about it, so we just have to come up with coping strategies.


    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 XPlane devs don't seem to agree with this though, and they don't seem to understand why it is what many users want.


    My personal [Mod - Happy Thoughts]essment would be that this means that XPlane is simply not suitable for use on an online multiplayer platform like VATSIM.

  10. Thanks a lot to both of you!!

    Regarding LFMN 4R, I had two different VATSIM online maps open, there was really no plane in this area.. But it doesn't I just wanted to be sure that I do not miss something important here...


    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.

  11. 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 this many FDM updates, each with a time delta of 1/120 s.

    3. Repeat.


    Whereas XPlane seems to be doing this:


    1. Render a frame.

    2. How much time has p[Mod - Happy Thoughts]ed since the last logic update? If that number is larger than 1/20 s, perform one FDM update with a time delta of 1/20 s, otherwise, perform one FDM update with a time delta equal to that number.

    3. Repeat


    While this suggests that XPlane's FDM uses a variable delta, that doesn't mean fixing it would require a complete rewrite of the FDM. You can still cap it at 1/20 s, you just have to run it multiple times if a frame took longer than 1/20 s to render. Just keep doing updates at 1/20 s until the remainder is less than 1/20 s, then one more update to get it to 0. You don't have to touch the FDM code itself at all, just call it more often.


    Of course that still doesn't mean the XPlane folks will fix it - not unless there is a financial incentive for them, that is.

  12. 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 online resources; I usually use SkyVector's METAR overlay.


    Now, I don't use XPlane, so I don't know how it works there, but it does make sense to me that a VATSIM plugin would disable the built-in speech synthesis ATIS; after all, if it didn't, then tuning COM1 to the correct frequency would get you both the speech-synthesized one from the sim itself *and* the voice ATIS from VATSIM, and you wouldn't hear a thing. In fact, that is what happens in FlightGear unless you disable the built-in ATIS entirely, and it's extremely annoying.

  13. I thought all approved connection clients had text?


    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 virtually all controllers, can *hear* voice).


    Barring that, text-to-speech is, I think, the most realistic solution.

  14. 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)

    - Possible to do in under 2 hours

  15. 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.

  16. 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 gets 120 updates per second, there's just going to be 15 of them per rendered frame.


    What we do care about is that when the simulator says your speed is 120 kts, then you should be covering 2 miles per minute according to the VATSIM network. Since position data is uncontroversial, the difference is due to in-sim clock vs. VATSIM clock (which in turn should be identical to real-world clock). So a better approach would be to either detect in-sim clock drift (comparing RTC elapsed time since startup against in-sim time since startup), or to detect deviations in ground speed as reported in-sim vs. as seen on the network.


    This approach has several advantages:


    1. It measures what we actually care about.

    2. It doesn't require frequent sampling: just getting the current position and ground speed once every 5 seconds or so, figuring out the ground track distance, and checking whether the effective speed is within limits of the reported speed. No averaging of frame rates is needed, just a bit of an error margin (e.g., at 120 kts groundspeed, you'd expect 2 miles in 1 minute, but 1.98 miles is probably still OK, while 0.95 miles is definitely not).

    3. It's future proof and relatively sim-agnostic - a client like Swift could easily implement this for all supported simulators. This would detect not just automatic time scaling like XPlane does, but also deliberate or accidental meddling with the time factor, pausing, and other anomalities. And if XPlane decides to make the time scaling thing optional via a configuration switch or something, then users solving the problem this way will not be punished for a crime they didn't commit.

  17. 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 necessarily being trained for special situations), and because unlike real-world pilots, we can change the weather if we like, so we can more easily predict that we will be using SVFR when filing our flight plans.

  18. I'm sorry to pick you, but you started it. Since the invention of the wheel, we have engineered all kinds of wheels. Cart wheels, artillery wheels, flywheels, wire wheels, train wheels, just to name a few. Perhaps most notably, gears.


    There are many kinds of wheels, none of which is a replacement for the other. Inventing and engineering are not synonymous. None of the engineers that design the various types of wheels we have today, have invented the wheel or have tried to do so, yet their contraptions are useful in their own domain and not necessarily applicable in another.


    Whoever invented the wheel in the first place, I'm sure would be very impressed with gears.


    That is analogous to someone say about C++, 'why reinventing C?'


    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.

  19. 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 able to navigate visually, and you have to be flying in controlled airspace.

  20. 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...