KiloJuliett

Hi Roland Can you check in the flight planner of the sim where a simple map is shown if that issue is also present. I assume it's an issue of "you see what you get from your simulator". Or in other words, that your simulator has those VOR definitions in its database actually twice. Usually, add-on sceneries should cope with that correctly. What exact scenery of Rhodes do you have installed? Can you check your scenery priorities if they eventuelly cause the issue?

The problem is that the folder C:\Users\Juergen\Documents\Scenery\BASE read from your scenery.cfg doesn't exist. According the log, actually none of the folders listed can be found. So it looks like your scenery.cfg is either completely messed up or your registry points to a (for whatever reason) old/wrong scenery.cfg. Please check if the scenery.cfg located at C:\ProgramData\Microsoft\Fsx\scenery.cfg is the one that should be used. For testing, make sure your sim is not running and you start the EFB server with admin rights.

That is a log from v1, so no help in this case. Please help me to understand why you don't follow my advise in creating a log. Maybe you can do it with the help of the manuals (3 Server, Chapter 2.4)? If yes, please upload the file here. The manuals are also in the EFB folder in your start menu and in the forum (see link below).

Does the mentioned path exist at all? There is a separate program that was installed with EFB. Check your EFB program group via Windows start.

What exactly do you mean? Information about ATC is presented. But it's an EFB, a tool for pilots to make flying easier.

Hi Juergen Is the mentioned directory listed in the scenery list? Did you change your default scenery folder in the registry at some point? Can you provide the log files by creating a support file (lifesaver symbol in the EFB program group)? Thanks

Ok. So to clarify. I do fly online (and also control), as you can see in my signature. But there is also during busy events a good chance you realize what will be your next frequency listening at transmissions to other pilots. So what I'm trying to say here is that you can already guess your next frequency when listening to the frequency before you get your actual frequency chance. But also then and even with the display of v1, especially during events with high traffic and additional stations on, your guess and also the one from EFB can be wrong. Depends a little bit in what area you fly, respective what call signs the controller use (which makes it easier or more difficult for the algorithm to propose the next frequencies). Please understand that my statements are personal and not necessarily reflecting the developers intentions. As a beta tester I clearly see myself not as a developer, but more as a provider of ideas. Because I have very few if any experience on v1, I'm generally less comparing to what was before, but more trying to find out, what information is relevant and when it is needed. So, instead of just blocking my attempt to find out, what bits of information are the relevant ones, help me with it. Keeping the view "everything was better before" will never bring a real development.

Is this limited to EFB or would also other applications like a basic text editor, when you run it in the described scenario, refuse to accept 1-3? Do you have an app installed for key mappings or could it be an interference with other apps? Is the behaviour the same when your complete sim environment is running or if you do a try just with the EFB running.

I think you got my statement wrong. I was responding to the post just before where to issue to find routings with ATC coverage was addressed. I offered an alternativ solution for this, which is clearly a planning step and therefore not something EFB claims to cover. On one hand I can understand that you are missing something while in-flight. I guess we are talking here about a situation exclusive to online pilots. They might have indeed special or different needs and probably there is a solution to satisfy all users, we just haven't found it yet. On the other hand, you will have to listen anyway to the controllers what is the next frequency to go. If it comes to that frequency change, v2 offers better option in setting and switching the frequency directly. Also to read the ATIS, I prefer the version where I can select the station and the text stays then until I change my selection. Especially for touch devices, this is more convenient than the hover-approach in v1. I'm trying now to find out what information from the list in v1 is needed, and where/when exactly to find ideas how it could be implemented in v2. One question is: Do you really no the next station(s) in your area in order to pre-select the frequency. Can't you do this also with listening to the frequency? From the ATIS, you mainly want to have the text, right? Perhaps this can be integrated into the airport sidebar? Like a switch between the METAR information where and the text from the ATIS station. Or an option somewhere to display this text on top (at the bottom) of the map window just in plan text (similar to what the sim can do). For the controller info, maybe this kind of display could also be introduced? Showing up when tuning in the new frequency and stay for x seconds. And maybe could called again to be displayed with a click somewhere or a shortcut. Just a few ideas. Let's talk about. I think design-wise, there are better options than in v1 because the bar takes unnecessarily much space from the map which can be used better. So let's find a way to do it.

It's most probably a question of the interface as EFBv2 is now using FSUIPC to get this data. EFBv1 and FS flight control both work with SimConnect. Both interfaces have advantages and disadvantages. But FSUIPC was chosen for good reasons. I'm sure there is a way to get also the AI traffic data more consistent. However it may need some time for investigation as it is limited to a few users only whereas it works flawless for others.

