EDDF-Triangle

[tdammers]

Someone who is more intricately familiar with the MP protocol should probably jump in and elaborate though.

Partial UDP packets can't happen however packets that don't contain the full property set are possibly, and if the aircraft is transmitting variable length strings long strings can cause a packet that is nearly full to become full and cause properties at the end to not be transmitted. There are warning messages given on the console of the transmitting aircraft that indicate this. I've not checked the packet size on the B777 - that can be viewed when flying by looking in /sim/multiplay/last-xmit-packet-len - ideally this should be no more than 900 (bytes) to allow for text chat strings.

The non tilting landing gear on the 777 doesn't seem to me from what I've read to fit the profile of a transmission problem - it is more likely a model/animation problem than an MP protocol problem.

Hmm, I'm looking at the 777 as we speak. The RH gear tilt animation is based on sim/multiplay/generic/float[2] in Models/777-200.xml, and 777-set-common.xml maps that to /gear/gear[2]/compression-m. So that looks alright to me.

I'm also looking at two 777's (running on two of my computers) as we speak, going through mpserver01. This is what I see:



The Air France one in the foreground is running locally on the machine where the screenshot was taken, the BA one in the background runs on the other machine, callsign NL255. As you can see, the gear looks fine on both, no tilting.

**HOWEVER**

These are both the model taken directly from https://gitlab.com/fg777_seattle/fg777_seattle.git. There are other 777's making rounds, including the one in the default hangar, which I believe is an older version of this model. The model ID they send may very well be the same, but it's possible that those don't send that particular property yet. If that is the case, then the proper solution would be to use the gitlab version, or, even better, merge that into the default hangar. It's either that, or a protocol issue after all (but then again, it works fine between these two machines...)

(On a side note, parking 777's at EDLN is hilariously ridiculous... just imagine trying to taxi past one another on those taxiways...)


**EDIT:**

I just checked the 777 from fgaddon; it has the same MP property assignments, as you can see here: https://sourceforge.net/p/flightgear/fgaddon/721/tree/trunk/Aircraft/777/777-set-common.xml#l515, and the animation here: https://sourceforge.net/p/flightgear/fgaddon/721/tree/trunk/Aircraft/777/Models/777-200.xml#l1872. So that's not it.

[jomo]

[...] I guess everybody flying with FGFS has a Handy[...]

Thx for your general mumble support.
Sorry that I do not understand your lecture about "handy" etc in your post. I still believe that just about all our FGFS-customers do know that the most used APPs (including "mumble") are available for all PC's, NB's, Tablets, Handies, etc etc pp. You may also check http://www.emmerich-j.de/Mumble/mumble.html. There is also described how you assign any key for the Mic on/off .. I use the lowest left key on kyb.. (e.g. no need for changes inside FGFS!)

I also do not understand why mumble should be newly designed for FGFS. There are lots of MUMBLE_serves all over the world (we even use one from a FGFS-member --> my thx to WTF411 for the perfect support/service within hours after faults occurred)

Two more points to the urgency of using mumble:
1) Just try to type a 50 Chr-msg while watching the screen with 10 moving objects and incoming voice info's etc. etc. pp. --> I guess that should be convincing that you might not be able to notice every incoming MPmsg for quite some time!

2) See the following EDDF-ATC-20190105.png and notice:

a) The prime infos are on the Radar - the shown situation with 5 moving/close targets requires the major attention of the ATC!
b) Then the ATC keeps an eye on the FP-section at the right for changing FPs that would indicating new situations! Their updates will always take a lot of typing-time!
c) After seeing above picture: Did you notice that in the left lower corner there appeared "..XA -- ready to taxi"?
-- I believe there is no FGFS-pilot that never overlooked those MPmsgs from time to time! And that MPmsg will disappear very fast unnoticed if ATC is forced to type in stress!
-- You can be sure that no ATC in stress will search for "maybe missed msgs" -- i.e. the pilot must repeat and repeat and repeat -- as long as the ATC is busy!
---> with mumbles
- the ATC could not "overSEE" that MPmsg
- the pilot will notices that the ATC is busy (i.e. that there is more traffic than the MPchat-user noticed)

I hope we can convince more pilots to use Mumble: Typing is terrible also for pilots on short final etc ....
And there is no new design or other efforts needed for using mumble -- just use it!

[jomo]

These are both the model taken directly from https://gitlab.com/fg777_seattle/fg777_seattle.git. There are other 777's making rounds, including the one in the default hangar, which I believe is an older version of this model.

Exactly this is the major problem for all Multiplayer Events!! And it is a growing problem! There are hundreds of libraries with unique versions for the same models. With the new FGFS the designers try to reduce that by using the "fgfs launcher" - thus restricting the model choices (at least for the less knowledgeable users -- I am not sure that will help).

