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 jomo » Tue Mar 05, 2019 12:04 am

LH-1701 wrote in Mon Mar 04, 2019 9:45 pm:The @ in front of a name in chat message is meant similar to "hey xxx" so for example "@LH-1701" means "hey LH-1701"

Please do the following test between 2 PC's:
Code: Select all
open on PC1 OpenRadar with ID "@EDDFjom"
open on PC2 OpenRadar with ID "EDDFjom"
send some orders between those two ATCs on different servers during the same session!

The result is as was obviously planed by the "antiJomo" group:
Code: Select all
"23:20:02 test1:    @test1: Ätsch - who is now the real "test1"-ATC -- whom I should follow?"

Thus there are now 2 different ATC's serving at the same AP - which is not possible via MP !
Thus the "@" is part of the UID - not a standalone greeting!
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: 877
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle

Postby legoboyvdlp » Tue Mar 05, 2019 3:17 pm

Thank you to lenny for dealing with the issue!

http://flightgear-atc.alwaysdata.net/
User avatar
legoboyvdlp
 
Posts: 6506
Joined: Sat Jul 26, 2014 1:28 am
Callsign: YV-LEGO
Version: 2018.3.1
OS: Windows 10 HP

Re: EDDF-Triangle

Postby LH-1701 » Tue Mar 05, 2019 4:14 pm

Yes, this unneccessary blockings are removed! good way!

Reguarding the @:

So you mean that when you add an "@" to the user-ID in OpenRadar this character not visible in the MP List, so that "@EDDFjom" would show up as "EDDFjom" in the MP list?
I dont have openRadar installed, but will try this with FG multiplayer later.

This is just 4 interest, i hope the sessions will not be disturbed anymore.

reguards

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

Re: EDDF-Triangle

Postby jomo » Tue Mar 05, 2019 5:02 pm

LH-1701 wrote in Tue Mar 05, 2019 4:14 pm:So you mean that when you add an "@" to the user-ID in OpenRadar this character not visible in the MP List, so that "@EDDFjom" would show up as "EDDFjom" in the MP list?

I am not sure we talk the same - thus: Actually that evening:
There were 2 IDs giving ATCorders: "EDDFjom" + "@EDDFjom"
(the @EDDFjom often came from a Flight model - not from an OR !!! But which user investigates if the "ATC" commands come from an OR or helicopter or or...??)
thx for your support
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: 877
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle

Postby PINTO » Tue Mar 05, 2019 5:27 pm

The max callsign length that people using FG can see is 7 characters. If they were talking to someone with an ‘@‘ at the beginning of their name, they would be talking to an ‘@EDDFjo’, since it is impossible to have the callsigns ‘@EDDFjom’ and ‘@EDDFjomo’ be show over mp. OpenRadar and Flightgear will let you assign yourself a callsign over 7 characters, but everything over 7 gets truncated when sending to everyone else.
Actively developing the MiG-21bis (link to repo) (link to thread)

http://opredflag.com is an active flightgear dogfighting community (using a system that isn’t bombable)
User avatar
PINTO
 
Posts: 935
Joined: Wed Oct 21, 2015 6:28 pm
Callsign: pinto
Version: 2016.3.0
OS: Win10

Re: EDDF-Triangle

Postby lenny64600 » Wed Mar 06, 2019 12:04 pm

Hello everybody,

Some malicious users created some fake EDDF sessions on the website http://flightgear-atc.alwaysdata.net/ . Here are the actions that has been made in order to avoid future problems:
1. I removed all the ATC-events created by those users
2. I created a way for "trusted ATCs" to get "verified". It means that when they will plan an ATC-event their pseudo will appear with a green label on it (like Jomo right now).
3. Now everyone (verified or not) is able to plan ATC-events but in the future we will be able to refuse events created by non-trusted ATCs (with refused verifications).
4. If you want your account to be "verified" (and you want others to see that you are a "trusted ATC") please log in to your ATC Dashboard and follow the instructions. Once logged in, this link will tell you if your verification is pending, verified or not verified...
5. The contact page is available if you have any doubt, question, or remarks.

I hope it will be enough to get rid of those users...
Best regards,
Lenny
*NEW : New website to follow ATC sessions : http://flightgear-atc.alwaysdata.net
Follow us on Twitter
@Flightgear_ATC
User avatar
lenny64600
 
Posts: 43
Joined: Thu Jan 24, 2013 6:54 am
Location: France
Callsign: LFOK_TW, F-LENNY
OS: Linux

Re: EDDF-Triangle

Postby tdammers » Mon Mar 11, 2019 9:52 pm

@jomo, re the yellow glider problem with the CRJ700/900 at the last event. I've done some additional experimenting and research, and found a few interesting things. But before I go into details, I'd like to clarify that this isn't to blame anyone or anything, I just wanted to satisfy my curiosity, and thought I'd share my results, for future reference.

So first, some observations.

