F5 ALT ES/VRC interaction

[Kevin Kan]

I just found out when I hit F5 and [Mod - Happy Thoughts]ign a new alt to a plane, it is not reflected in VRC for the other controllers. I searched but I didn't find this problem.

 

I am using ES.

[Kevin Kan]

Did some experiments with Karl online.

 

F5 key in ES changes only the ALT for ES users.

 

The FPL (.am) dialog box cruise altitude, if amendments are made there, every one including VRC and ES can see the changes.

 

F8 everyone including VRC and ES can see the temp alt changes.

 

 

 

Something is wrong with the F5 key.

Edited November 19, 2009 at 06:27 AM by Guest

[Karl Kornel 964857]

Did some experiments with someone else online.

 

That someone else was me!

 

One other observation: If cruise altitude is currently X, and I change cruise altitude to Y using F5, then disconnect and reconnect, the cruise altitude has changed back to X.

[Todor Atanasov 878664]

From ES wiki

> .qz - available by pressing F5

This function changes the final altitude of an aircraft. Important that it does not change the flight plan, just [Mod - Happy Thoughts]igns a final altitude.

[Gergely Csernak]

There are values (final altitude, temporary altitude, scratch pad string) that are not stores on the servers. If some sets them it is published. If a new controller comes online he asks about these data and the client who tracks the plane (or set this value) responds to this query with the value. If you leave the system and comes online again noone will tell you about the values you set in your previous session.

 

About the VRC-ES incompatibility about F5: Does it work the opposite way? If you set the final altitude in VRC is it visible in ES?

[Ross Carlson]

Note that F5 in VRC also amends the flight plan cruise altitude.

[Gergely Csernak]

Ross,

 

Thx for the info. It solves the problem. ES does not amend the FP in case of F5. And because of that it handles the final altitude message without amendments. Do you think I should change it?

[Ross Carlson]

Ross,

 

Thx for the info. It solves the problem. ES does not amend the FP in case of F5. And because of that it handles the final altitude message without amendments. Do you think I should change it?

 

That's a good question. I've honestly never understood the need for the final altitude packets in the protocol. It seems to me that just amending the flight plan should be sufficient. We already have a protocol for setting a temporary altitude, so I don't know what the final altitude packet is really for.

[Stephan Boerner 945550]

In my understanding, the final altitude is something different than the planned altitude. So even if I change the final altitude, for example due to restriction within my airspace, it has nothing to do with what the pilot originally filed. So I don't touch the planned altitude in the flightplan.

 

Personally I think VRC is doing it wrong and not ES, so obviously I don't think ES' behaviour should be changed. This is not really a question of network protocol but of procedure. The interesting question is, if in reality (and not only in the US, but world-wide) the planned altitude in the flightplan is changed or remains in the plan during the whole flight. If controller always change the planned altitude when [Mod - Happy Thoughts]igning a new level, then VRC would be right. Otherwise ES would be.

[Ross Carlson]

The interesting question is, if in reality (and not only in the US, but world-wide) the planned altitude in the flightplan is changed or remains in the plan during the whole flight. If controller always change the planned altitude when [Mod - Happy Thoughts]igning a new level, then VRC would be right. Otherwise ES would be.

 

Yeah, that's the same thought process I went through when I wrote VRC. I felt that if the flight's *final* altitude was being changed, then that change should also be made in the flight plan, so that controllers further down the line would see it and not wonder why the aircraft was cruising at a flight level other than what the plan showed.

 

But you're absolutely right, this behavior may not be correct when compared with the real world. I have no idea how real systems work in this regard. VRC's behavior was designed to accommodate the way things work on VATSIM, and not create confusion for other controllers handling the flight.

[Todor Atanasov 878664]

Well in real life (in Europe) there are two different entities:

1. Filed Flight Plan - this is what the pilot submits to the Air Traffic Services

