Closed dneuge closed 2 years ago
New fields are now available via Client#getAssignedTransponderCodeDecimal()
and FSDServer#isSweatbox()
.
client_connections_allowed
is a weird one. The previous field clients_connection_allowed
(note the swapped plural) was "always" there (same as on legacy format) and never observed with any different value than 1
, so I already assumed that it's probably a boolean encoded as an integer (and offlined servers simply are never exposed through the data files). According to my code comments, JSON v3 API documentation (still offline...) stated that the old field is int32
. parseClientConnectionAllowedInteger
translated 0
to false
and all other values to true
(as would be the case when comparing an integer on low-level languages or machine code) but logged a warning (via SLF4J, not parser log) in case we encounter some other value. With the new field I added an additional check which reports any mismatch between the two fields to the parser log but ultimately trusts the boolean (because the boolean indication isClientConnectionAllowed
is what our FSDServer
class was always supposed to transport, not an integer). Let's see if we ever hit that message; I suspect the old field is simply cargo cult from migrating the legacy formats to JSON and might be deleted in a future JSON format version.
Nothing needed to be done to support servers_sweatbox
and servers_all
on NetworkInformation
. Any key on data
will be transported. Whoever needs that data can already access it using getDataUrls
or getAllUrlsByDataKey
.
New additions noticed in January 2022:
assigned_transponder
(string), default0000
?client_connections_allowed
(bool)is_sweatbox
(bool)data
:servers_sweatbox
servers_all
Check if support for
data.servers
has been added at some point to this parser.These changes were not publically announced (again). API documentation seems to be offline (would be located at https://api.vatsim.dev/#operation/DataServerV3)