Is P3Dv4 the simulator you use? Did you start the sim already while the EFB server was running? (Manual 3 Server - Chapter 2.3.1) Your second problem seems not EFB related. Be aware that EFB currently does not support flight plan export to any others than the standard formats (refer to Manual 6 Flightplan - Chapter 5.1).

@Tivec was there other network traffic on the airport you saw in the simulator? Otherwise everything seems to work as it should. This is just difficult to determine as there is no information whether the network client is connected or not. So neither the sim, nor FSUIPC nor EFB does know if network traffic (which looks on the interfaces not different from AI traffic generated by the simulator itself) is "injected" yet. To prevent overlay of "blue" and "red" targets, the "red" traffic is removed as soon as the simulator is detected to be running.

Or use vroute. It has even a prediction of service along your route based on statistics. And of course, it shows currently active controllers and planned sessions (ATC bookings).

There are two kinds of problem reported. One is the missing online traffic while not yet connected to the network (dump file showing red aircraft) which under reproducable circumstances disappears when it is expected to show traffic. I'm sure Urs will be able to solve this within one of the next updates. Regarding the issue of not seeing actual AI traffic in the simulator (which is generated by the network client such as vPilot, showing blue aircraft) when connected to the network, I've not yet really an idea about the causal factor. @Tivec it might be good for us to know what libraries you use to display the network traffic. Maybe this is causing the issue. Can you check if traffic is displayed on the map if you don't use VATSIM, but add some AI traffic directly within your simulator?

Don't think so although all these applications use the same data source. The VATSIM dump exceptionally is not available, but in general it works quite good. It's just important to get the current data servers (file provider) from time to time. Otherwise you may run out of valid sources. This check is done by EFB for sure. I guess also Plan G does it. At least on my computer, this function of Plan G still works seamless.

is then the solution for you.

Maybe an other approach is suitable for you. If you really wish this runway to be named still 05-23, also use an AIRAC file where the runway was still named so. Mappings will be on 05 and 23. As we are in a sim environment, you don't necessarily need to use the latest AIRAC. This may not be true if you are flying in a network environment where both parties have to agree on a certain data base. But matching data sources from different AIRACs (which is the underlying issue as the navigation data is from a different AIRAC than the runway definitions) will always create issues that can be solved as good as practicable or not at all. And please, be kind to each other. Different opinions are no reason to offend someone.

Check that the flight plan window (I assume this is where you change the altitude) is actually the active window. You didn't change by mistake the shortcut settings for the 3 zoom levels available in the client settings, register "Shortcuts"?

That's true. I was able to partly reproduce the issue. When you see no network traffic when not connected to the network, check if it is loaded after you restart the EFB server. You may then have to wait a few seconds (up to 30), but then the traffic should be displayed. It seems the EFB server sometimes does not switch back to the offline display where you would expect so. I could kind of force it by restarting the server. Would be interesting if that works for you as well. However I'll do some further analysis and inform Urs about my findings. I'll keep you informed.

I think it's the other way round than you think. EFB can forward its flight plan automatically to the default GPS. See Manual 5 Client - Chapter 12.2.8.

Looks like you didn't start EFB with admin rights. This will prevent EFB from getting the actual position data from the sim. Start your simulator and move your aircraft to this airport.

Looks for me like a delimiter issue. Might be up to Urs to verify if any system variables are involved here (or influence from the .NET framework). If you see again this situation, please upload the logfiles from the server and client and also the downloaded VATSIM file as described here:

Actually, it is the solution to fix the "why scenery designers do not design the AFCAD as they draw the painting". But finally, BGL files are the only source I am currently aware of where information about the ground layout is saved in an electronic and logic format. Makerunways does also "only" interpret these BGL files. We may check with Pete whether he found a solution to overcome the dilemma we are currently in.

hoops, that happens when you have all the manual open to assist others We have identified this as Oskar wrote. But there is no solution in sight for now as every scenery designer is using the AFCAD with his own interpretation. The reason is because this runway is marked closed. If such runways would be displayed anyway in general, a lot of artificial runways would pop up on other sceneries because designers use them to tweak their AFCAD. So we have only two bad alternatives. Choosing the other one would not kill any of the CONS mentioned (only alter no.2 to read "does display a lot of not existing runways"). I hope you can understand the underlying issue following these explanations.

I was more thinking about intermediate transitions which are used between STARs and the Instrument Approach and are not part of the planned route. There are combinations possible that require either a transition (the list named "Via") or none. So it is necessary to give the option to only deselect a transition. You can always go back to a higher level and deselect for example the type of approach. This will clear all selections up to the type of approach and let you continue directly from there which one click.