2. Current Flight Plan - this is the actual flight plan, taken from the Filed Flight Plan but extended with estimates, FL, and so on. This flight plan is what is send from ACC to ACC via OLDI (OnLine Data Interchange). So in real life when you set final FL you change the FL in the CFL, not in the FFP.

[Stephan Boerner 945550]

That's what I thougt, thanks Todor. So my vote remains at "don't change ES", as it works just the way it is supposed to work.

[Kevin Kan]

We use F5 alot for descents. The thinking is the airplane shouldn't be climbing back up to the cruise altitude if he/she is descending to land. This way when we hand-off to the next controller we know that he is cleared to that certain FL/Altitude.

 

I also prefer that F5 can change the Flight Plan Altitude incase a pilot requests a new FL for cruise, instead of opening the fpl dialog box we use a simple keyboard command.

 

We use F8 only if it's something out of the ordinary, say a conflict is developing one controller will put in a temp alt to show everyone else this plane is cleared to that altitude but will be climbing higher.

 

 

Either way both logic makes sense, if you don't want to change it maybe make F10 key the "change flight plan dialog box cruise altitude."

[Ross Carlson]

That's what I thougt, thanks Todor. So my vote remains at "don't change ES", as it works just the way it is supposed to work.

 

Hrmmm ... I'm confused. On VATSIM we don't have the concept of "current" versus "filed" flight plans. We only have one flight plan. In that sense I would say VRC's behavior is closer to what Todor is describing.

 

As Gergely said, changes to the Final Altitude value are not stored on the server. They are only shared amongst controllers that are in range of each other. (Similar to scratchpad and temporary altitudes.) So with ES, if you set the final altitude with F5, and the flight leaves your airspace and later enters the airspace of another controller that isn't in range of the controller that set the Final Altitude with F5, then the new controller won't see the change. He'll just see what's in the flight plan.

 

Am I missing something?

[Todor Atanasov 878664]

Nope Ross you are not missing it. Indeed if you disconnect the set FL/Alt from F5 (ES) is lost. But VATSIM doesn't work as the real systems, so there shouldn't be a comparison. In the real world, the FFP is available for every user (via AFTN)...the current FP is available only for the next FIR/sector, stored locally only during the flight. In that sense ES is working as in the real life....but here come the VATSIM downside, you disconnect, and in the real life the ACC doesn't stops it servers So ES is doing it the way the real systems works, but for VATSIM it is not enough. Maybe the VATSIM flight plan needs one extra field for that cleared FL, hidden for the pilot, but available for the ATC clients.

[Stephan Boerner 945550]

@Kevin:

 

If you handoff to another controller, you don't need the flightplan entry, because then it is populated via VATSIM. If you send him over to UNICOM, it does not really matter (and in my opinion does not really make sense) because he either is in range for descend and will continue it (what makes the planned level be incorrect as well, because he will continue the descend and the flightplan won't update), or he isn't yet in range for his calculated descend and then he might even climb again back to his planned level, because it's own navigation. So especially for those descend planning I don't see the point in using the flightplan. I would consider it useless especially for that.

 

As controller I would be much more interested in his planned level than in what level any previous controller [Mod - Happy Thoughts]igned to him at some point. Because his planned level is most likely what he will be using for own navigation.

 

The question is, if your procedure is based on any real system, of if it's just "VATSIM/VRC works that way, so we decided to do that". Usually I would just say "make it an option", and everyone would be fine with it, but I can already see the VRC users claiming "please use that, because that's how it works for us"

 

@Ross:

 

No, of course we have the concept of current vs. filed flightplan. Filed is what the pilot filed, current is what is populated over the network. The problem with out special environment is UNICOM, so if an aircraft goes to UNICOM, there is no current flightplan, which is actually correct, because the current flightplan is in that case, what the pilot decides to make it. The best information in that case for the next controller is the planned flightplan, because that is closest to what the pilot planned in the first place, and what he probably will be planning his own navigation after.

