Board index FlightGear Multiplayer events

EDDF-Triangle

Virtual fly-ins, fun flies, competitions, and other group events. Find out details of upcoming events, register for competitions, or organize your own tour of a favorite location.

Re: EDDF-Triangle

Postby LH-1701 » Mon Jul 15, 2019 11:24 am

Hi Jomo,

one suggestion reguarding conflict situations like AAL4955 and me had yesterday (http://www.emmerich-j.de/EDDF/Films/201 ... 923-91.mp4 minutes apx 22 to 29)
In real aviation they solve situations like this usually via the elevation.

For example:

LH-1701, traffic. Stay on 10000 (or FL100 reguarding to trans altitude) or above
AAL4955, traffic. Stay below FL090.

After clearance of conflict:

LH-1701 continue descend to 5000 (maybe it would be neccessary to circle down over the VOR)
AAL4955 continue climb to cruise.

This would keep the vertical distance of 1000ft which is needed for vertical separation.
The advantage is that it would clear the conflict without loosing the SID/STAR .

reguards,

tobias LH-1701
#ISupportJomo
LH-1701
 
Posts: 29
Joined: Thu Feb 07, 2019 6:12 pm
Callsign: LH-1701
Version: 2018.3.2
OS: Linux

Re: EDDF-Triangle

Postby jomo » Mon Jul 15, 2019 3:06 pm

LH-1701 wrote in Mon Jul 15, 2019 11:24 am:Hi Jomo,
one suggestion reguarding conflict situations like AAL4955 and me had yesterday (http://www.emmerich-j.de/EDDF/Films/201 ... 923-91.mp4 minutes apx 22 to 29)
In real aviation they solve situations like this usually via the elevation.

Thank you for your suggestions. But I disagree with that proposal for this unique situation:
* AAL4955 was climbing from fl075 to .... (whatever the SID says/allows - for sure higher than your approach-altitude)
* you were descending from fl132 to fl050 over TAU
For a standard crossing situation your suggestion would be correct. But considering this as well horizontal as also vertical crossing that is not the best solution! There was NOT JUST a crossing: If you consider continuing Your coarse to TAU and AAL4955 on the SID to KUSOM->GUBAX then you would see that after the theoretical "crossing-point" you both would fly in parallel for a long long time -- and even within the holding-pattern over TAU you would have needed to cross his line multiple times - i.e. you both would have to deviate from your planed altitudes for a long long time - and you both would have had to change your planed course/altitude drastically!

Thus I decided to let you both cross not vertically but let AAL4955 cross behind you. That means all that was need was:
* You continue as planned - no restrictions at all
* AL4955 just crossing BEHIND you (instead of below you) and then just merges back into his SID 1point later!

I guess: I would do the same next time - but thanks for watching.
jomo / ATCjomo
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 912
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle

Postby wkitty42 » Mon Jul 15, 2019 8:53 pm

jomo wrote in Mon Jul 15, 2019 9:14 am:I have no idea how you got to that conclusion! Did you try to read just a little bit prior to come to that conclusion?

seems to me that he actually tested it and looked at the actual flow of data... richard is one of the FG developers, ya know? ;)

unless i have the wrong richard in mind, of course...
"You get more air close to the ground," said Angalo. "I read that in a book. You get lots of air low down, and not much when you go up."
"Why not?" said Gurder.
"Dunno. It's frightened of heights, I guess."
User avatar
wkitty42
 
Posts: 5644
Joined: Fri Feb 20, 2015 3:46 pm
Location: central NC, USA
Callsign: wk42
Version: git next
OS: Kubuntu 14.04.5

Re: EDDF-Triangle

Postby Richard » Mon Jul 15, 2019 11:16 pm

jomo wrote in Mon Jul 15, 2019 9:14 am:I have no idea how you got to that conclusion!


I arrived at my conclusion by a number of logical steps.

1.Verified that the problem happened with you at EDDF using my F-14 and the latest build of FG

Now to see where the problem is I had to do the following;

2. Installed OpenRadar, configured the FGFS ORCAM correctly.
3. Launched the ORCAM instance of FlightGear
4, Ensure that I understand how to use OpenRadar to make ORCAM work. Viewed various aircraft in your airspace all with version 1.
5. Start an F-14 in another FG instance on my machine. Verified that this was visible in OpenRadar - but as it was using V2 it wasn't visible in ORCAM
6. Analysed the data flow - to discover that OpenRadar is not MP forwarding V2 packets.
7. Verified (6) above with the debugger from within FG. No V2 packets are arriving.
8. Switch the F-14 into V1 and the packets start arriving at the ORCAM instance.

There is nothing to reconsider. OpenRadar isn't correctly forwarding V2 packets and it is OpenRadar that needs to be investigated and fixed.
Richard
 
Posts: 707
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: EDDF-Triangle

Postby WoodSTokk » Wed Jul 17, 2019 12:18 am

Richard was faster then me. Yes, OpenRadar doesn't forward V2 packets.
As a workaround, you can connect ORCAM directly with the MP server, because ORCAM is only a aircraft running a normal FG session.
As example, my previous start script for ORCAM was:
Code: Select all
fgfs \
--fg-aircraft=/home/woodstokk/OpenRadar/ORCAM \
--fg-aircraft=/home/woodstokk/.fgfs/Aircraft/de.djgummikuh.hangar.it0uchpods/Aircraft \
--fg-aircraft=/home/woodstokk/.fgfs/Aircraft/org.flightgear.fgaddon.trunk/Aircraft \
--fg-aircraft=/home/woodstokk/.fgfs/Aircraft/org.flightgear.fgaddon.stable_2018/Aircraft \
--multiplay=in,100,,5010 \
--multiplay=out,100,localhost,5010 \
--telnet=,,100,,5010, \
--aircraft=ORCAM \
--airport=LOWW \
--callsign=_

I have changed the connection to the MP server and it is now:
Code: Select all
fgfs \
--fg-aircraft=/home/woodstokk/OpenRadar/ORCAM \
--fg-aircraft=/home/woodstokk/.fgfs/Aircraft/de.djgummikuh.hangar.it0uchpods/Aircraft \
--fg-aircraft=/home/woodstokk/.fgfs/Aircraft/org.flightgear.fgaddon.trunk/Aircraft \
--fg-aircraft=/home/woodstokk/.fgfs/Aircraft/org.flightgear.fgaddon.stable_2018/Aircraft \
--prop:/sim/multiplay/txhost=mpserver03.flightgear.org \
--prop:/sim/multiplay/txport=5010 \
--telnet=,,100,,5010, \
--aircraft=ORCAM \
--airport=LOWW \
--callsign=LOWWorc

Don't touch the telnet parameter! This is the connection to OpenRadar.
As ORCAM is now directly connected to a MP server, it is visible in the pilot list.
In this case its a good idea to set the callsign to a meaningfull name (like 'EDDForc').
You can reverse the changes if OpenRadar receive a update that repair that bug.
WoodSTokk
 
Posts: 277
Joined: Tue Oct 17, 2017 2:30 pm
Location: Milky Way/Sol/Earth/Europe
Callsign: OE-WST
IRC name: WoodSTokk
Version: 2018.3.1
OS: Debian Buster/Sid

Re: EDDF-Triangle

Postby jomo » Wed Jul 17, 2019 10:35 am

WoodSTokk wrote in Wed Jul 17, 2019 12:18 am:Yes, OpenRadar doesn't forward V2 packets. As a workaround, you can connect ORCAM directly with the MP server, because ORCAM is only a aircraft running a normal FG session.
Sorry that I am that stubborn - I am just a poor user having big problems to understand these complex programmings - and I get more and more confused:
    * I still have no idea what that V1/V2 packages are - and where they are part of
    * and why in the MPsettings there is the option "Visible to only 2017+" or "Visible to all"
    * and why I (the filming ATC) never yet had a problem with guests coming with whatever model and or setting: If they switch to "Visble to All" everything works fine without changing anything on OR and/or ORCAM.
    * Could it be that this MPsetting has something to do with that V1/V2? Maybe that V1/V2 is supposed to try reducing the traffic via the MP-servers?
Based on the f-14 incident I checked my local Model-Library and found an older version of the f-14b (June 8 2017) than the one now in the FGFS-Library (Oct 2018) and maybe there are even newer ones. So it may be that is why one model is fine in MPevents and others do cause problems!?!? That would mean we have to define: All events only with models released after 2017? I definitely would not suggest that in regards to events where many many different users are coming and not all of them will love to check if they have the right model version. I would rather prefer my suggestion "during events all participants use the 'Visible to All' in MP.

By the way: My setup for ORCAM is: (compare http://wiki.flightgear.org/OpenRadar_FGFS_ORCAM)
Code: Select all
#!/bin/sh
/usr/games/fgfs   \
--fg-root=/usr/share/games/flightgear   \
--fg-scenery=/home/emmerich/terraGIT    \
--fg-aircraft=/usr/share/games/flightgear/Aircraft   \
--aircraft=ORCAM    \
--callsign=EDDFjo1   \
--airport=EDDF   \
--telnet=,,100,,5010, \
--multiplay=in,100,,5010 \
--multiplay=out,100,localhost,5010 \
--geometry=1152x864   \
--timeofday=noon   \
--enable-ai-models \
--disable-rembrandt   \
--disable-ai-traffic \
--disable-sound   \
--prop:/sim/frame-rate-throttle-hz=15 \
--enable-terrasync      \
--httpd=8080   \
i.e. --> no extra Link to MPserver - and with that unchanged setup I can visualize any plane in my area even if OR is not active/started! You can try to use this without OpenRadar yourselfe! Then you will notice that You actually ONLY miss the GPS-Focus-Data from OR - i.e. you then have to manually set them into the "Internal Properties".

Can anybody help me by explaining:
* What is V1/V2, where is it and what is it for ? (Reduce MP-traffic?)
* Are we still allowed to fly OLD models from many years ago ? (I see them weekly at EDDF!)
* Can we tell everybody participating in any event that he should set MP to "Visible to All"! (As I do it now as ATC)
* I am sure OR-designers cannot help us there - because as stated above in the first lines: "ORCAM is only an aircraft running a normal FG session .." --> i.e. you always have the VIEW functions as from any other FGFS-model! You do not need OR for that!
* Would it matter if events (without OpenRadar) will continue to have that problem between all participants themselves?
Again: Sorry - but I see that as important for people liking events and making photos, films, etc. (as well with new as also with old models!)
jomo / ATCjomo
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 912
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle

Postby Richard » Wed Jul 17, 2019 1:32 pm

jomo wrote in Wed Jul 17, 2019 10:35 am:* I still have no idea what that V1/V2 packages are - and where they are part of

A packet is sent between FlightGear and the multiplayer server.

V1 packet is "Visible to All"
V2 packet is "Visible to only 2017+"


jomo wrote in Wed Jul 17, 2019 10:35 am:* and why in the MPsettings there is the option "Visible to only 2017+" or "Visible to all"

For backwards compatibility with pre 2017.1 FlightGear.

To be clear it is to allow someone running 2016.4 (or before) to see all of *the animations* (gear, elevators, etc.) from someone running 2017.1 or later.


jomo wrote in Wed Jul 17, 2019 10:35 am:* and why I (the filming ATC) never yet had a problem with guests coming with whatever model and or setting: If they switch to "Visble to All" everything works fine without changing anything on OR and/or ORCAM.

Because OpenRadar doesn't correctly support V2 packets; so when your pilots switch to V1 (Visible to all) packets OpenRadar will forward these packets correctly.

The way that ORCAM works (according to the documentation) is to use the OpenRadar MP relay to send packets from OpenRadar to ORCAM.


jomo wrote in Wed Jul 17, 2019 10:35 am:* Could it be that this MPsetting has something to do with that V1/V2? Maybe that V1/V2 is supposed to try reducing the traffic via the MP-servers?

V2 is to reduce the network traffic and to allow many more properties to be sent (in a smaller amount of space). That's the reason for V2.


jomo wrote in Wed Jul 17, 2019 10:35 am:Based on the f-14 incident I checked my local Model-Library and found an older version of the f-14b (June 8 2017) than the one now in the FGFS-Library (Oct 2018) and maybe there are even newer


The problem you saw with the F-14 model is 100% not caused by incompatible models. I can be sure because it is my model and I understand it completely.

It is possible that a new model will not show - but unlikely as generally the model names don't change. More likely is that animations will not work correctly between model versions. Most aircraft developers should be aware that changing MP property usage can break older versions - but sometimes it is impossible to avoid.


jomo wrote in Wed Jul 17, 2019 10:35 am:Can anybody help me by explaining:

* What is V1/V2, where is it and what is it for ? (Reduce MP-traffic?)

V1 packet is "Visible to All"

V2 packet is "Visible to only 2017+"

V2 is to reduce the network traffic and to allow many more properties to be sent (in a smaller amount of space). That's the reason for V2.


jomo wrote in Wed Jul 17, 2019 10:35 am:* Are we still allowed to fly OLD models from many years ago ? (I see them weekly at EDDF!)

Yes; models are not affected by this change if you are using FlightGear 2017.1 or later then it will handle both V1 and V2 automatically.


jomo wrote in Wed Jul 17, 2019 10:35 am:* Can we tell everybody participating in any event that he should set MP to "Visible to All"! (As I do it now as ATC)

That is what you will have to do until OpenRadar is fixed; or you use the alternative way to connect ORCAM to the normal flightgear multiplayer server instead of the OpenRadar MP relay.


jomo wrote in Wed Jul 17, 2019 10:35 am:* I am sure OR-designers cannot help us there - because as stated above in the first lines: "ORCAM is only an aircraft running a normal FG session .." --> i.e. you always have the VIEW functions as from any other FGFS-model! You do not need OR for that!

I am 100% totally sure that it is only the OpenRadar developers who can fix this problem - because OpenRadar is acting as a MP relay.

What this means is that OpenRadar receives the multiplayer packets from the main FlightGear multiplayer servers (e.g. mpserver01.flightgear.org) and then it sends these packets out on port 5010 to the ORCAM FlightGeear instances. The ORCAM FlightGear instance is not connected to the normal multiplayer servers but instead ORCAM is connected to OpenRadar.


jomo wrote in Wed Jul 17, 2019 10:35 am:* Would it matter if events (without OpenRadar) will continue to have that problem between all participants themselves?

Providing that those participating in events are running 2017.1 or later there will not be a problem; only pilots running old FlightGear (before 2017.1) will be unable to see animations.
Richard
 
Posts: 707
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: EDDF-Triangle

Postby LH-1701 » Thu Jul 18, 2019 8:25 am

Hi Jomo,

only as addition:

For a standard crossing situation your suggestion would be correct. But considering this as well horizontal as also vertical crossing that is not the best solution! There was NOT JUST a crossing: If you consider continuing Your coarse to TAU and AAL4955 on the SID to KUSOM->GUBAX then you would see that after the theoretical "crossing-point" you both would fly in parallel for a long long time -- and even within the holding-pattern over TAU you would have needed to cross his line multiple times - i.e. you both would have to deviate from your planed altitudes for a long long time - and you both would have had to change your planed course/altitude drastically!


Thats correct , but thats why i meant to wait "After clearance of conflict".
Of course you are right, we both would have to deviate from planned altitudes for a period of time,
and i would have to circle down over TAU after AAL4955 has left the area. Also he needs to climb later.
The advantage would be that we both could stay on our planned courses.

I guess: I would do the same next time

Thats ok in my eyes, i think both methods are valid as long as separation is kept.

See you next time!

Tobias (LH-1701)
#ISupportJomo
LH-1701
 
Posts: 29
Joined: Thu Feb 07, 2019 6:12 pm
Callsign: LH-1701
Version: 2018.3.2
OS: Linux

Re: EDDF-Triangle

Postby AAL545 » Thu Jul 18, 2019 3:27 pm

Interesting topics going on here, I really like this because it shows the true love for the Libre system, people dedicating their free time to improve it,
also, thanks to Jomo for the filming so that the bugs are found, not to mention all the contributors. Maybe now they can find out why the landing gear on the B-777 isn't flattening out.




Thats correct , but thats why i meant to wait "After clearance of conflict".
Of course you are right, we both would have to deviate from planned altitudes for a period of time,
and i would have to circle down over TAU after AAL4955 has left the area. Also he needs to climb later.
The advantage would be that we both could stay on our planned courses.


Another way of doing this is instead of climb to cruse is climb to an approved FL like in real life, downside is this will add to the work load of the ATC.


AAL4955
AAL545
 
Posts: 174
Joined: Tue Aug 08, 2017 4:14 am

Re: EDDF-Triangle

Postby Isaak » Thu Jul 18, 2019 9:12 pm

AAL545 wrote in Thu Jul 18, 2019 3:27 pm:Maybe now they can find out why the landing gear on the B-777 isn't flattening out.


I've only seen this in the movies, not in my MP environment. I was at EDDF last sunday and saw two other 777's landing/taking off, every time with the proper gear animation. Maybe it has something to do with the properties not being sent correctly to ORCAM?
Isaak
 
Posts: 455
Joined: Sat Jun 04, 2011 2:52 pm
Location: Leuven, Belgium
Callsign: OO-ISA
Version: 2019.1.1
OS: Windows 10

Re: EDDF-Triangle

Postby AAL545 » Fri Jul 19, 2019 3:41 am

I've only seen this in the movies, not in my MP environment. I was at EDDF last sunday and saw two other 777's landing/taking off, every time with the proper gear animation. Maybe it has something to do with the properties not being sent correctly to ORCAM?


It's been a while since this issue has been discussed but what I remember is FG has changed how much data is being sent, but that doesn't make sense if you can see the landing properly on the ground over the MP environment,
so it must be ORCAM like you mentioned.
Actually it's not only the landing gear but I remember the speed brakes should properly as well but not anymore. Either way a great plane to fly!!!



AAL4955
AAL545
 
Posts: 174
Joined: Tue Aug 08, 2017 4:14 am

Re: EDDF-Triangle

Postby jomo » Fri Jul 19, 2019 8:05 am

AAL545 wrote in Fri Jul 19, 2019 3:41 am:It's been a while since this issue has been discussed but what I remember is FG has changed how much data is being sent, but that doesn't make sense if you can see the landing properly on the ground over the MP environment,
so it must be ORCAM like you mentioned.
Pls be aware that one of the problems with filming the events is: The film will show the model as it is in the local library of that ORCAM-user (e.g. me!). So pls send me the release data of your model (or the whole model) so I can compare it with my library-status! (I am not reloading/syncing all of my 200 local models regularly!)
jomo / ATCjomo
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 912
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle

Postby jomo » Fri Jul 19, 2019 8:32 am

jomo wrote in Fri Jul 19, 2019 8:05 am:Pls be aware that one of the problems with filming the events is: The film will always show the model as it is in the local library of the ORCAM-user
Sorry I forgot to make the point: Maybe a good idea always is: Have a look locally with your outside VIEW-options and compare it with what is shown in the movie. If it does not match tell me and include from where you have downloaded what! Remember: There may be many libraries with many models of the same name - but still are different. I usually download from the FGFS-Library and/or from https://github.com/FGMEMBERS. Consider that in my library I can only have 1 model with a unique name - I will not constantly change the libraries on request! We discussed this problem of multiple libraries with "same models looking different" already more often - that is not only an ORCAM-problem but happens whenever you view Your friend flying the same model (ID): You will always see the model that is loaded in your local library - that may not be what your friend is flying!!!
jomo / ATCjomo
ATC at EDDF Fr,Sa,Su,We from 20:00 to 24:00 CET/MEZ., see http://www.emmerich-j.de
User avatar
jomo
 
Posts: 912
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle

Postby legoboyvdlp » Fri Jul 19, 2019 9:25 am

Well - FGADDON just got fixes to the animations of the 777 over multiplayer. Perhaps that is to do with it -- if you use FGADDON 777 instead of FGMEMBERS (which is very outdated and has stolen texture files / sounds that might help fix the landing gear!
User avatar
legoboyvdlp
 
Posts: 7007
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: EDDF-Triangle

Postby AAL545 » Fri Jul 19, 2019 3:22 pm

Have a look locally with your outside VIEW-options and compare it with what is shown in the movie.


Sorry not sure what you mean!!!



I am not downloading from this source anymore as the B777 is outdated and because of stolen data,
instead am now using this model as it is regularly updated. http://mirrors.ibiblio.org/flightgear/f ... aft-trunk/.
This link is the actual download link from FGMEMBERS, in other words the same model aircraft and the same maintainers!



AAL4955
AAL545
 
Posts: 174
Joined: Tue Aug 08, 2017 4:14 am

PreviousNext

Return to Multiplayer events

Who is online

Users browsing this forum: Dogers and 4 guests