For EDDF I tell already every user since a long that I do only support/download models from
-- http://home.flightgear.org/download/
-- https://github.com/FGMEMBERS

Does anybody has a better proposal how we can ensure that all participants in events are using compatible models?

[legoboyvdlp]

tdammers,

the most up to date 777 is this:
http://mirrors.ibiblio.org/flightgear/ftp/Aircraft-trunk/777.zip

This includes all from that repository, as well as some updates / bugfixes. That repository you linked is no longer maintained, as the seattle team is inactive.
also available through the launcher download.

FGMEMBER's repository is also outdated and does not have the latest changes.

[wkitty42]

I also do not understand why mumble should be newly designed for FGFS.

i don't think anyone has suggested that... what i read was a suggestion to build a mumble client into FG... why? so that new users (and old ones) don't have to fumble about installing yet more software to be able to fly and have fun interactions with other pilots in this simulated environment... folks don't like fgcom which is built-in and available separately... then like mumble so it kinda makes sense to maybe build a mumble client into FG, too... the question is if it can be done without breaking GPL...

[wkitty42]

For EDDF I tell already every user since a long that I do only support/download models from
-- http://home.flightgear.org/download/
[...]

ummm... that flightgear link takes you to the same place that the builtin launcher gets the craft from... it is also easy to add other 3rd party hangers to the launcher... the only requirement is the hanger generate the necessary file for the launcher to process so it can display the craft in a 3rd party hanger as well as being able to download the craft packages from the hanger and install them... i see no limitations for the users, there...

[tdammers]

These are both the model taken directly from https://gitlab.com/fg777_seattle/fg777_seattle.git. There are other 777's making rounds, including the one in the default hangar, which I believe is an older version of this model.

Exactly this is the major problem for all Multiplayer Events!! And it is a growing problem! There are hundreds of libraries with unique versions for the same models. With the new FGFS the designers try to reduce that by using the "fgfs launcher" - thus restricting the model choices (at least for the less knowledgeable users -- I am not sure that will help).

For EDDF I tell already every user since a long that I do only support/download models from
-- http://home.flightgear.org/download/
-- https://github.com/FGMEMBERS

Does anybody has a better proposal how we can ensure that all participants in events are using compatible models?

It's free software; trying to restrict model choices is absolutely hopeless.

What you have just discovered is one of the hardest problems in programming: API compatibility. That is, building things that depend on another in some way (in this case, aircraft models on multiple computers) such that 1) they are compatible, but 2) they can evolve independently. The second one is absolutely crucial; you could of course try to prevent independent evolution, but in an open source ecosystem, this is neither realistic nor desirable.

Unfortunately, the software industry as a whole still struggles with this problem, so there isn't a good solution, really. I've tried to think of one that would at least reduce the pain, but none of them seem realistic. For example:

