AndyTWF/afv-euroscope-bridge

Getting data out from AFV to 3rd party or to ES

Opened this issue · 10 comments

bostjanlaba commented

HI @AndyTWF ,

I'm trying to understand how AFV data is communicated to Euroscope or if there's even any option to pull data from AFV to some 3rdparty desktop app from AFV.

I've been looking at RDF plugin, your afv bridge and I cannot get last callsign on freq (in AFV) to show in Euroscope. I've tried using OnVoice.... methods in Euroscope, nothing.

Would you please tell me how this this communication works? What data is AFV being able to send and receive? I'm guessing since RDF can draw circles around planes in Euroscope, it must be getting LastOnFreq from AFV somehow...

Using ES 3.2.3, afv bridge 1.2.3 and AFV 1.10.1

Thank you kindly.

Bostjan

AndyTWF commented

Hi @bostjanlaba!

EuroScope itself has no direct integration with AFV - all of the OnVoice methods are from the days of the old voice codec, so don't (to my knowledge) work with AFV.

For this plugin specifically, AFV sends us a simple message: the frequency that the user has selected, and whether thats in receive or xmit mode. We translate that into listening on Euroscope text channels to tie up text chat with the frequencies selected in AFV.

The communication with the bridge plugin (and I believe the same is true for RDF) is done behind the scenes via a "hidden window". In short, the bridge plugin opens an invisible program window that is able to receive messages on the Win32 message queue. When things happen in AFV, the AFV client sends a message to the window where it expects to find the bridge plugin (it doesn't check that the plugin is actually loaded, to my knowledge). The bridge plugin then decodes the message, and acts on it.

This is all pretty much baked into the AFV standalone client as a bespoke solution - I collaborated with the developer of the client at the time to get this all working (and it's been a few years since!). I'm not aware of any pull-based systems from retrieving data from the AFV client, it's all push-based unfortunately. So any potential future supported clients would need to engage with the AFV team about getting integrated.

Probably not the answer you were hoping for, but hopefully this helps clarify how things work :)

Andy

bostjanlaba commented

Thank you, Andy, for this detailed information and a prompt reply.

I wasn't expecting this to be so "bad". Seems like whole vatsim infrastructure and clients are a bit due for a serious overhaul but I'm not sure I'm allow to say that out loud :)

Cheers

Bostjan

goliver1984 commented
bostjanlaba commented

Oliver,

I'm sorry that you feel this way. It wasn't my intention to offend or say it's useless.

Window messaging, as many other techniques of course is valid, especially as it works, but there could probably be other solutions aswell, with structured data, other protocols etc.
If things need to be decoded, extracted, scraped etc. they are not optimal. Unless 3rdparty development is unwanted.

My view of things being "bad" goes to more things, fsd protocol, development guides, getting support etc.

But I see some developers trying really hard to make things better, who help a lot to other developers and community and I really appreaciate them.

Cheers

Bostjan

I would say it’s bad… windows messaging is a perfectly valid way to interface! I was gonna say I was happy to provide you with the information on what we send to Andy but now you’re on your own. Cheers G
…
On Wed, 6 Dec 2023 at 09:23, Bostjan Laba @.> wrote: Thank you, Andy, for this detailed information and a prompt reply. I wasn't expecting this to be so "bad". Seems like whole vatsim infrastructure and clients are a bit due for a serious overhaul but I'm not sure I'm allow to say that out loud :) Cheers Bostjan — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5Q66W36MOTAEH2X2LHSC3YIA2QFAVCNFSM6AAAAABAJAE4XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBSGQ4TMMJQGY . You are receiving this because you are subscribed to this thread.Message ID: @.>

goliver1984 commented
bostjanlaba commented

Thank you. Got it, now it works. I will try to contact Dev team and see if there is any will to perhaps add some other comms into afv aswell.

Thanks again.

Bostjan

bostjanlaba commented

Ah, just one question. Now message appears after then transmission has ended. Any way to get the message at the start of transmission? Or is that a limitation of AFV?

And since we're at it, if external win app would create a new window, would it also receive messages along with ES? Is window messaging a broadcast kind of messaging or unidirectional?

goliver1984 commented
bostjanlaba commented

So it's Gary, not Oliver ;)

What do you mean by "many endpoints available"?

bostjanlaba commented

Gary, does the window name AND windows class have to be as specified for this to work?
Setting both works in the plugin I made for ES, but I'm also trying to catch this outside ES by only setting a window name but either I'm doing something wrong or the class name is a must too.

Thanks

Bostjan

Bostjan, No worries I get what you’re saying now :) I sent a string to a hidden window class for the RDF plugin which at the time maintained backwards compatibility with them I think.. If you create a window you will receive a string.. The window has to present as int hWnd = getWindowId("RDFHiddenWindowClass", "RDFHiddenWindow"); result = sendWindowsStringMessage(hWnd, 0, callsignsString); you will then receive a string separated by colons as follows windowMessaging.SendReceivingCallsigns(string.Join(":", e.ReceivingCallsigns)); if there are no receivingcallsigns at the time you will get a blank string as such windowMessaging.SendReceivingCallsigns(""); The AFVBridge only receives frequencies that are set but if you need that I can document. Cheers G
…
On Wed, 6 Dec 2023 at 09:40, Bostjan Laba @.> wrote: Oliver, I'm sorry that you feel this way. It wasn't my intention to offend or say it's useless. Window messaging, as many other techniques of course is valid, especially as it works, but there could probably be other solutions aswell, with structured data, other protocols etc. If things need to be decoded, extracted, scraped etc. they are not optimal. Unless 3rdparty development is unwanted. My view of things being "bad" goes to more things, fsd protocol, development guides, getting support etc. But I see some developers trying really hard to make things better, who help a lot to other developers and community and I really appreaciate them. Cheers Bostjan I would say it’s bad… windows messaging is a perfectly valid way to interface! I was gonna say I was happy to provide you with the information on what we send to Andy but now you’re on your own. Cheers G … <#m_9038272816679060974_m_-4390643419721378283_> On Wed, 6 Dec 2023 at 09:23, Bostjan Laba @.> wrote: Thank you, Andy, for this detailed information and a prompt reply. I wasn't expecting this to be so "bad". Seems like whole vatsim infrastructure and clients are a bit due for a serious overhaul but I'm not sure I'm allow to say that out loud :) Cheers Bostjan — Reply to this email directly, view it on GitHub <#4 (comment) <#4 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5Q66W36MOTAEH2X2LHSC3YIA2QFAVCNFSM6AAAAABAJAE4XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBSGQ4TMMJQGY https://github.com/notifications/unsubscribe-auth/AC5Q66W36MOTAEH2X2LHSC3YIA2QFAVCNFSM6AAAAABAJAE4XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBSGQ4TMMJQGY . You are receiving this because you are subscribed to this thread.Message ID: @.> — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC5Q66RER73USV3LSFSOVGDYIA4PVAVCNFSM6AAAAABAJAE4XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBSGUZDGNZQGE . You are receiving this because you commented.Message ID: @.**>