Center working airports below Class B

[Ross Carlson]

James, I would argue that your way is far LESS realistic for the majority of those involved. You are not providing local control to airports that would normally have it. Your way is more realistic for you, the center controller, but it is less realistic for everyone else on the network, because all those airports in your ARTCC that would normally have local control, don't have it.

 

It's worth pointing out that you are already breaking realism by staffing a full ARTCC instead of the small sector that you would normally staff in the real world, plus you are handling all the TRACON radar services, right? That's not realistic either. You are already making realism sacrifices due to the limitations of VATSIM ... why not do the same and provide local control at towered airports? Again, it's more realistic for the pilots if you do so.

 

Note that I'm not saying every CTR controller on VATSIM should provide local control at every towered airport ... I realize that workload issues are a significant factor here. I'm just pointing out that the realism knife cuts both ways. When you as a CTR controller decide that you aren't going to provide local control at towered airports, you are making things more realistic for yourself, but less realistic for everyone else.

 

Edit: It could even be argued that you are making things less realistic for yourself, too, in that you will have to treat normally towered airports as untowered, and not be able to have more than one aircraft cleared for an approach to such a field at the same time. Whereas in reality, it would be perfectly acceptable. (I don't know if this restriction still exists for non-towered airports in the real world ... it's what I was taught 5 years ago when I became a VATSIM controller ... I [Mod - Happy Thoughts]ume it does.)

[Owen Catherwood 903683]

Edit: It could even be argued that you are making things less realistic for yourself, too, in that you will have to treat normally towered airports as untowered, and not be able to have more than one aircraft cleared for an approach to such a field at the same time. Whereas in reality, it would be perfectly acceptable. (I don't know if this restriction still exists for non-towered airports in the real world ... it's what I was taught 5 years ago when I became a VATSIM controller ... I [Mod - Happy Thoughts]ume it does.)

 

One-in-one-out still applies for all IFR flights to non-towered airports, and instrument procedures to towered airports where only the slow-updating ARSR provides coverage.

[James McMannamy]

It's not. If it works like the real world, I have no problem with it. That is, if the airport would be closed in real life, with no controllers, then I expect it to be closed in VATSIM during the same period, also with no controllers.

 

The airport does not close when the tower closes! When ATW and GRB towers close, Minneapolis Center takes over GRB approach airspace (it reverts to cl[Mod - Happy Thoughts] E airspace), and MSP_CTR treats ATW and GRB as uncontrolled airports. Airplanes can (and do) operate out of both airports all night long. Minneapolis Center doesn't clear airplanes for takeoff or landing.

 

It could even be argued that you are making things less realistic for yourself, too, in that you will have to treat normally towered airports as untowered, and not be able to have more than one aircraft cleared for an approach to such a field at the same time. Whereas in reality, it would be perfectly acceptable. (I don't know if this restriction still exists for non-towered airports in the real world ... it's what I was taught 5 years ago when I became a VATSIM controller ... I [Mod - Happy Thoughts]ume it does.)

 

Not exactly true. I can have more than one aircraft on an approach, or one released with one on the approach to an airport without a tower. You just have to ensure standard IFR separation between the aircraft . . . two aircraft cleared for an approach 10 miles in-trail is very common at busy uncontrolled airports. Learning how to manage these aircraft going into and out of uncontrolled airports should be part of the training curriculum at the approach and center levels on VATSIM, since it really is ATC 101 in a radar environment.

 

It's worth pointing out that you are already breaking realism by staffing a full ARTCC instead of the small sector that you would normally staff in the real world, plus you are handling all the TRACON radar services, right

 

ARTCCs combine sectors all the time during low traffic periods. So do approach controls. Centers take over approach controls during low periods of traffic every day. If VATSIM traffic was the equivalent of real world traffic, there wouldn't be a single approach control in this country, except for a few events, where there already is adequate staffing.

 

Note that I'm not saying every CTR controller on VATSIM should provide local control at every towered airport ... I realize that workload issues are a significant factor here. When you as a CTR controller decide that you aren't going to provide local control at towered airports, you are making things more realistic for yourself, but less realistic for everyone else

 

