And chance of voice CTAF on vPilot?

[Sean Harrison]

I can fully understand if VATSIM staff don't want to support it anymore; not sure how much effort goes into currently supporting it...

 

The guys that developed FSinn literally haven't responded to emails about their client, written a post on a forum, or connected to Vatsim for over 5 years. The support forum is run by a guy who had literally nothing to do with coding it and learned the ins and outs of using FSinn the same way most of us did. By experimenting and learning by trial and effort. (And I'm [Mod - Happy Thoughts]uming it was a lot of effort!)

 

Totally agreed there, Ernesto has lead FSInn support from what I have seen, and I have benefited from that support. The whole community is supported by people like you Trent and probably hundreds across VATSIM. Granted their support varies from negligible to many hours each week.

 

What I really meant was (again my terminology and English betray me) that if Ernesto didn't answer another post on the forums about FSInn, would FSInn not still be an effective tool to numerous members who use the network. My belief is that like many developers, VATSIM should merely make a statement when time comes "VATSIM does not offer support for FSInn". That would of course be the case if no-one else offered to rely to posts within FSInn subforum.

 

So in summary; and hopefully clearly; banning connections utilising FSInn would be counterproductive to many members IMHO. Declining to offer support would be a matter for individual members, because I reckon the helpers would still try and help others.

[David Zhong]

It would not be counter-productive in the sense if we were to make changes to the network protocol that FSInn could not support, allowing people to continue to use FSInn could result in undesirable behaviour.

[Ross Carlson]

If somebody wants to throw a standard together, I'm all ears.

 

That's precisely what we've been doing for the past 3 pages in this thread, starting with my post here:

 

viewtopic.php?f=8&t=70437&start=45#p496181

 

There I described a standard and asked for feedback. I'll be writing it up in summary proposal form and sending it to the BoG.

[Ernesto Alvarez 818262]

there are sooooo many people in the community with much more technical expertise then I have, programmers, etc.. the day i stop giving folks support for any of our clients or specifically FSINN, ive no doubt other users would step in.

 

FSINN does indeed work, under the current architecture. with all the things that people want, better voice capabilities etc... its only a matter of time before the network updates something on the servers which breaks some functionality in Squawkbox and FSINN. at that point there is nothing anyone can do to bring those back. the fear of this happening is one of the biggest reasons the network hasnt gone ahead with any of those plans, we have no backup right now if that happens and would essentially kill the network by doing so. once the alternative comes around though, they will be less hesitant

 

it may not be an immediate "ban", definitely would not be a good idea to just dump everyone off on a new client without the new client having a couple of months of running on its own on the network. only way to work the kinks out of it. beta testers will only get you so much info. you tend to get a heck of a lot more info when the public starts using it. not to mention the initial planned release is for FSX with support for FS9 coming after, then XP. so may be a year or two after Swift before FSINN sees the end, that would be my prediction, [Mod - Happy Thoughts]uming in that time the network starts work on those server updates

 

 

 

I can fully understand if VATSIM staff don't want to support it anymore; not sure how much effort goes into currently supporting it...

 

The guys that developed FSinn literally haven't responded to emails about their client, written a post on a forum, or connected to Vatsim for over 5 years. The support forum is run by a guy who had literally nothing to do with coding it and learned the ins and outs of using FSinn the same way most of us did. By experimenting and learning by trial and effort. (And I'm [Mod - Happy Thoughts]uming it was a lot of effort!)

 

Totally agreed there, Ernesto has lead FSInn support from what I have seen, and I have benefited from that support. The whole community is supported by people like you Trent and probably hundreds across VATSIM. Granted their support varies from negligible to many hours each week.

 

What I really meant was (again my terminology and English betray me) that if Ernesto didn't answer another post on the forums about FSInn, would FSInn not still be an effective tool to numerous members who use the network. My belief is that like many developers, VATSIM should merely make a statement when time comes "VATSIM does not offer support for FSInn". That would of course be the case if no-one else offered to rely to posts within FSInn subforum.

 

So in summary; and hopefully clearly; banning connections utilising FSInn would be counterproductive to many members IMHO. Declining to offer support would be a matter for individual members, because I reckon the helpers would still try and help others.

[Jackson Harding]

 

The issue of RL 24/7 airports that are unstaffed on VATSIM...

Our policy here has been that any major airport that normally has a 24/7 tower requires that the pilot remain on the UNICOM frequency.

 