[Ross Carlson]

@Ross:

 

No, of course we have the concept of current vs. filed flightplan. Filed is what the pilot filed, current is what is populated over the network. The problem with out special environment is UNICOM, so if an aircraft goes to UNICOM, there is no current flightplan, which is actually correct, because the current flightplan is in that case, what the pilot decides to make it. The best information in that case for the next controller is the planned flightplan, because that is closest to what the pilot planned in the first place, and what he probably will be planning his own navigation after.

 

That's one way to look at it, but another way to look at it is that it is more realistic for the altitude NOT to revert back to the original filed altitude when a flight goes from controlled airspace, to uncontrolled, then back to controlled again, because such a case is an anomaly of VATSIM ... that doesn't happen in the real world. In many cases the pilot is going to stay at the new final altitude that the controller [Mod - Happy Thoughts]igned, so when he goes to uncontrolled airspace, then back to controlled airspace, he's going to be at a different altitude than his flight plan reflects. (If the controller that [Mod - Happy Thoughts]igned a new final altitude was using ES.)

 

Two different ways to look at it ... and neither is fully correct. The fact that we have highly unrealistic gaps in coverage is the only reason it's even an issue. I personally think it's better to have the final altitude change persist, because it does in the real world. And the only way to do that on VATSIM where we have gaps in coverage is to amend the flight plan. It's a compromise.

[Jonas Eberle]

I would vote for compatibility, thus only workling with flightplan RFL and Temp FL.

 

I think all scenarios can be depicted with these. If you can only climb an aircraft to a certain altitude, this can be shown via the temp level.

[Stephan Boerner 945550]

And in many cases he won't stay at the level, so that approach won't really lead us anywhere. I would for example say that it's more realistic to have the filed flightplan preserved instead of any controller's amendment. Different oppinions with no right or wrong, but compared to the European system, it would definitly be a backstep to adopt the VRC way.

 

But speaking of compatibility, that is the real issue. We are already way past the point, where it makes sense to keep such stuff compatible. The network protocol is our master concerning compatibility. If we would measure EuroScope development on VRC compatibility, we would have no coordination, no extended tag information, no plugins because all that is not compatible with VRC. Don't get me wrong, I have used VRC for a long time, and I threw ASRC of my HDD the day VRC was released. But (as far as I am informed) VRC is a dead client as far as development is concerned. (correct me if I am wrong.) Of course VRC will remain an actively used client for several years, but as long as Gergely keeps providing us with his outstanding work, the gap between VRC and ES will constantly grow and compatibility issues will grow in numbers. We can not measure ES development compared to VRC. We have crossed that line the moment ES started to use the scratchpad to store it's data.

 

Personally I would very much appreciate a VRC v1.3 to adress such compatibility issues. In that case it would make sense to talk about standards for storing data and have them implemented and kept compatible. As long as this does not happen, there is no point in doing it. Then the VATSIM protocol is relevant. The scratchpad allows more than 4 chars, so ES uses them. If VRC does not, it is a VRC issue and not ES storing [Mod - lovely stuff] in it (as some VRC user claim). If VRC links F5 and the fligtplan, so be it. But it is not an ES issue to follow, if it is more realistic not to do it.

 

I don't know if it is realistic to speculate on network-side changes to for example implement a second FL field for the current fligtplan as Todor suggested. That would be a solution ... Linking the protocol value to the flightplan in ES is none.

[Ross Carlson]

But speaking of compatibility, that is the real issue. We are already way past the point, where it makes sense to keep such stuff compatible. The network protocol is our master concerning compatibility. If we would measure EuroScope development on VRC compatibility, we would have no coordination, no extended tag information, no plugins because all that is not compatible with VRC.

 

There's a difference between the items you mentioned here (coordination, extended tags, plugins) and the F5 issue. The former are additional features not present in existing clients. The latter is different behavior for features that all clients share. The latter is where actual problems can develop.

