EDDF-Triangle

[jomo]

Since a whole month now we have to endure a real, absolute Baby-Idiot that tops all we have encountered the last 15 years. If you want to "hear" what we mean call up:

http://www.emmerich-j.de/EDDF/Films/201 ... 955-67.mp4 ( another nice sequence starting at FilmMinute 20)

You will hear terrible noises - then we block his incoming Net-IP - then he comes back with another Net-IP - we block ... again and again ... over hours! See in the following a few IP's he used:

<W>2018-04-07 15:09:04.056 1 => Ignoring connection: 154.119.50.246:57468 (Server ban)
<W>2018-04-07 14:52:12.503 1 => Ignoring connection: 188.125.175.10:33496 (Server ban)
<W>2018-04-07 14:50:22.605 1 => Ignoring connection: 5.9.78.25:39290 (Server ban)
<W>2018-04-07 14:48:45.486 1 => Ignoring connection: 80.211.4.187:39534 (Server ban)
<W>2018-04-07 14:47:44.681 1 => Ignoring connection: 75.114.77.34:8856 (Server ban)
<W>2018-04-07 14:43:05.959 1 => Ignoring connection: 89.236.17.106:52546 (Server ban)
<W>2018-04-07 14:38:03.502 1 => Ignoring connection: 188.125.175.27:45672 (Server ban)

(BTW: With the IP plus TimeStamp we can find the Provider - that provider then might decide if he really wants such customers - and even the police may be interested to get to know those CyperCriminals!)
Similar things he tries on OpenRadar.

Right now we hope that someone knows this Baby-Idiot and is able to get some common-sense into his Baby-Brain -- otherwise we may have to stop the "free Login" possibilities and use authorized LogIns (as well for "mumble" as also for "OpenRadar" -- that really would be a pity!).

Pls help us to convince that guy to stop - prior to others having to implement technical restrictions.

[Clive2670]

This person must be hiding behind a VPN I would have said As the 154 Adress is in Stellenbosch South Africa. The 188 address is in Turkey, The 5 Address is closer to home in Germany (Hetzner Online GmbH) The 80 address is in Italy, The 75 address is in the USA. The 89 address is Sweden. Lastly the other 188 address is blocked for query but it must be Turkey? Surly jomo if this person is using VPNs you personally cannot track Him / Her and the service provider can only put "blocks" on the VPN (s) that are being used. Also surely the more people get involved to try and "convince" this person the more he/she will do it more?

[AAL545]

That is so sad regarding this idiot, in the good old days he'd get bent over the knee. (Maybe that's what's wrong today)

Anyway regarding the landing gear issue, what I have noticed today in the film (April 22-2018) is my 777-300ER and another 777 was the Japan Airlines instead of American Airlines.
Not sure if this has anything to do with upgrading to FG 2018 or not.


AAL 4955

[tdammers]

So I've been wrecking my head over the missing nose cone on the DHC-6; after continuing my flight from EDDF, I met a fellow DHC-6 pilot, and we could both see each other's nose cones, but jomo's setup clearly didn't show it.

Now, there is this peculiar thing about the DHC-6. The real aircraft comes in two versions, one with a blunt nose (as originally designed in the -100 series), and an optional stretched nose for additional baggage (available in the -300 series). The FlightGear model contains both flavors, and there is a property (

Code: Select all

/sim/model/blunt-nose

) that selects the nose (true meaning blunt, false meaning stretched). This property is set through the selected livery, and transmitted over MP - however, if the latter goes wrong, then it seems that the nose may not appear at all. And here's why: the

Code: Select all

Models/DHC6.xml

file has two sections for selecting the nose cone submodel from the .ac file:

Code: Select all

<animation>
    <type>select</type>
    <object-name>bluntnose</object-name>
    <condition>
        <equals>
            <property>sim/multiplay/generic/int[0]</property>
            <value>1</value>
        </equals>
    </condition>
</animation>

<animation>
    <type>select</type>
    <object-name>longnose</object-name>
    <condition>
        <equals>
            <property>sim/multiplay/generic/int[0]</property>
            <value>0</value>
        </equals>
    </condition>
