Easy property addition to allow CTR control (make 100 NM limit variable)

Thanks for the feature request, but I do not think this would start with a FGMS change.

If I understand correctly you wish to add a new property to what FGFS (or an ATC instance) sends in the packets to a FGMS instance, so I think the first step would be to open this for discussion on the FGFS develoment list, to get the property added to the packet structure. Many of us do not follow the forum regularly...

Only then could a FGMS server decode that additional packet property, and use that distance instead of the configured FGMS value, default 100 nm.

Now this would have to be an addition to the position message header. FGMS does not get into decoding other properties, FGPropertyData, added to the packets. See https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/MultiPlayer/mpmessages.hxx#l84 and down...

And that FGFS development discussion would include a general concensus that the scope of ATC be expanded to such an en-route control centre...

Alternatively, such an en-route control centre, if generally agreed it is desireable, could get aircraft position using say a crossfeed instance, connected to a FGMS instance.

This map - http://geoffair.org/fg/map-test2/map-test.html - is powered by such a crossfeed, connected to mpserver14, and the json update is available from - http://crossfeed.freeflightsim.org/flights.json - updated just each second. And is also available as XML - http://crossfeed.freeflightsim.org/flights.xml...

So, as indicated, I do not think this can be added to FGMS yet, so have marked this pending a change in the packet structure... But maybe I do not understand something...

PS: In general we have moved these requests to the gitlab repo - https://gitlab.com/fgms/fgms-0-x/issues ... thanks...

Probably some follow up to expect here:
https://sourceforge.net/p/flightgear/codetickets/1843

Thanks!

Thanks for posting the SF FG Ticket 1843. We shall see what responses that brings from the FG community... You might also post something on the dev list, since again not everybody gets/reads the code tickets...

You have accurately stated that such a new value would have to be in the position packet header, since FGMS does not decode attached FG properties, which can vary greatly...

It would be appreciated if you could post all your replies here so all can read them, rather than directly to me...

To try to answer your questions on the json (or xml) crossfeed service...

Yes, it is ALL pilots on-line world wide - ie no distance restriction - from FGMS instances that are connected to the mpserver01 HUB. Now, not every FGMS server does that, so some flights can be missing, but most do... But also those that do not can not be seen by other mp aircraft nor ATC, unless they are connected to that same FGMS instance...

Crossfeed is a reliable service in that it has been running now, non-stop, for years... IIRC since about Apr 2013...

The json (and xml) responses to the http GET request are only updated internally each second, perhaps plus a little - only when the time() is sampled and changes, which thus can be a fraction of a second later - so yes it can be queried each second, plus a little! No attempt is made to accurately spaces these updates. But faster requests would be meaningless... Change can be determined by the "last_update" UTC time stamp.

And note there is some minor filtering of the callsign. Only alphanumberic, plus '-' and '_' chars are allowed. This mean spaces and other characters are discarded. And packets where the resulting filtered callsign are null are discarded. The "dist_nm" is an estimated accumulation of the distance travelled between packets, in meters, using sim-time, and converted to a integer sum of nm. Read not exactly accurate! All other values come directly from the mp packet.

As to whether crossfeed can be queried by many clients, the answer in general is yes, depending on what you exactly mean by many. The server that hosts the current service does have some IO limits, but these are quite generous... so if by many you mean say 2 to 10, no problems... thousands, definitely NO!

As stated this current crossfeed is connected to mpserver14, but other FGMS servers could also set up crossfeed instances - it is GPL open source, like FGMS/FG - thus spreading the load if it got heavy...

Yes, this sort of became two topics - FGMS and crossfeed - but I have no problem with that ;=))

And it seems, at this stage at least, you have no interest in the alternative solution suggested, namely using the crossfeed service, which has no distance limits, but presents other problems in your eyes. That is fine...

Concerning the forum topic FGMS packet field addition, it seems the poster, Hooray, got the two topics very confused, taking pains to pointing out that FGMS does indeed have a configurable m_PlayerIsOutOfReach, which definitely controls whether FGMS will forward the packet to LOCAL FGFS clients! Hope you at least undestood that I never intended to imply otherwise.

Considering all, I will leave it stand as is, and will refrain from commenting on the possibility of using a "custom chat message" to do something regarding this distance...

As you say, let's see where this goes...