My thinking on this is that if the airport is staffed 24/7 real world, then an overlying approach or center controller would be providing tower services there anyway. If there is no overlying approach or center controller, then the regular tower frequency for that airport would become the CTAF frequency. That's how it works at many (all?) airports in the US that close during the night.

 

Ross, that's pretty much what VATPAC do already. For the (handful) of towers that are open 24 hours a day (Sydney, Melbourne, Perth, Adelaide, Brisbane, Cairns, Darwin, Townsville) then UNICOM 122.8 is used when there is no coverage. For the rest (most, but not all of which are in Cl[Mod - Happy Thoughts] D airspace, Canberra and Gold Coast are the big two exceptions) they become CTAFs on the TWR freq out of hours.

 

Jackson

[Ross Carlson]

Ross, that's pretty much what VATPAC do already. For the (handful) of towers that are open 24 hours a day (Sydney, Melbourne, Perth, Adelaide, Brisbane, Cairns, Darwin, Townsville) then UNICOM 122.8 is used when there is no coverage. For the rest (most, but not all of which are in Cl[Mod - Happy Thoughts] D airspace, Canberra and Gold Coast are the big two exceptions) they become CTAFs on the TWR freq out of hours.

 

Why not use the tower frequency for the ones that are 24/7 real world, when they're unstaffed on VATSIM?

[Christopher Collins]

If somebody wants to throw a standard together, I'm all ears.

 

That's precisely what we've been doing for the past 3 pages in this thread, starting with my post here:

 

viewtopic.php?f=8&t=70437&start=45#p496181

 

There I described a standard and asked for feedback. I'll be writing it up in summary proposal form and sending it to the BoG.

 

Not to challenge your goodwill here, but I only see a scope of works being put forward "for discussion" - maybe I'm missing something.

 

As I see it, we'll still need somebody to write the final docomeent that says how it'll work otherwise we'll just be inventing 3 or 4 different wheels.

[Greg Barber]

Why not use the tower frequency for the ones that are 24/7 real world, when they're unstaffed on VATSIM?

 

I think the main reason we don't do it that way is that there literally is no CTAF frequency published on the chart for those airports, for all others there is. The other benefit is that the vast majority of pilots are in the habit of tuning to UNICOM 122.8 when no ATC is available. Using this frequency at those airports captures the vast majority of our traffic at our busiest airports on the same frequency. If VATSIM goes down the path of using 120.5 as the CTAF at YSSY for example, there would be a period of adjustment where some pilots would be on advisory 120.5 and others on advisory 122.8 simply because some are unaware of the new regs.

 

A separate CTAF works well at smaller airports where the traffic is light enough that if someone doesn't follow the rules it often doesn't affect anyone else. At a big international airport however, pilots not using the correct advisory frequency has the potential to affect the enjoyment of many more network users.

[Ross Carlson]

Not to challenge your goodwill here, but I only see a scope of works being put forward "for discussion" - maybe I'm missing something.

 

Do you have an alternative suggestion on where to start?

 

As I see it, we'll still need somebody to write the final docomeent that says how it'll work otherwise we'll just be inventing 3 or 4 different wheels.

 

I think it goes without saying that the end result of this effort, if accepted by the VATSIM staff, would be some sort of final docomeent.

[Christopher Collins]

Not to challenge your goodwill here, but I only see a scope of works being put forward "for discussion" - maybe I'm missing something.

 

Do you have an alternative suggestion on where to start?

 

Given the absence of a VP of Technical Development, I'd be starting with a mostly complete specification as to how the mechanism should work, and more importantly, the full benefits/impact upon the network enumerated in real world terms (ie: what does it actually mean for VATSIM as a whole to adopt it in realistic terms if the specification as provided is implemented), specifically focusing on any necessary network or server changes, policy changes, additional overheads, anticipated impact on client developers, anticipated impact on server load, anticipated impact on end users...

 

I suspect a proposal with no firm indication or consideration of how it will affect things will result in a lot of talk and no action or will be ignored for whatever narrative currently holds the status quo in place. Whilst we may have people to champion the concept, as there is nobody to champion a specific technical implementation, we should move to provide of much of this in advance rather than hoping it'll mysteriously emerge from the BoG afterwards.

[Ross Carlson]

Given the absence of a VP of Technical Development, I'd be starting with a mostly complete specification as to how the mechanism should work, and more importantly, the full benefits/impact upon the network enumerated in real world terms

 