It's more realistic to NOT get local services at an airport when the tower is closed. Like I said above, learning how to manage traffic into and out of uncontrolled airports (which is a skill that is ignored frequently during training on VATSIM) should be part of a controller's training.

 

If no center controller is online, that airspace becomes cl[Mod - Happy Thoughts] G (why? By definition, airspace with no air traffic control is cl[Mod - Happy Thoughts] G airspace). If the tower is not online, why then would the airport be controlled? Now it's a double standard, and we wonder why so many new pilots are confused.

 

All I am saying is that ATC facilities shut down every day, and there are established procedures to follow when it happens. We should follow those procedures because it's reasonable to do so, and we're NOT providing inferior services to pilots when we do (otherwise the FAA wouldn't allow any facilities to close overnight).

[Ross Carlson]

Not exactly true. I can have more than one aircraft on an approach, or one released with one on the approach to an airport without a tower. You just have to ensure standard IFR separation between the aircraft . . . two aircraft cleared for an approach 10 miles in-trail is very common at busy uncontrolled airports. Learning how to manage these aircraft going into and out of uncontrolled airports should be part of the training curriculum at the approach and center levels on VATSIM, since it really is ATC 101 in a radar environment.

 

I agree that handling IFR traffic into and out of uncontrolled airports should be part of VATSIM training, absolutely. It already is in many ARTCCs.

 

That, however, is completely beside my point. My point is that when you as a CTR controller don't provide TWR services at a field that would normally have TWR services at that time, then you are breaking realism for every pilot that may fly into or out of that field. You are making it more realistic for yourself only, by saying "I'm a CTR controller therefore I don't provide local control". But you are making it less realistic for everyone else. On VATSIM, we sometimes need to make a concession and operate as BOTH CTR and TWR controllers, in order to keep things realistic.

 

ARTCCs combine sectors all the time during low traffic periods. So do approach controls. Centers take over approach controls during low periods of traffic every day. If VATSIM traffic was the equivalent of real world traffic, there wouldn't be a single approach control in this country, except for a few events, where there already is adequate staffing.

 

Again, that's beside the point. Just because a given procedure has as real-world mirror does not mean that it is realistic to do so ALL the time. For example, my home airport (KBTV) has a TRACON that closes at midnight. Boston center takes over when it closes. If I'm on BOS_CTR, and it's 5 PM, then it is unrealistic for me to provide approach services at KBTV. I am already breaking realism by providing those services at that time, because in the real world, someone else would be doing it. It's not much of a stretch to break realism even further by also providing local control at KBTV, even though in the real-world someone else would be doing it. Again, the point is that we make realism concessions all over the place on VATSIM ... providing local control when you are also providing enroute control is no different.

 

It's more realistic to NOT get local services at an airport when the tower is closed.

 

I asbolutely agree ... which is why the tower should not be closed if it is not normally closed in the real world at the given hour. The fact that the normally-open tower is being closed is what's unrealistic here.

 

If no center controller is online, that airspace becomes cl[Mod - Happy Thoughts] G (why? By definition, airspace with no air traffic control is cl[Mod - Happy Thoughts] G airspace). If the tower is not online, why then would the airport be controlled? Now it's a double standard, and we wonder why so many new pilots are confused.

 

Pilots are confused because there is no standard. Different ARTCCs have different policies on how this is handled. At some ARTCCs, CTR only provides local control at the cl[Mod - Happy Thoughts] B fields. In some cases, it's up to the controller based on workload. At some ARTCCs, CTR provides local control at any towered field. Some observe normal closing hours for cl[Mod - Happy Thoughts] C/D fields, some don't. There is no standard. Sure, it would be easy to make a network-wide standard that any tower that doesn't have an actual _TWR controller staffing it is to be handled as an untowered airport, but that would do a major disservice to pilots. We need a compromise.

 

All I am saying is that ATC facilities shut down every day, and there are established procedures to follow when it happens. We should follow those procedures because it's reasonable to do so, and we're NOT providing inferior services to pilots when we do (otherwise the FAA wouldn't allow any facilities to close overnight).

 

I agree completely ... where I think our opinions differ is on *when* those facilities should be shut down.

[Steve Ogrodowski 876322]

This whole discussion is very entertaining . Everyone wants to believe that this is an issue of "realism." It's "realistic" to do it this way, it's "realistic" to do it that way. The thing is, like Ross pointed out...the "realism" point can be twisted to anyone's desire...it really holds no merit.

 

Here's the issue here...it's of VATSIM nature. Do you take the environment of VATSIM and only take the literal, face value of it and apply procedures? Or do you take it and plug in a bit of role play and imagination? I'm not sure how clear that is for everyone to understand, so I'll try to expand:

 

The "literal" view of VATSIM, that looks at the way we are staffed and takes it at face value, word-for-word...is James' & Nick's camp. They look at the ServInfo VATUSA map, and they see three centers lighted up, a couple towers, and a couple tracons. And so they see three consolidated center controllers, a couple local controllers, and a couple consolidated approach controllers. Everything else is closed, and quite literally...uncontrolled. It doesn't matter what it would be in the real world, if there's no controller there on VATSIM...it's uncontrolled & otherwise closed. (Another example of what would be a "literal" point of view...is the unifying factor of VATSIM provided weather or day/time. VATSIM provided weather would be the ground rule...anyone using something different would be straying from what the state of VATSIM was at the moment)

 

The "imaginative" view of VATSIM, that looks at the way we are staffed, and takes a more expansive view of the services he's providing. They look at the ServInfo VATUSA map, and they see three centers lighted up, a couple towers, and a couple tracons. But to them, let's just look at the centers. To them, the centers are "CTR" in the sense of taking up one of the VATUSA ARTCC airspaces...but they are also "pretending" to be approach controllers, tower controllers, ground controllers, etc...for all those other airports under their airspace. They look at the airspace and say...in the real world right now, a bunch of these airports would have services...and so I'm going to pretend I'm those controllers. (Another example of what would be an "imaginitive" point of view...is the mimicking of current real world ops. Some of these controllers would have fun to find out that there...I dunno, is "gate-hold" in effect at their airport, and would have fun emulating that on VATSIM...even though our actual traffic levels don't justify it)

 

A VATSIM issue of the "imaginative" view, especially in the eyes of the literalists...is that the software & network will only let a single person act as a single callsign & frequency. There would be less of an issue here if a single person could actually log in and have twenty callsigns and frequencies operated for all of the airports/positions that they want to emulate. And so that's the issue...of whether you think that we can extend and "pretend" that we are acting as more positions than we appear as on the network, or you can take our positions and procedures and only serve as if you are just serving singularly as the callsign you log in with.

 

And neither side is more realistic than the other. The "literalists" can look at it and see the realism of using different phraseology and procedures when certain towers are closed, like James pointed out. He's right. But the "imaginists" can look at the map at 7:00 EST on Tuesday and say...well, in the real world...almost every one of these airports would normally be open and staffed, and we would be realistic in acting as if all these airports are open on VATSIM. That's right, too. I can [Mod - Happy Thoughts]ert that the latter is more realistic than the former...but that is just a subjective viewpoint, since VATSIM is still so far from the real world anyway. I can throw some fake numbers at it too. If there were a "meter" of how "real" something was, the real world would be 100% real. VATSIM is probably about 25% real on that meter...and the validity of either of the two opposing view points I mentioned in this paragraph are barely worth a percentage point, and wouldn't tip the scale by any means. EDIT: (the number stuff, the latter-former [Mod - Happy Thoughts]ertion...are jokes, of course )

 

And just like everything, there are people on-the-fence or in-between, that agree with certain concepts from one and certain concepts from another. In my eyes, it's harder to have a literal point of view...because it sort of locks you into a certain methodology of doing things and doesn't really allow for leeway. If you are hardcore to the literal point, you can't really justify...say, emulating that "gate-hold" procedure I just used as an example. If you did...you would be jumping hypocrisy, since there is not likely a basis for you to use a gate-hold on VATSIM (they are usually only justifiable during events).

 

I personally have a more "imaginist" view of how we provide services. When I look at HOU_CTR, I see an enroute controller as well as multiple approach controllers, local and ground controllers with a whole bunch of open facilities. I believe in using proper phraseology...within the belief that I am pretending I'm a whole bunch of different controllers. Perhaps when you look at HOU_CTR, you just see an Enroute controller with provisional services. And you might believe in using proper phraseology...to the effect of pretending you are that singular controller bound to operating just within the limits that specific facility/controller would normally have.

[Jim Johnson 814050]

There would be less of an issue here if a single person could actually log in and have twenty callsigns and frequencies operated for all of the airports/positions that they want to emulate.

 

This is where I would love to see VATSIM end up! No more logins... just log in with your CID in your ARTCC, and then select the sectors you're working. The pilot only needs to tune the proper freq on the chart and he'll come up on one of the freqs you're working. That would be very realistic as frequencies are combined all the time real world (i.e. pilots may be transmitting on 4 different freqs, but the same controller is responding to all of them).

 

If we could just get this and standardized display of thunderstorm activity with weather radar, I would be one very happy controller

[Keith Smith]

Excellent discussion. It's nice to see it holding together without exceeding Vne!

 

Steve, you are spot on with your view of the imaginative vs literal view with regarding to interpretation of staffing. I agree that there isn't a right or wrong way to handle this, and that it is reasonable for VATUSA to defer to each facility.

 

I ran an experiment a few years back while controlling ZLA. I asked each pilot to address me using the ROLE I was serving, rather than my actual callsign. It removed all ambiguity and mystery from the process. Very few ppl called me "Oakland Center". I was "Livermore tower", "San Carlos Tower", "San Francisco delivery", "Reno Departure", etc.

 

The only point I'd like to reiterate is that if we take the literal view, rather than the creative view, then VFR pilots who fly out of smaller towered fields, practically speaking, are NEVER going to receive tower service. I acknowledge that it's not a large number of pilots, but in terms of providing a realistic experience for them, I think it's worth the effort. I also argue that the level of effort is minimal, because unless you're talking about a pattern full of airplanes, the incremental increase in workload is minimal.

 

Picture this, a real world student pilot hears about VATSIM, makes the effort to plug in, connects at his local Cl[Mod - Happy Thoughts] D airport, reads the PRC and various rules about the inverted-wedding-cake staffing model, calls for taxi for pattern work or even a VFR departure out to the practice area. He gets "freq change approved". I guarantee it is a letdown and will not meet his expectations.

 

Btw, in the time it's taken to write this post, I've handled 4 VFR operations at Cl[Mod - Happy Thoughts] D fields. It does happen!

[Anthony Atkielski 985811]

If we could just get this and standardized display of thunderstorm activity with weather radar, I would be one very happy controller :lol:

 

I think having multiple frequencies per controller makes lots of sense, and would be very realistic. It would not require a change to the pilot clients. I don't know what's required on the server side.

 

And there is a solution for the weather. If all client software generates weather based on a predetermined pseudorandom seed value (say, 256 bits, generated randomly and distributed over the network), it is possible for every pilot and controller on the network to see exactly the same weather, right down to the individual clouds. However, this would require quite a bit of software modification, and since Microsoft would not buy into it and it could not be retrofitted into MSFS, everyone would have to use a program like ActiveSky (which would have to be enhanced to allow this, if it doesn't work this way already). If this were in place, all VFR traffic could see and avoid the same clouds (whereas right now every pilot sees a somewhat different [Mod - Happy Thoughts]ortment of clouds).

[Brad Littlejohn]

If we could just get this and standardized display of thunderstorm activity with weather radar, I would be one very happy controller

 

I think having multiple frequencies per controller makes lots of sense, and would be very realistic. It would not require a change to the pilot clients. I don't know what's required on the server side.

 

You're meaning as in having a controller use multiple frequencies (as they do when they combine because one sector closes) and the pilot responds on one of those frequencies?

 

If so, nothing needs to be done on the client nor server side. The ATC client can use multiple frequencies and the pilot responds on the one he's asked to switch to.

 

Example: real world KVGT's AWOS says that for questions or IFR clearance after the tower closes, to contact Las Vegas Approach on 133.95. When L30 combines, they combine on 125.02; yet the controller keeps all normal L30 frequencies coupled on his frequency so he can call out on them in case someone calls in. So when that lone guy at VGT calls in on 133.95, the controller tells him to "change to my frequency 125.02" and all is well.

 

Same applies in VRC, ASRC, and Euroscope.

 

BL.

[Ross Carlson]

It would require ATC client and server changes for a controller to open more than one frequency, and have pilots auto-connect to the controller's voice room when tuning any one of those frequencies. I [Mod - Happy Thoughts]ume that's what Anthony is referring to.

[Nicholas Fredrich 827138]

So this again begs the question.... why not let it be up to the individual controller to decide what types of services they will provide to cl[Mod - Happy Thoughts] C / D airport? one mans garbage is anothers treasure.

[Bryan Wollenberg 810243]

It would require ATC client and server changes for a controller to open more than one frequency, and have pilots auto-connect to the controller's voice room when tuning any one of those frequencies. I [Mod - Happy Thoughts]ume that's what Anthony is referring to.

 

I think this is what Anthony and Brad are referring to, and I agree that it would be an awesome feature. I always planned after events to recommend this feature, but then always just forgot about it. Doh!

 

It would be great if you could open multiple frequencies as a controller, and have those frequencies be recognized by pilots, so they don't just drop out of the voice room. That's exactly how it works real world, so when a position combines with another, you don't have 20 "Contact LA Center on 133.2"s taking place. The controller just takes the other guy's frequencies and the aircraft have no idea a change even took place. Same would be true on VATSIM when an approach control combines with center, for example. Center would just take approach's frequencies and that's that.

[Anthony Atkielski 985811]

You're meaning as in having a controller use multiple frequencies (as they do when they combine because one sector closes) and the pilot responds on one of those frequencies?

 

The controller would broadcast on multiple frequencies simultaneously, whichever frequencies he is staffing. He would not attempt to treat each frequency separately; all frequencies would hear whatever he said at the same time.

 

Pilots would see multiple frequencies and would choose whichever frequency the charts dictate, with ATC giving handoffs thereafter. ATC might even hand off to a different frequency manned by the same controller (as sometimes happens in real life, from what I understand).

 

If so, nothing needs to be done on the client nor server side. The ATC client can use multiple frequencies and the pilot responds on the one he's asked to switch to.

 

Example: real world KVGT's AWOS says that for questions or IFR clearance after the tower closes, to contact Las Vegas Approach on 133.95. When L30 combines, they combine on 125.02; yet the controller keeps all normal L30 frequencies coupled on his frequency so he can call out on them in case someone calls in. So when that lone guy at VGT calls in on 133.95, the controller tells him to "change to my frequency 125.02" and all is well.

 

Same applies in VRC, ASRC, and Euroscope.

 

Cool. So why isn't it done?

[Anthony Atkielski 985811]

I think this is what Anthony and Brad are referring to, and I agree that it would be an awesome feature. I always planned after events to recommend this feature, but then always just forgot about it. Doh!

 

It would be great if you could open multiple frequencies as a controller, and have those frequencies be recognized by pilots, so they don't just drop out of the voice room. That's exactly how it works real world, so when a position combines with another, you don't have 20 "Contact LA Center on 133.2"s taking place. The controller just takes the other guy's frequencies and the aircraft have no idea a change even took place. Same would be true on VATSIM when an approach control combines with center, for example. Center would just take approach's frequencies and that's that.

 

So how hard is it to make this happen?

[Norman Blackburn]

Since it appears you missed this one:

 

It would require ATC client and server changes for a controller to open more than one frequency, and have pilots auto-connect to the controller's voice room when tuning any one of those frequencies.

[Brad Littlejohn]

Since it appears you missed this one:

 

It would require ATC client and server changes for a controller to open more than one frequency, and have pilots auto-connect to the controller's voice room when tuning any one of those frequencies.

 

Would it (honestly; not trying to be snide)?

 

IIRC, at least with ASRC, you could still manually type in the address to your voice frequency in your controller info and still keep it hidden so the prats on Roger Wilco won't get on and cause trouble.

 

From there, you could open up the other channels and and select them for Rx and Tx, and you should be able to transmit on all additional frequencies, while a pilot on one of those frequencies will not hear a pilot on another frequency, but both will hear you.

 

We did that once at L30 once during an event some 4 or so years ago, when a controller working a split approach sector needed to go, and instead of handing off all his pilots to the other controller, the other controller [Mod - Happy Thoughts]umed control of the frequency of the guy leaving.. But once again, this was with ASRC.

 

Not for nothing, do you have a general idea of what changes that would need to be made at the server level?

 

BL.

[Norman Blackburn]

Brad,

 

I honestly cant recall doing it in ASRC but know that only one voice room will show with VRC no matter what you try. At server level (simplified from my limited knowledge) would mean that the current limits of valid controller / valid suffix (unless Sup/Adm) / in range / voice details would need ammended to allow multiple occ[Mod - Happy Thoughts]ions. Ross would be best placed to answer.

[Ian Elchitz 810151]

A bunch of stuff

 

I'm with Steve on this one. An excellent example. I too am an "imaginist" type controller when I plug in.

 

I believe Keith Smith was the one who pushed for full Cl[Mod - Happy Thoughts] D service at the facility where I control. At first I really wanted to limit myself to Cl[Mod - Happy Thoughts] C and B, but after a while I saw the light. Working the "D" stuff while on a radar position added a lot of great variety to my experience.

 

Of course, just like anything else - workload comes into play. If I'm slammed then I simply won't be able to handle guys in the pattern.

 

Working those FLIBs into the small towers is a lot of fun.

[Ross Carlson]

Would it (honestly; not trying to be snide)?

 

IIRC, at least with ASRC, you could still manually type in the address to your voice frequency in your controller info and still keep it hidden so the prats on Roger Wilco won't get on and cause trouble.

 

From there, you could open up the other channels and and select them for Rx and Tx, and you should be able to transmit on all additional frequencies, while a pilot on one of those frequencies will not hear a pilot on another frequency, but both will hear you.

 

We did that once at L30 once during an event some 4 or so years ago, when a controller working a split approach sector needed to go, and instead of handing off all his pilots to the other controller, the other controller [Mod - Happy Thoughts]umed control of the frequency of the guy leaving.. But once again, this was with ASRC.

 

Not for nothing, do you have a general idea of what changes that would need to be made at the server level?

 

BL.

 

What you did at L30 is not the same as what Anthony is describing. In your example situation, pilots still only saw one frequency in their list. Any pilots already on any of the L30 sector frequencies would be able to communicate with the one controller after the consolidation, but any new pilots would have to tune his primary frequency.

 

The idea behind Anthony's scenario is that a pilot could tune whatever frequency he would tune in the real world, and get a controller. For example, if I'm covering a consolidated GND/TWR at KBTV, a pilot could tune *either* 121.9 or 118.300 and be connected to me. The pilot would see *both* frequencies in his list of available frequencies. In another example, if I was covering all of Boston Approach, pilots could tune either 118.25 or 120.600 and talk to me. We can't do that with the current software. Essentially, controllers would have more than one primary frequency. Neither the server, nor the ATC clients support this notion of more than one primary frequency per controller.

 

P.S. - I don't think your L30 situation would work anymore, because if I remember right, Squawkbox will drop your voice connection if the controller with the matching primary frequency goes offline. So the pilots would have to re-tune to the consolidated frequency anyway, in order to stay in communication with the remaining controller. I raised this issue with Joel a while back, but I don't recall if he changed the behavior or not ... I would have to test it.

 

P.P.S. - Actually, we'd likely need pilot client software updates as well ... I don't think the pilot clients would be able to handle more than one frequency per callsign. It depends on how they were written.

[Harold Rutila 974112]

Then there are the complaints about how to resolve getting two transmissions at once. With consolidated positions and active frequencies still working, that enables two pilots to call the controller at the same time. It happens at my home airport when they consolidate the entire tower, which is quite a workload, and a lot of times, pilot transmissions have to be repeated. N6030E could call the controller for clearance to the practice area while at the same time, Citrus 219 could be calling up on a 10-mile final. Not that I'm against being able to transmit on multiple frequencies as they do in the real world, but I think there's one small disadvantage, especially during events if positions are consolidated.

[James McMannamy]

It's an issue in the real world -- some controllers work 5 or more frequencies at one time and get 3 or more calls at once. It's part of the cost of consolidating positions, and it's an extremely real issue that is part of how the game is played.

[Dan Everette]

I say we throw imagination into the wind and cater to the ultra-realistic crowd. I want to fly VFR out of PVD along the coast. Damnit I better be able to tune my radio on 126.65 and talk to clearance delivery (I don't care WHO I'm talking to, but they better be on 126.65 so I can launch out of PVD). Same with Ground, Tower and the two approach sectors.

 

So, I go to log on as PVD_APP, I need to monitor 5 frequencies. It's doable on this network with limited traffic and a couple gin & tonics.

 

But wait, I'd like to open up BOS_CTR during the day, and perhaps provide more ATC services to more pilots (because if you don't, people will whine that there is never enough ATC open). Hmmmm, I have 8 Cl[Mod - Happy Thoughts] C's and a Cl[Mod - Happy Thoughts] B. So, now we're looking at a minimum of 40 frequencies. Oh, wait, forgot the Cl[Mod - Happy Thoughts] D's, and the various center sector frequencies (by golly, the high/low enroute chart says Boston Center is on this frequency, there better be a controller on it if BOS_CTR is online).

 

End result, we go to a dozens of pilots stepping on each other on one frequency (which you have some control over) to pilots stepping on each other over dozens of frequencies.

 

I bring this to an extreme to make a point, specifically to point out how absurdly ridiculous this has become. "Realism" means different things to different people. If you want 100% realistic, go spend $20k and get your PPL and instrument rating, or become a real world controller. VATSIM will never have enough controllers to staff all positions all the time. So, a line has to be drawn somewhere, and that line is based on both available resources and controller experience/proficiency.

 

Is it a pain that some facilities provide full Cl[Mod - Happy Thoughts] C/D services and some don't? If you're a 100% realism junkie, yup it is. How about a controller who starts out providing C/D services, then changes those to uncontrolled when traffic situations warrant it? I've seen it over the years, people send feedback to the facility (or whine about it in the forums) that they had to wait 10 minutes for a release from a field whose tower was closed at the time, and those that complain that the tower was closed and shouldn't be issued taxi instructions.

 

My question is: Is it that much of a detriment to your flying/controlling experience to bend/break some real world rules, recognizing that VATSIM is not, and is unable to be, a completely realistic simulation for various reasons? Is it that much of a heartache if things vary from facilitiy to facility on this network (due to various reasons)? Are you really losing sleep at night over this?

 

I just find it quite comical that there are people in this forum that are currently arguing "Things need to be hyper-realistic, and it has to be done this way, because that's how it's done in the real world" in one thread, and in another thread the comments are along the line of "Relax, things need to calm down, this is a game and people are not going to die if you don't do things right all the time".

 

So who's up for opening CTR and it's [Mod - Happy Thoughts]ociated 100+ frequencies in the name of being "realistic"?

[Ernesto Alvarez 818262]

its already bad enough it happens on 1 frequency. pilots stepping on each other on 2 or more frequencies at the same time is nuts id immediately go text only on the other channels

 

 

i like the idea tho. would definitely take the guess work out of who should you call. but at the end of the day, youll just be simulating what we already have, only with a bunch of frequencies instead of just 1

[Wade Williams 877539]

I don't think the pilot clients would be able to handle more than one frequency per callsign. It depends on how they were written.

 

I can tell you in the case of XSqawkBox, that's true.

 

My thinking would be - integrate this functionality into the next major revamp of the voice library perhaps along with a codec change, etc - whenever that might be. (And believe me, I'm not asking for this anytime soon - I have plenty on my plate) Whether it's used or not would then become a VATSIM decision.

[Anthony Atkielski 985811]

its already bad enough it happens on 1 frequency. pilots stepping on each other on 2 or more frequencies at the same time is nuts …

 

Actually, there is no practical difference between the two. People stepping on each other on frequency comes from understaffing and network delays, and has nothing to do with the number of frequencies used.