</animation>


The crucial part here is that if the property isn't received at all, then its value will be neither 0 nor 1, and the conditions in both animation sections will both evaluate to false.

The quick solution is to change the conditions so that one of them becomes the default, e.g.:

Code: Select all

<animation>
    <type>select</type>
    <object-name>bluntnose</object-name>
    <condition>
        <not>
            <equals>
                <property>sim/multiplay/generic/int[0]</property>
                <value>0</value>
            </equals>
        </not>
    </condition>
</animation>

<animation>
    <type>select</type>
    <object-name>longnose</object-name>
    <condition>
            <equals>
                <property>sim/multiplay/generic/int[0]</property>
                <value>0</value>
            </equals>
    </condition>
</animation>


...essentially making the blunt nose the default.

That would be a good thing to do anyway, but it's not the true cause of the problem - the conundrum is why the property didn't get transmitted in the first place. It's been in the DHC6 for years, unchanged, so it's unlikely that a model version mismatch would cause this. I suspect that the cause lies somewhere in the MP protocol itself; have there been any recent changes that may cause this property to be transmitted incorrectly between FG versions? FWIW, I'm using a fairly recent version checked out from git and compiled from source, don't know what jomo uses, but I believe it's a tad bit older.

[AAL545]

Oops, ignore

[AAL545]

So I've been wrecking my head over the missing nose cone on the DHC-6;

Fair enough but what about the B-777 missing landing gear?
I mean the gear was there and functioned 100% about 2 or 3 months ago then it started acting up and today it's totally gone.



AAL 4955

[tdammers]

I don't know, but I wouldn't be surprised if the cause were the same. Typically, when landing gear does or does not show up, it's either because the models on either side don't use the same property for the gear state, or that property doesn't get transmitted correctly. So if there's an incompatibility between the FG versions on both sides, then that might be the cause. And who knows, maybe the server also plays a role. I don't know much about the protocol though, so I can't really say anything for sure here.

[AAL545]

The only thing I can think of besides different version aircraft (which I have ruled out) is I know Jomo has done a reinstall / updrade of his OS
and so have I, I have switched from Ubuntu to Linux Mint 18 but I can't see that being an issue. (Need to run will think of this in the mean time)



AAL4955

[jomo]

Sorry AAL545
why can we not stay on that forum where you etc. started and were I gave you a detailed explanation??
Please stay there for your problem - otherwise we all will be confused completely!

I am not able to now comment on both FORUMS with similar - but not exactly the same problem.
Please answer on the original forum
http://www.thejabberwocky.net/viewtopic ... 253#p24172
and refer to my hints given there, based on your and PavlinS problem-descriptions. There you may even see that YOU did change as well the OperatingSysten as also the Model as well as also the FGFS version -- and here you say the complete opposite!

Sorry - but that now becomes too confusing for a simple guy like me!

[tdammers]

Jomo; I just read the thread you linked on thejabberwocky, and I think that the way you think things work is almost, but not quite, correct.

You are right about how models are loaded from whatever is installed on either side: if the MP protocol says I'm flying a "777-200ER", then your FG instance will look at the Aircraft directories on your computer and try to find a model named "777-200ER". So far, so good.

The next important thing here is the "property tree": this is a tree-shaped data structure that reflects the entire state of an aircraft in the simulation - position, speed, type, systems, failures, control surfaces, engine state, everything. The property tree can be inspected (and even modified) inside FG under "Debug > Browse Internal Properties", and also somewhere in the Phi web interface.

Among other things, the property tree is used to position and animate the aircraft model - for example, there may be a property "/surface-positions/elevator", containing a deflection angle in degrees, and the aircraft model might then be rigged to rotate the submodel (aircraft part) called "elevator" by that amount. All this is defined in the aircraft definition, typical somewhere in a file called Models/{aircraft-name}.xml. This system is extremely flexible; it doesn't only rotate submodels, but it can also show/hide aircraft parts, change texts, change texture positions, turn lights on and off, illuminate things, etc. etc.