- In the video, there's another pilot flying a CRJ700, and their model also shows as a yellow glider.
- OpenRadar shows my aircraft type as "CRJ9". The other CRJ however is shown as "CRJ700" (full model name, not ICAO designator).
- At the end of the session, when we tried a couple combinations, there were three differences between the last failed attempt and the successful one: 1. I had been using mpserver01 for the failed experiments, but mpserver03 for the successful one, and so I initially suspected mpserver01 to be the culprit. 2. For the successful run, I used the CRJ700, while the unsuccessful ones were done with various other models from the CRJ700-family (900, 1000, 1000ER). 3. Between the unsuccessful runs and the successful run, you apparently deleted your CRJ700 install, and then installed the CRJ700-family from github.

Armed with this, I tried to replicate the problem, using mpmap03.flightgear.org as a convenient way of checking the aircraft ID as sent over FG MP. Since I suspected mpserver01 to be the culprit, somehow truncating the aircraft name from "CRJ900" to just "CRJ", I logged onto MP in various ways, exactly as I had done during the event - however, no matter which MP server and aircraft model I chose, they all showed correctly. So I had to dismiss this theory - neither the 700 vs. 900 difference, nor the mpserver01 vs. 03 / 19 / ... change made any difference.

And then I remembered that there are hard-coded paths inside the CRJ700 family, which means that installing it into a directory other than "CRJ700-family" could cause it to not load correctly. I also remembered that yours had been installed into "CRJ700", not "CRJ700-family". So that is the probable cause of the problem, as far as I can tell. And further, it's possible that those paths inside the CRJ aircraft that referenced the "CRJ700-family" directory weren't there in older versions of the aircraft, which would explain why it worked a few weeks ago, when I last visited: without those references, it doesn't matter how you name the directory, as long as it's directly under your aircraft directory.

