Jump to content

Reimplementing AFV for Linux


Pedro Rodrigues 1377186
 Share

Recommended Posts

Sounds like he's looking for a way to do ATC on Linux, and there's no way to do that natively. Some of the radar clients in my experience run okay-ish under Wine, with some issues. There are other threads here suggesting it's not easy getting the AFV standalone client to work with Wine.

 

The audio itself might not be so bad if you use the Xsquawkbox implementation but I'm guessing some of the authentication with VATSIM would need permission from the VATSIM to implement. I'd just as well wait until the clients have native AFV support which has been hinted for sometime this year.

Link to comment
Share on other sites

Ah, right, yes. Might still be worth it to get in touch with the Swift team - much of their work is open source, so it might be possible to just extract the AFV parts and reuse those. Maybe even turn them into a library. I have no idea what the source code looks like though, so it may or may not be worth it.

23.png
Link to comment
Share on other sites

There is working AFV support in Swift, which also works on Linux. Maybe look into that rather than reinventing the wheel?

 

Thank you. Yes, it is a very valid implementation. It is in C++ which I'm not very familiar with.

 

 

 

I'm sorry to pick you, but you started it. Since the invention of the wheel, we have engineered all kinds of wheels. Cart wheels, artillery wheels, flywheels, wire wheels, train wheels, just to name a few. Perhaps most notably, gears.

 

There are many kinds of wheels, none of which is a replacement for the other. Inventing and engineering are not synonymous. None of the engineers that design the various types of wheels we have today, have invented the wheel or have tried to do so, yet their contraptions are useful in their own domain and not necessarily applicable in another.

 

Whoever invented the wheel in the first place, I'm sure would be very impressed with gears.

 

That is analogous to someone say about C++, 'why reinventing C?'

Edited by Guest
  • Like 1
Link to comment
Share on other sites

Sounds like he's looking for a way to do ATC on Linux, and there's no way to do that natively. Some of the radar clients in my experience run okay-ish under Wine, with some issues. There are other threads here suggesting it's not easy getting the AFV standalone client to work with Wine.

 

The audio itself might not be so bad if you use the Xsquawkbox implementation but I'm guessing some of the authentication with VATSIM would need permission from the VATSIM to implement. I'd just as well wait until the clients have native AFV support which has been hinted for sometime this year.

 

That is correct. Before AFV I could control on Linux. Since AFV I cannot get a solid setup. Mostly due to AFV current implementation.

Link to comment
Share on other sites

Ah, right, yes. Might still be worth it to get in touch with the Swift team - much of their work is open source, so it might be possible to just extract the AFV parts and reuse those. Maybe even turn them into a library. I have no idea what the source code looks like though, so it may or may not be worth it.

 

Their source code is available in https://dev.swift-project.org/source/pilotclient/

Link to comment
Share on other sites

VATSIM doesn't force you to make closed source software. I'm pretty sure client devs are free to open source their code at their liking (except for one very-precise part, for security purposes). Swift is an example of this.

 

I don't know if you've been on the VATSIM Dev Team before, but I know I haven't seen you around it since I've been part of it, which leads me to think you're talking about an NDA which you haven't ever seen by yourself. In the past years VATSIM has been changing significantly, and that includes moving slowly towards a more open-sourced mindset.

 

I am not here to force you into the team, nor am I responsible for it (I'm just a random developer that's part of it), but I really can't emphasise this enough: Join us, try it and then, decide

Me.

Link to comment
Share on other sites

VATSIM doesn't force you to make closed source software. I'm pretty sure client devs are free to open source their code at their liking (except for one very-precise part, for security purposes). Swift is an example of this.

 

I don't know if you've been on the VATSIM Dev Team before, but I know I haven't seen you around it since I've been part of it, which leads me to think you're talking about an NDA which you haven't ever seen by yourself. In the past years VATSIM has been changing significantly, and that includes moving slowly towards a more open-sourced mindset.

 

I am not here to force you into the team, nor am I responsible for it (I'm just a random developer that's part of it), but I really can't emphasise this enough: Join us, try it and then, decide

 

I don't think I can adequately show my appreciation to the effort I see you put in. Thanks.

 

You are correct, I haven't seen the NDA or have I been a member of the dev team.

 

Nor do I want to read it or be a member of said team. With all due respect for their efforts. I appreciate the invite, and this is a discussion I had with a board member before, but I just want to send some patches.

Link to comment
Share on other sites

I'm sorry to pick you, but you started it. Since the invention of the wheel, we have engineered all kinds of wheels. Cart wheels, artillery wheels, flywheels, wire wheels, train wheels, just to name a few. Perhaps most notably, gears.

 