Landing gear is pretty much always done this way: the current gear position (as calculated by the FDM) is stored somewhere in the property tree (IIRC it's something like "/gear/gear[n]/position" or sth like that), and the model animation picks up that property and changes the position and rotation of the landing gear and landing gear covers.

The DHC-6 nose (blunt or stretched) is done the same way, except that the property is not set by the FDM, but based on the selected livery. If you load up the DHC-6, and change the "/sim/model/blunt-nose" property in the property browser, you will see that the model's nose changes shape on the fly.

Now, the problem with multiplayer is that in order to show an aircraft properly, you need the correct values for all the properties that influence animations; and those properties need to be sent over the network, otherwise you won't know the correct values for someone else's aircraft. Problem is, you can't just send the entire property tree, because that would require way too much network bandwidth. A full property tree can have hundreds, if not thousands, of individual values, and sending them all would require sending several megabytes per frame (!) over the network - with, say, 20 other aircraft in sight, and 30 FPS, that's an entire CD-ROM worth of data to be exchanged every second. That is simply not going to work. But since the system is so flexible, it is impossible to tell in an automated fashion which properties are relevant - there is a handful of them that you always need, like position and velocity, and those are standardized, but everything else is up to the aircraft author. Each aircraft defines a list of additional properties to send over the network, mapping spots in the property tree to spots in the multiplayer protocol message. E.g., you could define that your aircraft puts "current gear extension status" for the 3 sets of gears in properties 5 through 7. As long as those mappings match on both sides, everything works out great: the controlling pilot's FG instance sends the selected properties, and the observer's FG instance reads them, reconstructs the property tree from them, and animates the model.

Trouble starts when this goes wrong: when a needed property doesn't end up in the right spot, the animation won't run, or it will run incorrectly. For example, if the gear extension status property isn't there, then the landing gear will be displayed in the default position, which is typically "retracted"; and if the DHC-6's blunt-nose property isn't there, then no nose will be shown at all (I checked this, it is actually what the aircraft definition says).

But there are several reasons why and how things can go wrong:

- Incompatible aircraft. If the aircraft definitions on both sides use different properties for, say, gear extension status, then the animation will look at the wrong property, not find it, and thus fail to display the landing gear. Or if the property does get sent, but in a different slot of the MP protocol message, then the other end will not read it back out into the right property, and the same thing will happen.
- Buggy aircraft. If the aircraft simply doesn't send the property at all, then there is no way to get it back out. Likewise, if the aircraft definition on the receiving side doesn't define an MP mapping for the property, then it won't be received either.
- Transmission problems. I don't know the specifics here, but AFAIK, it is possible for MP protocol messages to get truncated. This could, in theory at least, lead to some properties at the end of the message not being transmitted. I don't know if this can actually happen though, and if so, under what circumstances.
- Incompatible FG versions. And this, I think is a hot lead (I will explain in a second why I think that). If the FG versions on both sides are different, and the receiving end doesn't fully understand what the sender is sending, then it may not be able to get all the properties that have been transmitted. And we get the same problem again: property missing, aircraft model animations defaulting or doing weird things.

So why do I suspect the FG version? Well, several clues:

1. The way the DHC-6 nose works hasn't been changed in years; I went back in history to 2015, long before the past few FGDATA releases. There have been no changes to how the nose works since, and since I've flown the exact same DHC-6 before without issue (several movies confirm this), a sudden change in the aircraft itself cannot be causing this.
2. The nose showed up fine within the same MP session later, on someone else's computer (I met FlyAndi shortly after departing from EDDF and asked to confirm that my nose was present).
3. I am running a fairly new FG version (2018.2) that I built from source, and IIRC there has been some work on the MP protocol since.

So in order to troubleshoot this, it would be very helpful if we could compare FG versions; then I could dig into the history and see if I can find anything that hints at a change in FG itself that could cause this. Either way, I am pretty convinced that it's *not* an incompatibility between the installed aircraft models.

[AAL545]

Sorry Jomo if I posted in the wrong forum, but since we are here.
Not sure about "and here you say the complete opposite!"
If I would have known that this is going to be an issue (not only for me) I would have taken notes.
Let me explain, a while ago (2 to 3 months, can't remember) I was on Ubuntu 16 and everything was fine including the landing gear showing and leveling out at touchdown and vice versa,
short story, my OS crashed and I switched to Linux Mint 18. Now at some point, again I don't recall which happened first, the OS switch or B777 switch, what I mean by B777 switch is I switched
to the B777-300ER from Github (more advanced) , I noticed the landing gear issue then I switched back to the default aircraft via FG, guess what, no difference!
This might be hard to follow but I can't see it being an OS problem because what I see is FG pilots are using Linux, Windows and MAC.
Again, I have tried clean downloads via FG, from Github and in the add on section pointing to that folder where the aircraft is located. (Same way you do if you have custom scenery)
I have done some modifying on my aircraft, for example, using a custom jet engine and fine tuning the response in my yoke settings but that has never been an issue.
"Transmission problems." could it be a bandwidth issue?


AAL 4955

[AAL545]

Posted by Jomo on December 29th 2017. " In my local directories are now over 300 models - in addition there are more and more development groups working on different models under the same model-name --> causing additional "display-problems"!."

I think this is the problem since I have tried a clean install of my aircraft.
Not to blame Jomo here but how can we have a good filming experience if we download aircraft from different sources, eg; FG or github.



AAL 4955

[jomo]

Not to blame Jomo here but how can we have a good filming experience if we download aircraft from different sources, eg; FG or github.

I answered exactly that (and see also tdammers very detailed explanation a little further down)! And pls try to help by testing (pls facts - not suggestions):

1) There is no way that the whole world with thousands of FGFS-users will always and for ever use the same model for all time. So we have to find which models do have a problem and which do not - only that way we can pinpoint what can to be done by whom!
2) The problem could be the model or the FGFS-version or the Multiplayer or the OS programs etc etc.
3) Pls also remember that I already pointed out that obviously also some of the Airbuses (probably from the same GIT you used) have that same problem! You should be able to see that in our last films!
4) and pls notice that I did NOT change my system since many month - pls do not say I did!!!