So where does the "CRJ9" come from? Simple: that's what I entered on alwaysdata when filing the flight plan. IRL, you would use ICAO designators for the aircraft type, and most flight plans I see on alwaysdata do exactly that - you file "B772", not "777-200" or "Boeing 777-200", and likewise, you file "CRJ9", not "CRJ900" or "CRJ-900". OpenRadar, then, automatically fetches the flight plan from alwaysdata, and displays the filed type ("CRJ9"), ignoring what it sees on the network ("CRJ900"). The other CRJ that night hadn't filed a flight plan, so OpenRadar had nothing else to display than what the FG MP network said ("CRJ700"). So it's not that my client didn't send the full model name, and the mpserver didn't eat half the type name either; this is simply a feature of OpenRadar, and it worked as designed. ORCAM, which uses the exact same aircraft model resolution logic as the full-blown regular FlightGear codebase, doesn't care though: it always looks at the MP network, and completely ignores alwaysdata and OpenRadar (in fact it doesn't even know alwaysdata exists). Even if OpenRadar says "CRJ9", ORCAM still gets "CRJ900", and uses that to find the correct model. I could file "Foobar 12345" as the aircraft type, and ORCAM would still use whatever I was actually flying, while OpenRadar would happily display "Foobar 12345", at least once you have imported the flight plan. I think this is what made you believe that my client was cutting off the aircraft name, and what got me confused during the session.

Hope this clarifies things, if not, feel free to ask.
tdammers
 
Posts: 193
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256

Re: EDDF-Triangle

Postby WoodSTokk » Tue Mar 12, 2019 1:37 am

I dont know from where OpenRadar take the model, but I was at EDDF 1 week ago with a 707 and have not filled a flightplan.
In the movie I see the flight stripe on the right side with correct model '707' and on the radar screen the model is mentioned as 'B703'.
I do a grep over the whole 707 directory, but can NOT find any location with the text 'B703'.
I absolutely don't know what algorythm behind OpenRadar work that out.
WoodSTokk
 
Posts: 195
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 tdammers » Tue Mar 12, 2019 8:19 am

WoodSTokk wrote in Tue Mar 12, 2019 1:37 am:I dont know from where OpenRadar take the model, but I was at EDDF 1 week ago with a 707 and have not filled a flightplan.
In the movie I see the flight stripe on the right side with correct model '707' and on the radar screen the model is mentioned as 'B703'.
I do a grep over the whole 707 directory, but can NOT find any location with the text 'B703'.
I absolutely don't know what algorythm behind OpenRadar work that out.


Maybe it knows how to match certain model names to ICAO designators.
tdammers
 
Posts: 193
Joined: Wed Dec 13, 2017 10:35 am
Callsign: NL256
IRC name: nl256

Re: EDDF-Triangle

Postby jomo » Tue Mar 12, 2019 10:44 am

tdammers wrote in Mon Mar 11, 2019 9:52 pm:@jomo, re the yellow glider problem with the CRJ700/900 at the last event.

Sorry - I do not completely understand what you try to explain - let me try to explain my understanding of the basics:
* If you view your model with e.g. "View -> View Options -> Chase View" you see your model as installed in your local Aircraft directory! That one depends on when you downloaded it from whatever library! There often are different libraries with different looking models/structures of the same plane.
If somebody else views Your model - he/she NEVER sees Your model -- but he/she sees the model that is installed in his local PC for the model-ID that is transmitted via MPservices.

So (as in our case) we had different versions of your model installed in our different PCs - and thus we have seen different things! The big confusion was started due to different file-structures (and names?) for that same model on different versions! That was proven at the end by us two both having downloaded the latest version from the GIT --> and everything was fine!

Some words to the co-players:
MPserver just transfer Model-ID plus the setting of controls + location (not the model picture!)
Open Radar does not care about the model at all - it just puts the Model-ID into a text-field (and starts ORCAM with model ID, position etc.)
ATC using ORCAM (=FGFS model: "Air Traffic Control No.2") just displays the model as each FGFS-model does: Just displaying the view of the model-ID xfered via MPserver as it finds it in the ATC-local-library
Flight-plan is either manually inserted into the Flight-strips by the ATC or as inputted into "Larrys" http://flightgear-atc.alwaysdata.net/ -- there has been developed an extra Interface between OR and Larry! It does not use MP!!

So I guess we only have one little problem:
How do we get every pilot to update his local Model-libraries at the same time! (Remember: It worked after we both downloaded the newest version from the same Master (GIT)!) And it is not just a matter of different versions --> in the meantime there are more and more designers using different libraries to design "the best of all" models with the same ID - thus pilots may use different models under the same ID! Please feel a little sorry for those poor ATC's who get beaten all the time because they may not always be able to show all models with the same ID but different version and/or design-lib's, etc, etc, ...!
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: 877
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle / What are the rwy which may become active

Postby EagleRainbow » Sat Apr 06, 2019 6:59 pm

Hi folks,

I am currently reading through the wiki page at http://wiki.flightgear.org/index.php?ti ... did=114003 and one section makes me scratch my head.
In section 4.4.3. "Runway Settings" it's written (as of current wiki page version):

Per Law you [...]
may only use runway 18, 07L, and 25R for "Landings" --> thus disable only "Landing": Just the "Land"-Option disappears


That does not make much sense to me: if runways may only be used for landings, then I don't disable the landing check boxes.
Moreover, it sounds strange that rwy 18 is only permitted for landings - whereas on https://en.wikipedia.org/wiki/Frankfurt_Airport#Runways it is stated that 18 is only permitted for take-offs (and not for landings).
However, on the other hand the en.wikipedia.org article states that the rwys 07L/25R are permitted for landing only (no take-off).
I am confused now... :?

Anyone to rescue?
Thanks!
EagleRainbow
 
Posts: 3
Joined: Sat Apr 06, 2019 6:49 pm
Callsign: D-ER144
Version: 2018.3.2
OS: Win10

Re: EDDF-Triangle

Postby Isaak » Sat Apr 06, 2019 7:18 pm

Wikipedia is correct: rwy 18 is takeoff only. Rwy 36 is prohibited for all ops and rwy 07L/25R is landing only.
Isaak
 
Posts: 346
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 EagleRainbow » Sat Apr 06, 2019 9:08 pm

Isaak wrote in Sat Apr 06, 2019 7:18 pm:Wikipedia is correct: rwy 18 is takeoff only. Rwy 36 is prohibited for all ops and rwy 07L/25R is landing only.

Thanks. IMO that means that the page at fg-wiki should get an overhaul...
EagleRainbow
 
Posts: 3
Joined: Sat Apr 06, 2019 6:49 pm
Callsign: D-ER144
Version: 2018.3.2
OS: Win10

Re: EDDF-Triangle / What are the rwy which may become active

Postby jomo » Sun Apr 07, 2019 6:17 am

EagleRainbow wrote in Sat Apr 06, 2019 6:59 pm:Per Law you [...]
may only use runway 18, 07L, and 25R for "Landings" --> thus disable only "Landing": Just the "Land"-Option disappears

Yo are right - that wording is wrong! I changed it - pls have a look if it is ok now.

By the way: the https://en.wikipedia.org/wiki/Frankfurt_Airport is correct - but may be confusing by stating:
"18/36 A: used for Takeoffs only in 1 direction" - but does not clearly state that this "1 direction" is the rw18 -- thus the rw36 has no function at all!
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: 877
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle / What are the rwy which may become active

Postby EagleRainbow » Sun Apr 07, 2019 8:14 am

jomo wrote in Sun Apr 07, 2019 6:17 am:Yo are right - that wording is wrong! I changed it - pls have a look if it is ok now.

By the way: the https://en.wikipedia.org/wiki/Frankfurt_Airport is correct - but may be confusing by stating:
"18/36 A: used for Takeoffs only in 1 direction" - but does not clearly state that this "1 direction" is the rw18 -- thus the rw36 has no function at all!


+1 - that's much better!
Thanks for fixing it, Jomo.
EagleRainbow
 
Posts: 3
Joined: Sat Apr 06, 2019 6:49 pm
Callsign: D-ER144
Version: 2018.3.2
OS: Win10

PreviousNext

Return to Multiplayer events

Who is online

Users browsing this forum: No registered users and 1 guest