[Dealing with skipped waypoints and adding arrivals]

On 9/14/2023 at 10:03 AM, GoofyJP said:

@Berzerker Do you have any problems using the "DIR-TO" function? Do you use it that often?
It's no problem to use the DIR-TO function. It's a quick and easy way to react to unforeseen situations   🙂
I don't really understand your insistence on unnecessarily complicating the programming of this software  😮

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.

[Dealing with skipped waypoints and adding arrivals]

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.

 

  

On 8/30/2023 at 9:40 AM, aivlasoft said:

It works for a vast majority of situations, and for all not covered cases just use the DIR-TO function to sync the flight plan.

 

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.

[Dealing with skipped waypoints and adding arrivals]

On 8/28/2023 at 2:42 PM, aivlasoft said:

Especially on certain (RNAV-) approaches this will not work because the waypoints are too close to each other. That's the reason why the requirement was implemented that all waypoints before must be passed. Otherwise the sequence might get a hick-up.

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.

[Dealing with skipped waypoints and adding arrivals]

On 8/26/2023 at 3:45 PM, aivlasoft said:

This is the logic which is implemented already. A WPT is considered as passed if you fly over or by within a range of 3 NM. However, the condition is that all waypoints before must also be passed.

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.

 

On 8/26/2023 at 3:45 PM, aivlasoft said:

There is no other way to accomplish this.

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.

[Dealing with skipped waypoints and adding arrivals]

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.

[Dealing with skipped waypoints and adding arrivals]

On 8/22/2023 at 3:08 PM, aivlasoft said:

If you forget it, how shall the software know about it? I guess that this is not possible.

 

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.

 

On 8/22/2023 at 3:08 PM, aivlasoft said:

Why not just use the DIR-TO function in such a situation? If programmable at all, such a logic would be far too error prone.

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.

[Dealing with skipped waypoints and adding arrivals]

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.

[Invalid Routing]

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.

[Sim Update 12 made changes to AI information.]

21 hours ago, aivlasoft said:

Obviously there are two different issues discussed in this thread.  First, the name of the currently loaded aircraft in MSFS, and second, the names of AI aircraft provided by MSFS. Regarding issue #1, I have the latest version of Fenix' A320 running (v1.0.6.146) and FSUIPC7 v7.3.19 is installed. On the next screenshots you can see that the ICAO type designator is properly detected by EFB:

 

 

 

Regarding issue #2 I can only say that the malformed names are the names of AI traffic and not the name of the own ship. Although these names are created beyond the scope of EFB, I have implemented some 'filtering code' which is trying to extract the ICAO type designator from these malformed names. It will be available with next update which is planned to be released soon. Until then I don't see a workaround except to pause the AI generation by the aforementioned third party tools.

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.

[Sim Update 12 made changes to AI information.]

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?

[Sim Update 12 made changes to AI information.]

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.

 

[Use of MSFS Addon Linker w/ Aivlasoft]

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.

[Use of MSFS Addon Linker w/ Aivlasoft]

Thanks for the clarification on the skipped stuff, looking forward to any updates you have on this.

[Use of MSFS Addon Linker w/ Aivlasoft]

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.

 

[Use of MSFS Addon Linker w/ Aivlasoft]

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?

[Use of MSFS Addon Linker w/ Aivlasoft]

Hello, I use MSFS Addon Linker, which can enable/disable addons and creates symbolic links to the directories in the Community folder. I'm assuming because of this, Aivlasoft doesn't want to read those directories, and I'm getting a "!! Skipped !! (Exclude definition)" notice for all of my custom sceneries.

 

Is there a way to have Aivlasoft be able to read these folders? If I set the folder to something else, it's highlighted yellow and I'm unable to scan.