We have to find out what it is - and I tried to ask you for help when I suggested you try to take again the model you did use before and try if it is still working correct (I assume you no longer believe it is due to the "Jomo's ORCAM").

So: If you really want to help you could try to use different models (different version, some base FGFS some GIT) and see if they all have the same problem - or which do or do not have the problem!

[tdammers]

OK, in case anyone wants to test things further, I will be leaving two Twin Otters at EDDF for most of today. Callsigns are NL255 and NL256, parked right behind one another on the West Apron, parking position V174, between N14 and N15. The NL255 one is the stock model from FGDATA, downloaded using the launcher, and using the standard "FireFighter" livery, with a blunt nose, running on FG 2016.1 as packaged by the Debian project. The other one, NL256, is what I usually fly: the git version from FGMEMBERS, with one additional commit from myself that adds my own livery. This one has the stretched nose. The exact version I use can be found on github, at https://github.com/tdammers/dhc6 - however, apart from the livery, it should be exactly the same as the FGDATA version (plus the livery).

On my own two machines, both Twin Otters show up correctly; the main machine (controlling NL256) shows both liveries and noses as it should, the other machine (controlling NL255) doesn't have the newer livery, but it shows the NL256 aircraft with another livery, and with the stretched nose.

If anyone wants to confirm, feel free to stop by and take a look. And if you find that the nose is missing, I would love to hear about it, especially which FG version you're running, which DHC6 model you have installed, and which of the two shows up without a nose. That would be super helpful.

[jomo]

OK, in case anyone wants to test things further, I will be leaving two Twin Otters at EDDF for most of today.

Thanks for taking it serious.
See pictures http://www.emmerich-j.de/EDDF/twin-1 to 5

If you need more infos let me know - I will keep those 5 pictures posted for at least a week
Have fun with it