There are many kinds of wheels, none of which is a replacement for the other. Inventing and engineering are not synonymous. None of the engineers that design the various types of wheels we have today, have invented the wheel or have tried to do so, yet their contraptions are useful in their own domain and not necessarily applicable in another.

 

Whoever invented the wheel in the first place, I'm sure would be very impressed with gears.

 

That is analogous to someone say about C++, 'why reinventing C?'

 

Easy there. All I meant to say was "someone has already done it, it works, it's open source, so why don't you look there before deciding to do all the work yourself?"

 

There may be valid reasons for making your own from-scratch implementation, but you haven't stated any, and when talk about "reimplementing the wheel", I really mean that it's a good idea to either use what's already there, or be confident about your reasons not to.

23.png
Link to comment
Share on other sites

I'm sorry to pick you, but you started it. Since the invention of the wheel, we have engineered all kinds of wheels. Cart wheels, artillery wheels, flywheels, wire wheels, train wheels, just to name a few. Perhaps most notably, gears.

 

There are many kinds of wheels, none of which is a replacement for the other. Inventing and engineering are not synonymous. None of the engineers that design the various types of wheels we have today, have invented the wheel or have tried to do so, yet their contraptions are useful in their own domain and not necessarily applicable in another.

 

Whoever invented the wheel in the first place, I'm sure would be very impressed with gears.

 

That is analogous to someone say about C++, 'why reinventing C?'

 

Easy there. All I meant to say was "someone has already done it, it works, it's open source, so why don't you look there before deciding to do all the work yourself?"

 

There may be valid reasons for making your own from-scratch implementation, but you haven't stated any, and when talk about "reimplementing the wheel", I really mean that it's a good idea to either use what's already there, or be confident about your reasons not to.

 

 

Thanks, I'm very glad you took it with right amount of salt.

 

Yes. what ever is done already, providing the licenses are permissible enough to allow modification and redistribution, they are very good candidates. At the moment I'm more in search for how accepted such a project might be by the community. And being fully honest, there isn't much interest I can see from here.

Link to comment
Share on other sites

Yes. what ever is done already, providing the licenses are permissible enough to allow modification and redistribution, they are very good candidates. At the moment I'm more in search for how accepted such a project might be by the community. And being fully honest, there isn't much interest I can see from here.

 

I'm not sure what you expected to be honest - VATSIM ATC is very windows-centric. We don't even have a native macOS client, and that's a much larger slice of the pie.

 

I have a bit of a "build it and they will come" type attitude to this stuff. We have little to no precedent for non-Windows ATC users, but we don't make it easy for them by lacking the native software. If we build it, maybe there'll develop enough of a population who cares. Maybe we won't. We really won't know until we try.

 

As for using the existing AFV-client implementations, if you've dealt with OO languages before, learning C++ isn't too bad, but you can avoid having to deal with too much yourself by using swig or another ABI/FFI compatibility tool to wrap the C++ API into a C one. You can potentially also write your own wrapper (read up on the the C++ extern "C" construct which will let you define functions that will not have the C++ symbol mangling applied to them). I can't comment on the automated tools like swig, I don't use them.

 

Having done the hard yards to write an AFV client, I really don't recommend trying to deal with the AFV internals in C. Most of the rest of a native voice-only client shouldn't be too bad except... for having to talk to the ATC client. I'm not sure how the AFV client currently does it (if it does at all), but if it needs Windows IPC, it's probably going to be quite hard to sort out.

XSquawkBox - Developer/Maintainer

 

Please post any support related questions to the XSquawkBox support forum rather than private messaging me, thanks.

Link to comment
Share on other sites

You can always join the VATSIM Dev Team by sending an email to vpdev(at)vatsim.net and offer yourself to build a native Linux client

 

 

Vatsim messed this transition up horribly, you have nothing to be proud of.

 

James, your post seems really out of place in this thread. Did you post in the wrong thread by mistake?

Developer: vPilot, VRC, vSTARS, vERAM, VAT-Spy

Senior Controller, Boston Virtual ARTCC

Link to comment
Share on other sites

Vatsim messed this transition up horribly, you have nothing to be proud of.

 

Double the number of connections at nearly any time of day before AFV was released... yeah a real messed up transition.

 

Maybe you might want to accept you’re in a far too vocal minority, but the majority of sane members of the network are enjoying things....

 

Once you have removed ones head out of ones bottom maybe come back and have a sensible discussion.

 

Cheers

G

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...