- We could have a system to assign unique identifiers to all aircraft models and versions. Problems here: it would require adding a fairly large prop to the already-overloaded MP packet; we would need a system to ensure uniqueness of identifiers (i.e. a global registry of aircraft authors, models and versions); we would need a convenient way of installing missing models as you encounter them (at the very least, adding download locations to the aforementioned registry). We'd also have to extend FG to make querying that registry and installing aircraft through it more convenient. All in all, I don't see that happening - who is going to run and maintain that registry, who is going to convince developers of putting their aircraft in there? And, more pressingly, can we even get buy-in from core contributors? I don't think so.
- We could redesign the MP protocol to be more fault-tolerant: instead of sending a flat list of raw values, we could send list of name-tagged values. But this would blow up the packet size, so we would have to completely change the way the MP protocol works to make this possible in an efficient manner, i.e., a breaking protocol change, and a massive amount of work that I don't see anyone volunteer for. Worse yet, it would probably also break all the MP servers out there.
- We could extend FG to support multiple versions of the same aircraft to be installed, add a hash of the relevant model files (or parts of model files - it's probably enough to even just hash the list of MP props) to the MP protocol, try to pick an exact match from the locally installed models, and visually alert the user when none was found, which would then 1) explain any visual inconsistencies, and 2) prompt players to exchange information as to where to get that aircraft model (as we have been doing occasionally). So you could just have the six most popular 777 versions installed alongside each other, and FG would pick the most appropriate one for each MP player you encounter.

[tdammers]

tdammers,

the most up to date 777 is this:
http://mirrors.ibiblio.org/flightgear/ftp/Aircraft-trunk/777.zip

This includes all from that repository, as well as some updates / bugfixes. That repository you linked is no longer maintained, as the seattle team is inactive.
also available through the launcher download.

FGMEMBER's repository is also outdated and does not have the latest changes.

Is there a git repo anywhere? I try to avoid the launcher like the plague, it has atrocious UX, breaks often, and is just all around inconvenient (to me, that is).

`git pull` is really the most convenient way of managing aircraft updates for me, it gives me full control and has the added benefits that I can manage any local changes I may want to make without any additional effort.

[jomo]

Alright, so the film in question is this one: http://www.emmerich-j.de/EDDF/Films/201 ... 57-157.mp4

Lucky me: So my previous picture and comments match, see

Now to your (helpful??) remarks to that film:

I'm flying under my usual callsign of NL256 (I thought the forum tagging gave that away). The first time I appear on screen is around 1:55, though I'm still about 110 miles out at that point. The flight strip pops up around 1:58, at 92 miles out. I'm trying to establish contact at 2:06, the screen shows my chat message at 22:40:31 local time. You can see me make further attempts, e.g. at 2:08; the last one is around 2:26. At 2:12, I fly right through the frame, near the PSA NDB.

I am not sure what times You are referencing in the above - pls see in the following the real UTC-Times given at the start of all MPmsg-lines:

22:40:31 "NL256 NL256 inbound EDDF, no mumble today (sorry)"
----- At that given time there are 3 active targets on approach + 1 taking off + 5 to be watched according to FP-listing (changing position when the status changes). Any those 5 targets approaching/starting forced me to concentrate onto the airport area - so the NL256 is neither seen on radar nor as being "controlled" in the FP-listing -- and definitely 100 mi out, i.e. it was not a high priority-target at that time!
----- and why should ATC care about the full statement that someone types to himself??? Today I am not sure if I noticed that msg at all or read it completely because it did not show me as target address and I was busy!!!
22:43:39 "NL256 ATCjomo, do you read me?"
----- still no target on radar - and still very busy - I am not sure if I noticed that msg
22:54:41 "NL256 does ANYONE read me?"
----- why should I notice/respond when that target is already past AP?? Anyone may answer - I am busy!
22:54:41 "?"
23:00:23 "ping"
I really see no reason at all why i should care about that nonsens

But, my complaint isn't about EDDF sessions not being like VATSIM; any level of realism is fine by me, really, as long as the terms are clear. I understand that the purpose, approach, and situation are different; I understand that there are technical and organizational limitations such as incompatible charts and procedures; I understand that you deviate from realism on a few points, such as not using squawks, etc.; that's fine. I just wanted to know why I got no responses.

I hope the list above gives you an idea why you got no response! And you should understand that from my point of view you actually made only 1 acceptable try to contact ATC within 110 mi of approach"
I hope that example above is not what you want as realism!

[legoboyvdlp]

Is there a git repo anywhere? I try to avoid the launcher like the plague, it has atrocious UX, breaks often, and is just all around inconvenient (to me, that is).

`git pull` is really the most convenient way of managing aircraft updates for me, it gives me full control and has the added benefits that I can manage any local changes I may want to make without any additional effort.

Hi,
If you use svn, you can checkout fgaddon. That link I sent to Aircraft-trunk is exactly the same as fgaddon -
this might work:

Code: Select all

git svn clone https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/777

[tdammers]

Now to your (helpful??) remarks to that film

You asked for information, I gave it. Passive-aggressively questioning the helpfulness of doing so is a bit rude, don't you think?

I am not sure what times You are referencing in the above

Times into the video. How else are you going to quickly navigate to the right position? UTC times are fine and all, but the video player doesn't know about those, so if you want to tell someone where exactly in a given video to look, this format is how everyone does it.

22:40:31 "NL256 NL256 inbound EDDF, no mumble today (sorry)"
----- At that given time there are 3 active targets on approach + 1 taking off + 5 to be watched according to FP-listing (changing position when the status changes). Any those 5 targets approaching/starting forced me to concentrate onto the airport area - so the NL256 is neither seen on radar nor as being "controlled" in the FP-listing -- and definitely 100 mi out, i.e. it was not a high priority-target at that time!
----- and why should ATC care about the full statement that someone types to himself??? Today I am not sure if I noticed that msg at all or read it completely because it did not show me as target address and I was busy!!!

Alright, note to self, name-tag messages and follow proper phraseology when initiating contact.

Note, however, that by the time I made that transmission, I was already within 50 miles of the airport (not 100), and the video shows that NL256 shows up in the strips section under "uncontrolled". I also remember from watching lots of your videos that you usually zoom out and / or check mpmap often, so under normal circumstances, I would have expected to have caught your attention already.

22:43:39 "NL256 ATCjomo, do you read me?"
----- still no target on radar - and still very busy - I am not sure if I noticed that msg

I can't see your screen; I was well within contact range at this point, but I was suspecting a technical problem (MP chat not being transmitted). The video doesn't show me on the radar screen, but that's simply because it's zoomed too much. No way for me to know that.

22:54:41 "NL256 does ANYONE read me?"
----- why should I notice/respond when that target is already past AP?? Anyone may answer - I am busy!
22:54:41 "?"
23:00:23 "ping"

At this point I'm dropping the last bit of realism and just try to figure out whether this is a technical problem, and if so, whether the problem is on your end or mine. Nobody answers, so I conclude that, despite reconnecting multiple times, via multiple servers, my messages don't even make it to the MP server. Which is just bad luck, I figure, so I write the evening off and log off. After all, this has happened before, no big deal.

But upon watching the video, I saw that there was no technical problem at all, so I thought it might be enlightening to discuss the matter.

I really see no reason at all why i should care about that nonsens

Here we go again with the passive aggression. Maybe it's just your relative lack of English language proficiency, but suggesting that someone's honest attempt at discussing a failed communication and learning from it is "nonsens" (sic) is pretty rude IMO.

I hope the list above gives you an idea why you got no response! And you should understand that from my point of view you actually made only 1 acceptable try to contact ATC within 110 mi of approach"
I hope that example above is not what you want as realism!

As I've said before, the choice of realism level is completely up to you, I'm not making any demands on that front, I just want to know what the expectations are.

So, recap (correct me if I'm wrong):

- I should have made contact a bit earlier, right at the edge of the radar contact area rather than 10 miles in.
- Upon initial contact, I should have followed proper phraseology (station, callsign, current clearances and intentions).
- I should expect mumble users to be prioritized over MP chat.
- Would a filed flight plan have helped you notice me? If so, I'll be happy to provide one next time.

Does that sound like a decent summary?

And then, on a final note: I noticed that your control of the English language is nowhere near native; that's fine, but it seems that it sometimes word you things in a way that are quite rude or offensive when you don't mean to be. Please do take this as constructive criticism, I'm not trying to blame you here. When you write things like "{callsign}, WHO ALLOWED YOU TO PUSH BACK?????????????", it comes across like a German officer screaming into your face, when really you probably didn't mean to, and "{callsign}, you have not been cleared for pushback, STOP!" would have gotten the point across in a more professional and less offensive way. It's subtle, but it makes a huge difference, and as a native German speaker, I can understand where this is coming from, and that it's not always meant as offensive as it comes across. Other examples include calling people "idiots" (the word is quite a bit harder in English than in colloquial German), referring to constructive remarks as "nonsense", etc.

So maybe you could try and work on that a little? Or am I totally out of line here with this last bit?

[tdammers]

Is there a git repo anywhere? I try to avoid the launcher like the plague, it has atrocious UX, breaks often, and is just all around inconvenient (to me, that is).

`git pull` is really the most convenient way of managing aircraft updates for me, it gives me full control and has the added benefits that I can manage any local changes I may want to make without any additional effort.

Hi,
If you use svn, you can checkout fgaddon. That link I sent to Aircraft-trunk is exactly the same as fgaddon -
this might work:

Code: Select all

git svn clone https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/777

Alright, yeah, that works for me. SVN makes me sad, and it's a bit inconvenient that the histories don't match up even though they are shared up to the head of the Seattle repo, but I think I can manage.

This seems to be the thing that fixes the landing gear btw:

Code: Select all

* 396f02b 2017-12-09 | 777: bug fix: animate the gear of the remote 777 with its own properties, not those of the local aircraft

And it also explains why everything looked fine on both my 777's while parked, but once I got one of them in the air, the gear tilt was messed up.

I also never realized that putting a slash at the start of a property or not makes a difference, so that's a good thing to remember. It's obvious in hindsight if you think about it (the MP model's properties being mounted somewhere deep down into the property tree, so reading out an absolute path gets you the local aircraft's values, not those of the remote one), but still somewhat unexpected.

[AAL545]

I feel responsible (in a bad way) for all this discussion regarding the 777 landing gear,
having said that I also feel it's to the benefit to improve the system (code) because obviously
a code was changed and correct me if I'm wrong but no one knows exactly what was changed!
If someone could take a look and compare the two between now and early to mid 2017 when everything was
working fine but I don't know if that's even possible.
But lets not do anything drastic and make matters worse.


AAL4955

[legoboyvdlp]

What version of the 777 are you using AAL?
Sorry if this has been answered before, but if you are using an outdated version, which does not have that commit mentioned by tdammers then that would be the reason why it is broken for you.

[Lydiot]

am I totally out of line here with this last bit?

"You must be new here."

Jomo is never wrong.