I asked for an alternative suggestion on where to start. Your answer describes the end game.

 

Perhaps you misunderstand the intentions of this thread. We are hashing out the details of how a voice CTAF system could work. Only then can any sort of proposal be submitted for VATSIM staff consideration. It would be foolish of me to draw up a proposal in isolation without any input from stakeholders.

 

The summary proposal I intend to write will indeed list the impacts on and benefits for the network. Without that it would be a stretch to call it a proposal ... it would just a be "wish list" item.

 

The summary proposal will also describe how it'll work from a technical perspective, using language similar to what I put in the bullet list a few pages back. Given that the technical details of this feature will be quite simple, that description won't be far from a technical specification anyway.

 

as there is nobody to champion a specific technical implementation, we should move to provide of much of this in advance rather than hoping it'll mysteriously emerge from the BoG afterwards.

 

(Since you are a developer, I [Mod - Happy Thoughts]ume you don't really mean "implementation" here, rather "specification".) I agree that it would be wrong to expect the BoG to come out with a finished spec. We wouldn't want them to anyway. The client developers need to do that.

 

Or did you actually mean "implementation" and you're suggesting we should have a working prototype before approaching the BoG?

[Richard Quigley]

Personal note: Voice CTAF would be the greatest thing since sliced bread. Experienced it in AU; missing it in NA.

 

"It's 2016. A pair of earbuds costs $2. We're flying around on hundred-dollar computers and simulators that cost up to $200. People who aren't willing to purchase a headset or at least earphones are, in my view, missing out on the most beneficial part of flying on VATSIM: realistic ATC interaction. "

 

Thank you Evan Reiter!

[Russell Diehl]

Great initiative. As VATPAC VFR Coordinator I fully endorse the proposal. Many of the participating pilots find using Voice CTAF the only viable way of operating in and out of crowded CTAF aerodromes. Text is highly undesirable when hand flying small aircraft not equipped with autoflight. In fact, it is quite detrimental to safe operations. A pilot has to be very aware the chat interface has input focus before attempting to enter text as the consequence of inadvertently raising/lowering landing gear on final approach by pressing the "G" (or other mapped key) can be catastrophic. As it is, I have to remind pilots to map "SLEW" mode to a modifier key combination (ie CTRL-Y) to ensure this is not accidentally invoked in flight by press "Y" when the simulator is in focus.

 

Each entry in the mapping file would represent an airport with the following fields: airport ID, frequency, voice URL, range

 

Just looking at existing FSINN text voice files, it would appear the Airport Long and Lat will be required as additional fields not included in the proposal so the client can recognise the centre from where to calculate Range.

 

Rusty Diehl

VATPAC VFR Event Coordinator

[Ross Carlson]

Each entry in the mapping file would represent an airport with the following fields: airport ID, frequency, voice URL, range

 

Just looking at existing FSINN text voice files, it would appear the Airport Long and Lat will be required as additional fields not included in the proposal so the client can recognise the centre from where to calculate Range.

 

Yes, I accidentally left out the lat/lon ... that would certainly be necessary.

[Russell Diehl]

Why not use the tower frequency for the ones that are 24/7 real world, when they're unstaffed on VATSIM?

 

Strangely, this is catered for with VATPAC voice files. If you are located at one of the airports with ATC 24/7 in the real world within Australia, then the voice file will remap the local tower frequency (ie 120.50) to the general AU-Unicom voice room. The voice file behaviour for the major and CTAF towers can provide some interesting amusement at times. A pilot can be conversing with TWR and not realise that tower may have gone offline in the interim and find themselves requesting a service from a non existent controller. Can take a while and some repeated requests for a pilot to realise that the request will never elicit a response since it was actually made within either the local CTAF or AU-Unicom voice room.

[Adam Trzcinski]

"It's 2016. A pair of earbuds costs $2. We're flying around on hundred-dollar computers and simulators that cost up to $200. People who aren't willing to purchase a headset or at least earphones are, in my view, missing out on the most beneficial part of flying on VATSIM: realistic ATC interaction. "

 

Our deaf and mute members will be relieved to hear that it will only cost them $2 to be able to use voice ATC on VATSIM! A miracle, I tell you!

[David Zhong]

If we are going to cater for everyone, then we will never get anywhere. I would wager that there are more FS2004 members than deaf/mute members that are also going to be disadvantaged by this proposal since SB3 and FSInn will not be updated for this.

 

Text has been and will continue to be the fallback when voice cannot be used for whatever reason. But where we can improve the experience for a overwhelming majority of members without excluding the remainder, then we should take that path.

[Gavin Dibley 1044852]

I fully agree with supporting the deaf, but there are a lot of situations in flying where you aren't capable of using text. I know when I'm flying (especially without a co-pilot), there is a lot of situations where I have to omit critical communication because I don't have my hands free to text on Unicom.

 

On FSInn, I would quite commonly use voice on CTAF and text in Unicom (if workload permits), that way it's less likely im going to ploy into the runway or building while trying to handle comms.

[Ernesto Alvarez 818262]

that is usually because some users have not learned to pre-type their coms. if im in the pattern, i type everything ahead of time. not to mention you dont need a full essay like some seem to want to do. you can get the same message across using short hand

[Evan Reiter]

"It's 2016. A pair of earbuds costs $2. We're flying around on hundred-dollar computers and simulators that cost up to $200. People who aren't willing to purchase a headset or at least earphones are, in my view, missing out on the most beneficial part of flying on VATSIM: realistic ATC interaction. "

 

Our deaf and mute members will be relieved to hear that it will only cost them $2 to be able to use voice ATC on VATSIM! A miracle, I tell you!

Adam,

 

I'll excuse you for taking a part of my statement out of context and making an [Mod - Happy Thoughts]umption about my feelings toward different members of VATSIM. For those who may not have seen the rest of my original post, the line that was quoted above was based on the proposal that those with a legitimate disability are afforded the opportunity to use text only. I was in no way suggesting that VATSIM exclude any group of members from any part of this community, nor would I do so.

 

Given the titles listed in your signature, I would have hoped for better.

 

In an earlier discussion on this subject, someone mentioned to me that the percentage of the population with dyslexia is substantially larger than those who are hearing or speech impaired. I don't have a specific statistic to back that up but I'm sure it's readily available.

[Ernesto Alvarez 818262]

you did kinda contradict yourself Evan, when you go down the road of users having to legitimize a possible disability, you do exclude users. frankly if im not required to legitimize my disability at my job, i should not have to on here either. nor should users be subjected to "sorry you dont have a qualifying disability to "justify" your use of text"

 

again, wrong road to be going down.

 

other then that the conversation has been moving forward, lets keep it moving forward, not backwards

[Joel Richters]

Ill just jump in here and say I'm 100% for the voice CTAF. I used it when I had FSInn and the Voice Files, and since then have missed it lots. I think the default communication method should be voice, and for those who can't use voice they announce there intentions on text. If someone sends a text CTAF message it would be polite to reply with text to let them know someone else is around.

 

So long and short, my opinion is... Default communication should be voice, if not available use text, and if someone using voice needs to communicate to a text only person, they need to use text. This makes sense since CTAF or unmanned towers should only be using the communication as an advisory frequency anyway. If you want to chat, I believe that's what teamspeak etc are for.

 

Happy debating!

[Evan Reiter]

you did kinda contradict yourself Evan, when you go down the road of users having to legitimize a possible disability, you do exclude users. frankly if im not required to legitimize my disability at my job, i should not have to on here either. nor should users be subjected to "sorry you dont have a qualifying disability to "justify" your use of text"

 

again, wrong road to be going down.

 

other then that the conversation has been moving forward, lets keep it moving forward, not backwards

The point, Ernesto, isn't whether my original comment is right or wrong. The point is that the poster took that comment out of context and, in my opinion, dramatically changed my original meaning. Out of respect for those who may not have read my entire original post, I wanted to clarify.

 

I thought we had addressed this issue in the immediate replies to my post so I'm not really sure why it was brought up again. I have no desire to re-open this part of the discussion. I think we're focusing on the Voice CTAF at this point; I think that's what we should be focused on and I'm wholly in favor.

 

I'm not looking to backtrack, but if someone decides to take a part of my post and use that to suggest that I'm in some way against specific groups of people, I'm going to at the very least clarify that I said more than the one-liner he quoted.

[Ross Carlson]

All, I have submitted the voice CTAF proposal to the BoG. Thanks go to Evan Reiter for organizing our ideas into the proposal docomeent. I'll keep this thread updated as my discussions with the BoG progress.

 

Thanks for all the input!

[David Zhong]

Nice one Ross, looking forward to hearing the BoG's response!