[Kevin Kan]

@Kevin:

The question is, if your procedure is based on any real system, of if it's just "VATSIM/VRC works that way, so we decided to do that". Usually I would just say "make it an option", and everyone would be fine with it, but I can already see the VRC users claiming "please use that, because that's how it works for us"

 

We just use it to show new levels. It's a procedure we adopted which I don't know if it's real or not, but it's our equivalent of manually updating flight strips compared to the real world, to show our own controllers in the APP area the pilots their cleared level.

 

 

I just don't see the purpose of having a third option where ES stores a value but it disappears as soon as you log off or he goes to unicom area. Your simulating a server that stores all this information (ALDI in your case), but nothing exists to actually do anything with this data. I think it is very nice that Gergely has simulated another real system, but in this case I don't think it's useful, especially since in VATSIM we go back and forth between 3 different controlling clients.

 

 

I also don't see any compatibility issue between ES/VRC. It's the same functions (F5 key) that operate differently.

[Gergely Csernak]

Huuh. It seems to be an interesting topic now. An I am in a complete trouble what to do and what not.

 

I have to admit that when I was programming the protocol I did not have so many things about the European and other systems in my mind. I purely concentrated on the protocol and tried to send and interpret all possible packets. When I found the Final Altitude message I simply thought that this packet is to override the requested level without amending the FP. So ES interprets it packet and uses it as an override. When you change the RFL (by F5 or other ways) sending the FA packet seemed to be enough for me. At that time I wanted not to amend the FP without explicit user request.

[Stephan Boerner 945550]

But speaking of compatibility, that is the real issue. We are already way past the point, where it makes sense to keep such stuff compatible. The network protocol is our master concerning compatibility. If we would measure EuroScope development on VRC compatibility, we would have no coordination, no extended tag information, no plugins because all that is not compatible with VRC.

 

There's a difference between the items you mentioned here (coordination, extended tags, plugins) and the F5 issue. The former are additional features not present in existing clients. The latter is different behavior for features that all clients share. The latter is where actual problems can develop.

Agree, even though the F5 issue is only partly different behaviour. Yes, it was not intentional to have it that way, but by having it, it turned out to be kind of an additional feature by giving us the possibility to make a difference between planned level and current level as it is done in reality. So it is no longer only about behaving differently. Changing the behaviour would eliminate an extra feature that - admittedly - is not really a feature literally but in fact affects controlling as a feature.

 

We just use it to show new levels. It's a procedure we adopted which I don't know if it's real or not, but it's our equivalent of manually updating flight strips compared to the real world, to show our own controllers in the APP area the pilots their cleared level.

That would be, what's supposed to be done via F8, not F5 and not the flightplan.

 

I just don't see the purpose of having a third option where ES stores a value but it disappears as soon as you log off or he goes to unicom area. Your simulating a server that stores all this information (ALDI in your case), but nothing exists to actually do anything with this data. I think it is very nice that Gergely has simulated another real system, but in this case I don't think it's useful, especially since in VATSIM we go back and forth between 3 different controlling clients.

That's not correct, neither in technical nor procedureal matter.

 

VATSIM is the server we use, simulating any real world database that might be used in whatever country on whatever system. VATSIM stores the flightplan, so the value stored in the flightplan is what we called "planned level" in this thread. That is what the pilot files, so no difference to real world. Ross decided to write VRC in a way, that F5 amends RFL and flightplan together. Just because he did that, you can not conclude that this means this is the same value. The RFL and the temp level are both values that are p[Mod - Happy Thoughts]ed from client to client. So that simulates (in limited ways) systems like OLDI, with one flaw: that data is not permanently stored on the server.

 

We probably all do not know what the intention behind the valued offered by the protocol were supposed to be used for. To be fair, years ago probably noone ever thought we would get that deep into realism and the simulation, so probably there was no intention that would help us understand now.

 

