[Flightgear-devel] MP Chat broken

[d***@mi7.us]

Looks like MP chat and transponder codes are broken in fgms-0.13.2 &
2017.2.1. Tested clients on Windows and Mac OSX, servers are 0.13.2.
Transponders set to a code show up remotely as 0000 until reset to
proper code.

-- Dr. R0ckso, Ph.D.

[Michael]

Post by d***@mi7.us
Looks like MP chat and transponder codes are broken in fgms-0.13.2 &
2017.2.1. Tested clients on Windows and Mac OSX, servers are 0.13.2.
Transponders set to a code show up remotely as 0000 until reset to
proper code.

The MP protocol has changed. What are the tested clients' versions?

I have recently been testing this on those servers and it worked as (newly)
expected. If you connect a new (>=2017.2) client without selecting the
compat option, and read from an old client, such behaviour is normal.

[w***@gmail.com]

Post by d***@mi7.us
Looks like MP chat and transponder codes are broken in fgms-0.13.2 &
2017.2.1. Tested clients on Windows and Mac OSX, servers are 0.13.2.
Transponders set to a code show up remotely as 0000 until reset to
proper code.
The MP protocol has changed. What are the tested clients' versions?
I have recently been testing this on those servers and it worked as (newly)
expected. If you connect a new (>=2017.2) client without selecting the compat
option, and read from an old client, such behaviour is normal.

can the compat option be switched on and off at any time or must one disconnect
and reconnect to the server to switch?

[Richard Harrison]

Post by w***@gmail.com
can the compat option be switched on and off at any time or must one disconnect
and reconnect to the server to switch?

No need to disconnect, it takes immediate effect; as do all of the new
2017.2 sim/multiplay parameters

[w***@gmail.com]

Post by w***@gmail.com
can the compat option be switched on and off at any time or must one disconnect
and reconnect to the server to switch?

No need to disconnect, it takes immediate effect; as do all of the new 2017.2
sim/multiplay parameters

thanks, i wasn't sure as i cannot see my own info in the MP Player list and the
mpmap servers don't show the transponder, for example... i'm guessing an ATC
setup would be needed to see more... i've had some luck with ATC-PIE but only in
an offline type mode practising ATC stuff with the simulated flights... maybe i
can set up something at diego garcia that i can see...

currently i'm in the ufo set "visible to all" at diego garcia with the
transponder turned off... i've been using mpserver51 since it was published...
its operator is the one that started this thread, IIRC...

[Richard Harrison]

The computability setting only affects property transfer to pre 2071.2
(or other non upgraded clients). 2017.2 will work with either setting,
as hopefully will the other clients once upgraded.

So, for example, in 2016.4 you will be able to see the 2017.2 aircraft
in the list, and around you, but often with missing/incorrect animations
(e.g. gear down in air).

If you're trying to have multiple FG (or clients) on the same machine
you need to ensure that each one is using 5000 as outgoing and a
different incoming port.

[d***@mi7.us]

Post by d***@mi7.us
Looks like MP chat and transponder codes are broken in fgms-0.13.2 &
2017.2.1. Tested clients on Windows and Mac OSX, servers are 0.13.2.
Transponders set to a code show up remotely as 0000 until reset to
proper code.
The MP protocol has changed. What are the tested clients' versions?
I have recently been testing this on those servers and it worked as
(newly) expected. If you connect a new (>=2017.2) client without
selecting the compat option, and read from an old client, such
behaviour is normal.

I have to adjust my statements.

Two clients are Win7-32, one client is Mac OSX. All three are 2017.2.1.
The server versions all match to 0.13.2; 0.12.a1 has been retired for
the moment.

One thing I noticed is that the rxport had to be changed on the two
clients sharing a host so the firewall/NAT/router can keep them
separated, and it works better to put each client on a different server
(since they are coming from the same IP address).

Another complication crept in with the communications radius. With one
client set to 400 nm, the other client -- still set for 100 nm --
appeared with transponder code 0000 (despite the default being 1200, or
overridden with other settings at start). Changing the transponder code
corrected the transponder from 0000 to what I set it to. Changing the
code again updated the transponder code seen by the remote client set to
400 nm (invisible to the first client set to 100 nm).

It seems like this should be something that can be set by the user and
retained over sessions until we actually have the code in the model
computing radio path availability.

The protocol could make use of compression; I've captured a few packets
and noticed a lot of null bytes.

-- Dr. R0ckso, Ph.D.

[d***@mi7.us]

So on further investigation of transponder misbehavior during long
flights, this message appeared in the Nasal console:

Nasal runtime error: non-numeric string in numeric context: 'a**0123a**'
at __dlg:radios, line 14.

0123 is the transponder code. Actual character printed at "a" was ASCII
131.

-- Dr. R0ckso, Ph.D.