[#131]

3 hours ago, lonewulf47 said:

First thing is that SU9 has done quite some harm to the filesystem of MSFS. Inorder to do at least some part of cleanup, I heavily recommend to delete the content.xml and have it rebuild by MSFS. Additionaly if you have Navigraph installed, you need to reinstall it after MSFS shutdown.Thereafter a complete rebuild of the database is necessary. After this we may discuss further problems. Without this we are simply unable to give any advice as we have no insight into the state of your MSFS and EFB installation

Before starting this cleanup, if you have any kind of automatic backup systems of any kind, please deactivate it and leave it deactivated.

 

This is all on xplane and P3D, not MSFS.

[#131]

I'm also on 131 on both server and client and I'm getting no VATSIM ATC info either. Only traffic shows up

 

 

I'm also missing stand numbers on all gates. Stands that are just numbers without terminals are completely blank

 

[Scenery scanning when deactivated not working as expected]

6 hours ago, aivlasoft said:

Hello,

 

thank you for sending the files. I have analyzed them and came to the following conclusion:

 

First of all a brief description about the so called 'package-system' and the relations between the files 'add-ons.cfg' and 'add-on.xml':

 

The file 'add-ons.cfg' is kind of a table of contents and it contains the list of your add-ons and for each of these add-ons a path to the directory where the files of the add-on are stored. There are two locations where the file 'add-ons.cfg' can be found, one is below '%ProgramData%' and one is below '%AppData%'.

 

The file 'add-on.xml' contains information about the add-on itself. One part of this information is whether it is a scenery-add-on, or not. If it is a scenery-add-on then the file must contain an XML-node containing the text 'scenery'. This is what the DbBuilder is looking for.

 

Basically the logfile entry '-- No scenery category found' is OK, because there are add-ons listed in the add-ons.cfg which do not have a scenery node (e.g. FSLabs, or FSUIPC). But if the '-- No scenery category found' entry is logged for a scenery-add-on then this is an indication of a serious problem, or in other words, it looks like the 'scenery-node' in the add-on.xml has been removed or has been commented out. If no 'scenery node' can be found in a certain add-on.xml, the DbBuilder will no longer try to scan this add-on when it is creating/updating the database.

 

That's correct. The DbBuilder distinguishes between active and inactive sceneries by simply reading the 'Active=true/false' flag in either the 'scenery.cfg' or in the 'add-ons.cfg' file(s). If the box 'Check all' is ticked then all add-ons will be considered, regardless whether the flag is set to true or false. If the box is no ticked, only active scenery add-ons will be considered.

 

In the logfile which you sent us I can see for example the following entry:
-- No scenery category found in: C:\Users\<username>\Documents\Prepar3D v5 Add-ons\Flightbeam - KDEN\add-on.xml

 

This seems to be a valid scenery add-on of KDEN airport, but it looks like the corresponding add-on.xml does not contain a 'scenery-node' (see above) and therefore this add-on will no longer be considered in the process of creating/updating a database.

 

Conclusion:
I don't know what exactly the Lorby-Organizer is doing when you set a scenery to ON or OFF, but from my point of view it seems that it does some changes in the add-on.xml file. Could you please check whether the content of the file C:\Users\<username>\Documents\Prepar3D v5 Add-ons\Flightbeam - KDEN\add-on.xml will be changed in any way when you switch the KDEN scenery from ON to OFF and vice versa?

 

 

 

Thank you for the detailed explanation. I figured this may have been the case. Seems like the contents of the add-on.xml file for KDEN do not change, but because the addon is disabled via Lorby, the entry actually gets removed completely from the scenery.cfg file. If it's disabled, I can't find it at all in there. So I guess with the way Lorby manages the sceneries, enabling all sceneries then running a rebuild would be the only way I can do a proper rebuild via Aivlasoft.

 

As an aside, would it be possible to add a box disabling the ask to rebuild the scenery database if it detects change? I see this fairly often since I'm always enabling and disabling sceneries.

 

Thank you again for the help.

[Scenery scanning when deactivated not working as expected]

Ok, I've sent the zipped client and server support files and referenced this thread in my email.

[Scenery scanning when deactivated not working as expected]

I think I've narrowed the issue down to it being an issue with addon.xml-based scenery addons. Perhaps I have something incorrectly configured in Aivla or Lorby, but for ex: if I have my US airports disabled, this shows in the log:

 

 

But if I enable them, I then get this:

 

 

So it seems to maybe be an issue with addon.xml based sceneries.

[Scenery scanning when deactivated not working as expected]

I guess, let me clarify my question. Is there any way to have the EFB scan all add-ons even if they are listed as disabled, and utilize custom scenery over default scenery, even if it's disabled?

 

I thought that's what the checkbox was supposed to do, but it doesn't seem to be scanning it properly.

[Scenery scanning when deactivated not working as expected]

Trying to figure out the proper way of setting up scenery scanning. I'd like to have it so all my custom scenery is scanned regardless of if they're enabled or not, but to prioritize custom sceneries over default ones.

 

I use Lorby Organizer to disable sceneries for areas not in use to speed up loading and reduce stuttering, but if I install a new scenery, I have to re-enable all my scenery, then rescan, or else the disabled scenery will get overwritten with the default scenery (since the custom one is disabled).

 

I assume the check box option to "scan all scenery" is how you avoid needing to do this, but it's not working as I expected (disabled custom scenery gets overwritten with default scenery). Is there a proper procedure for this or do I just need to re-enable all scenery before scanning?

 

Thank you.

[A310 Profile]

Based on the A306 profile I made, slightly altered MTOW/MLAW to match A310.A310.profile.xml

[Some extra new profiles]

On 4/14/2021 at 12:05 PM, Bob_Z said:

Is there a profile for the B777-200ER or is the basic profile good enough?

The 772 profile in the top post is for the 200ER. The default "772" profile should really be renamed to the 77L since it's for the LR.