The fact that we do not have full coverage all the time means, that there are limits for our simulation. Those limits are determined by the network protocol and by the fact that there is no 24/7 airspace coverage like in real world and no supranational databases and networks apart from the VATSIM servers and their protocol restraints. Within those limits we have to act. As I said earlier, those coverage wholes and UNICOM do not conflict with that cl[Mod - Happy Thoughts]ification of F5 and the flightplan, because there simply is no control on UNICOM, so there is no current level to be stored for that time, as the pilot is in control and any level you issued previously is no longer mandatory, and so there is no value that would have to be distributed to other ATCs.

 

You saw that somehow different and adopted a system of controlling, using the flightplan to avoid losing those data during coverage holes. From all I know, that's not the way it is supposed to be used by design (speaking of the server protocol and the client, no matter which one, as what you are talking about is what F8 would be supposed to be used for), but why not. I for example use the speed restriction value myself to note down the position reports when controlling oceanic, which is also some way it's not supposed to be used. It's fine to establish other procedures, as long as we are aware, that we are using it a different way than it is supposed to be used, and that there is no guarantee that this will stay supported.

 

The purpose of having a third option is not to lose the planned level, which is (as we now learned) at least in Europe stored for the whole flight. You are abandoning that data willingly when ammending the flightplan. You consider that data useless, I don't (and real world ATC also considers that data important enough to store it for the whole flight). And especially concerning the matter of UNICOM, the planned level should be considered even more important that it is in real life where should be a consistant current level as the (IFR-)flight should be under control the whole time.

 

@Gergely: if any change, then an option. Definitly no permanent link between F5 and the flightplan. By the way, I just thought of something related to that we need to discuss in development.

[Ross Carlson]

I'm missing something here. The answer to this question should help my understanding:

 

In the real world, under what circomestances would the pilot return to his filed altitude after a controller has [Mod - Happy Thoughts]igned a new final altitude? In other words, if we were to consider extending the VATSIM network protocol to allow storage of a new final altitude in addition to the planned altitude, when would the planned altitude ever need to be referred to, after a new final altitude was set?

[Kevin Kan]

We just use it to show new levels. It's a procedure we adopted which I don't know if it's real or not, but it's our equivalent of manually updating flight strips compared to the real world, to show our own controllers in the APP area the pilots their cleared level.

That would be, what's supposed to be done via F8, not F5 and not the flightplan.

 

If I clear him to descend on the STAR to 8000ft, why would the pilot need to climb back up to cruise?

 

It's just a different way of controlling. F5 for descents and F8 for climbs. Nothing says F8 is the only thing we have to use for climbs and descents. To have all controllers on the same page we made it into an SOP. For arrivals we F5 the new hard altitude, and since the pilot is planning to land we do not expect him to climb. Even if he wanted to divert, that would be an entirely new clearance, with new routing and new altitudes. For departure we only use F8 if the altitude the pilot is going to is not according to the SOP.

 

I don't see the purpose of simulating something that cannot be stored on the server for everyone to see. The final altitude is an important piece of information for the next controller, either after unicom or ones on VRC to see, no matter which position they are on, from DEL to CTR.

 

If I am controlling DEL with ES and i change the pilots altitude because it's invalid with F5, then the CTR controller using VRC can't see it. By your logic since it's the Cleared Flight Level and not the Requested Flight level I should be using the F5 key and not open the dialog box.

 

If it is changed, I don't see it as a step backwards in development or controlling. It just aligns all controller into the same page.

 

I also re-read your post on top there. If the pilot is in unicom and will land in unicom, I agree it doesn't matter what it says. If the pilot filed FL350 but only FL340 or FL360 is valid, well I don't expect the pilot to go back to FL350 because it's invalid. I would care more about the last [Mod - Happy Thoughts]igned altitude versus his planned.

 

@Gergely: If it's changed or not, it won't really matter. Either way people have to adapt their controlling styles to the clients limitations