Jump to content

Berzerker

Members
  • Posts

    27
  • Joined

  • Last visited

Recent Profile Visitors

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

Berzerker's Achievements

  1. I've already given all the reasons of why I use it often and it's annoying to have to use it so often. You've clearly did not read the thread. I guess it's not annoying to you, and you don't have to understand it. But it's annoying to me, and I've clearly laid out why. Edit: I've just had to use it again, just for an example. I was on the BALSI1D into LFML, I loaded in the approach/runway, and nearing DOLIV, I was told to expect the approach "via DOLIV", well now I have to go back in and select the DOLIV transition, which, of course, reset my plan back to the beginning of the arrival, then I had to select DIR DOLIV again. It could have recognized that I was inbound DOLIV and attempted to reassign it manually. I'm not saying there's a perfect solution, but I think it could be great improved as it stands now.
  2. Well that's why I was saying that it needs to be precise. When you're DIR-TO a waypoint, you're within 1 or even less than 1 NM of passing through or around the waypoint. That should be more than enough distance to recognize that you were or are DIR-TO that point and can update. I can see how passing over a waypoint twice might be a potential issue, but that should theoretically solve itself since if your flight plan is followed properly, the sequence should still play out how it would normally. i.e. you are direct those waypoints, then hold back into the approach, it should be ordered correctly in the flight plan that it will go ELHWA OCUVI HUTUL YUCSU then HUTUL OCUVI ELHWA. I don't think you'd get close enough to another waypoint before passing over one for it to update. As well, I think the logic to auto-update should only be applied if you are passing over a waypoint that's *not* the next one. As long as you don't get within 1nm of another waypoint, there's no reason to bypass any of the routing. However, if you are approaching a waypoint within 1nm that's 3, 4 or 5 waypoints ahead, it should update. Well that's why I ended up making this post because I disagree. I find myself very often having to use DIR-TO because of approach reconfigurations or assignments. It's quite annoying to have to DIR-TO every time my runway changes or I have to put a transition or approach in after not being assigned one while on the arrival. And in most of those situations, I am using DIR-TO to the same waypoint I was DIR-TO previously.
  3. Wouldn't just using the closest waypoint alleviate this issue? even if you have to down to a matter of tens or hundreths of a nm.
  4. That's my point, I think it should not have that requirement. If you pass directly (or within 3nm) of a waypoint, it should update no matter what you've passed before. I can't think of a situation where when you're passing within 2-3nm of a waypoint means that's not your current DIR and it shouldn't update. I think it should be possible to store the current DIR-TO waypoint in "preparation" for an update or approach change. Just have an always updating "currentDIRWPT" variable, something like that. i.e. I'm direct WW984, but I need to change the approach, but WW984 exists on the new input, it should match that and automatically run a "DIR WW984" update.
  5. I can potentially see how analyzing tracks and time and all that can lead to some ambiguity, but I think at least the two things I mentioned in my previous comment are pretty clear-cut when it comes to what's going on: 1) If you pass directly over a WPT or at least within a few NM (1-2nm), it's clear you were DIR that WPT and it should auto update 2) Inputting an approach after already being on the arrival/having input the arrival should put you back on the previous DIR WPT you were on before you input, not back to the beginning. Let me know your thoughts.
  6. I assumed by saying "add in some logic" that meant trying to come up with some way to do it. Obviously if you're nowhere near another WPT then it's probably impossible, but perhaps reading a track and assuming that direct to that track for 5+ or 10+ minutes means you're DIR to that WPT and it automatically updates. Likewise perhaps when overflying another WPT, it can automatically update. At the very least, when updating an arrival or adding an approach, it should not restart you back at the beginning. It should at the very least keep you DIR TO the same waypoint you were before. As for adding an arrival after you've been on a vector or something, for ex, the DIR TO can be automatically applied once flying over a WPT next time (within, say, 2 or 3nm if not an overfly waypoint). Just trying to throw out some ideas.
  7. Would it be possible to add in some logic on the backend that handles situations where if you forget to set a DIR after being given one, it never updates your flight plan once you reach subsequent waypoints? Also, when adding in an arrival, or updating an arrival, it always seems to set your Active WPT to the first WPT in the arrival/approach, it would be good if there was some logic to recognize which one you're inbound to or near, or perhaps to update it once you pass over the next one to know which your Active WPT truly is. Thanks.
  8. I'm having the same issue. I've gotten around it by changing the route to DCTs for each waypoint for now, but would definitely like a fix. I believe something changed with the AIRAC data as of 2307, some other issue happened to STKP and the dev had to put out an update for that.
  9. So for issue #1, will the workaround implemented for issue #2 alleviate this as well? Those of us also on the same Fenix and FSUIPC version are seeing a different identifier in the EFB, so clearly there's some issue here (though I agree probably not with the EFB). Either figuring out the proper addition to add for the A320 profile or having a way to disable the automatic profile selector would be a more-than-good-enough workaround for now.
  10. Is there a workaround for now where we can add the malformed module name to the profile and get it working? I tried adding ATCCOM.AC_MODEL_A320.0 to the list of acceptable airframes but it's still not recognizing it. Or is there a way to disable the automatic profile selector?
  11. I'm also experiencing the same thing, using FSLTL and FS Traffic too. I'm not so sure this is a plane issue to be honest.
  12. Thank you greatly for the detailed explanation. I can confirm placing the APRT file in the directory does solve this issue for Gaya LOWW. If we experience issues at other airports, should we be reporting them here or will they be created in anticipation by Aivlasoft? Thank you again.
  13. Thanks for the clarification on the skipped stuff, looking forward to any updates you have on this.
  14. I am also using Gaya's ORBX LOWW addon, but my layout looks different from yours. As a side-note, this is in MSFS, not P3D.
  15. You're correct, it seems that it's not ignoring it, but the stand numbers don't seem correct. Would they not match the "world map" view? For ex: at LOWW stand E43 shows as "43E" but in the world map view, it correctly shows as "E 43" I assumed those would match. I noticed there's a "navigraph" scenery layer as the 1) layer (I have this too), could this be taking priority or does that have nothing to do with the scenery itself?
×
×
  • Create New...