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 wkitty42 » Mon Jun 04, 2018 6:06 pm

tdammers wrote in Mon Jun 04, 2018 3:47 pm:
wkitty42 wrote in Thu May 31, 2018 2:31 pm:speaking of those problems, it almost sounds like the one where the one craft with multiple noses was being displayed with no nose... this was because they were not defaulting that property to false... since the property was not being sent to the remote, it was defaulting to false over there and they were not seeing the nose at all... once the craft was fixed, the nose reappeared and things have been fine ever since... so where's this going? it is possible that the logic in your craft is backwards for your landing gear and livery selection stuff... i dunno...


The aircraft in question is the DHC-6;

yep... that was the craft i was thinking of...

tdammers wrote in Mon Jun 04, 2018 3:47 pm:defaulting the nose to "false" doesn't fix the underlying problem, the property is still not being sent, the model now just deals with it in a less disruptive way. Instead of "oh dear, there's no nose property, so let's not select any nose at all", it now goes "oh dear, there's no nose property, so let's select the long nose, wild guess".

hahaha... well, kinda... it doesn't take a guess... it uses zero as the default since the nose choice indicator is something like 0, 1, 2 or 3... i don't remember all the details but i did read them and the fix that was applied to the craft...

tdammers wrote in Mon Jun 04, 2018 3:47 pm:And because of this, the same approach won't work for landing gear, because if the "gear down" property isn't transmitted, then you can only default to "gear always down" or "gear always up"; neither will be helpful.

true but it won't hinder your flight, either... there won't be any drag... it'll only look funny to others looking at your craft on MP... how many folks make the majority of their flights with others and go looking at the other craft instead of paying attention to their's? ;)

tdammers wrote in Mon Jun 04, 2018 3:47 pm:
wkitty42 wrote in Thu May 31, 2018 2:31 pm:the MP protocol was modified back in 2017... then a few updates were made to it to fix a couple of problems...
remember, the MP protocol has fixed sized packets it sends... if a craft tries to send to much, the packets will be truncated... that could easily lead to problems like this...


Well, the new v2 protocol will actually chop up a property tree update into multiple packets if it doesn't fit into one; and older (v1-only) clients will still receive and process the first of those, just not the subsequent ones. And unfortunately, authors have very limited control (bordering on useless) over the order in which they are packed, so you can't even say "OK, these 16 properties here are essential and must go into the first packet, everything after that is eye candy and may be ignore by v1 clients", and then stuff things like surface positions, cockpit / cabin lights, doors, etc., into those "less important" props, and landing gear and such into the "important ones".

right... and this problem has been with FG for a long time... craft are sending more and more data over the protocol... the craft have to be updated to work with the new fixes to the protocol or there will be problems... i seem to remember some group talking about having all the craft somewhere so it would be easier for craft developers to maintain them and fix the bugs in them... somehow, that doesn't seem to be happening as described...

anyway, folks have a choice...
    1. they can run old FG without all the neat new features and capabilities which means they will have to run old versions of their craft.
    OR
    2. they can run the new stuff and wait on the craft to catch up.
    OR
    3. they can run the new stuff and learn how to fix the craft themselves and share it with the rest of the community instead of carrying on about the craft bugs that aren't being fixed.
it really is that simple...
"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: 5428
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 Jun 04, 2018 7:42 pm

tdammers wrote in Mon Jun 04, 2018 3:47 pm:Well, the new v2 protocol will actually chop up a property tree update into multiple packets if it doesn't fit


The 2017.2 protocol doesn't do that. If the properties don't fit into a packet a message is output onto the console and properties aren't sent. This can happen when the packet is nearly full and text chat is used (as text is variably sized). There is a property /sim/multiplay/last-xmit-packet-len that tells you the size of the last packet transmitted. This is useful information for developers, but also for the pilot whose model isn't appearing correctly.

There may be other problems with the V2 protocol that are lingering in there - it was a hard thing to develop and I spent a lot of time validating that it was right; however it is complicated and things could be missed.

All I need is a bug report saying what the two versions of FG are; the affected model, and where to get the model from if it isn't from FGAddon.

Any version of FG should be able to receive packets from any other equal or earlier version, regardless of what is sent. The reverse isn't true and earlier FG will only be able to send packets to newer FG, so any incoming data will be reduced to basic position information. Models should always be visible and in the right place. This part of the protocol is unchanged.

Also worth remembering that we had MP problems long before I changed the protocol; so there could be other factors at play.
Richard
 
Posts: 690
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: EDDF-Triangle

Postby AAL545 » Tue Jun 05, 2018 4:13 am

The 2017.2 protocol doesn't do that. If the properties don't fit into a packet a message is output onto the console and properties aren't sent. This can happen when the packet is nearly full and text chat is used (as text is variably sized). There is a property /sim/multiplay/last-xmit-packet-len that tells you the size of the last packet transmitted. This is useful information for developers, but also for the pilot whose model isn't appearing correctly.



Hi Richard,

Parked at EDDF with a B777-200LR (no activity) with my MP setting at "Visible to all" my /sim/multiplay/last-xmit-packet-len = '832' (int)
With my MP setting at "Visible to only 2017+" my /sim/multiplay/last-xmit-packet-len = '568' (int)
Tried to post a screen shot but no luck. Anyway I hope this helps.


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

Re: EDDF-Triangle

Postby Richard » Tue Jun 05, 2018 4:57 am

AAL545 wrote in Tue Jun 05, 2018 4:13 am:Parked at EDDF with a B777-200LR (no activity) with my MP setting at "Visible to all" my /sim/multiplay/last-xmit-packet-len = '832' (int)
With my MP setting at "Visible to only 2017+" my /sim/multiplay/last-xmit-packet-len = '568' (int)
Tried to post a screen shot but no luck. Anyway I hope this helps.


Useful info; the V1 protocol at 832 has enough overhead that it shouldn't run out of space in the packet.

If there is a problem what I need is a bug report saying what the two versions of FG are; the affected model, and where to get the model from if it isn't from FGAddon, for example:

Running 2018.1 with the B777-200LR from FGAddon, the MODEL ELEMENT isn't WHAT IS WRONG on another computer running 2017.2
Richard
 
Posts: 690
Joined: Sun Nov 02, 2014 10:17 pm
Version: Git
OS: Win10

Re: EDDF-Triangle

Postby AAL545 » Tue Jun 05, 2018 7:03 pm

If there is a problem what I need is a bug report saying what the two versions of FG are; the affected model, and where to get the model from if it isn't from FGAddon, for example:



I think it would be quicker if you would provide me with instructions on doing a bug report, sorry newbie here.



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

Re: EDDF-Triangle

Postby wkitty42 » Wed Jun 06, 2018 4:33 am

see the Bug Tracker link at the top of the page?
"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: 5428
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 jomo » Wed Jun 06, 2018 7:49 am

Just as an example:
legoboyvdlp wrote in Thu May 31, 2018 9:25 am:OpenRadar, last I checked, is not compatible with MP Protocol v2.

There seem to be a lot of misunderstandings about the not correctly shown models in the EDDF-Triangle-movies! Let me try to explain what is involved there: (see e.g. http://wiki.flightgear.org/OpenRadarGuide#FGFS_ORCAM )

OpenRadar just provides the Radar picture --> i.e. the POSITION of the Aircraft - not the view of the model!
ORCAM really is basically the, since a long time known and still used, "atc-tower" --> it displays the model. Only the usually manually selection of which model to view comes from the OR.
The filming has nothing to do with the FGFS at all!! It is a "Screen-Coppy" - just copying what is displayed on the screen (i.e. pixels - not models!)!

There was tested already a couple of times that these problems are independent of OR+ORCAM. See e.g. the "missing nose" on the the viewtopic.php?f=10&t=13009&start=75#p331400. It proves that OR+ORCAM does display all models correctly if those model have been upgraded to the newer protocol.

So pls let us concentrate on the model-engineers to satisfy the users that want to see a perfect model in our EDDF-Triangel movies. I do not see what i can do for a solution. But ALL of YOU might help by flying models that do show up as you like it - I am sure that all engineers would like to have their model flown as much as possible - so they might react!

By the way: You do not need the EDDF-installation to verify - just go to any other active OR-location (with ORCAM) to let the guy view your model. Also just viewing a model from another model (e.g. during events) should show the same problem - just by viewing each other via the normal "menu --> View".

Pls let us try to solve it - believe me: It is even worse for me - because that very often is causing a "hang" in my programs during the events!
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: 897
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle

Postby wkitty42 » Wed Jun 06, 2018 4:31 pm

@jomo: have you set your FG that you are using for the tower/orcam view to be using MP protocol v2? if you have not and the user you are videoing from the tower has, you may see this problem and thus record it...
"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: 5428
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 jomo » Wed Jun 06, 2018 6:12 pm

wkitty42 wrote in Wed Jun 06, 2018 4:31 pm:@jomo: have you set your FG that you are using for the tower/orcam view to be using MP protocol v2? if you have not and the user you are videoing from the tower has, you may see this problem and thus record it...


I guess you mean the Multi-player setting in the FGFS menu - usually that is set to "visible to all". See film
http://www.emmerich-j.de/EDDF/Films/201 ... 831-96.mp4
About in center of that film I am testing with AL4955 exactly that in both ways - it did worsen the situation!
So I am back on "for all". If you want you are welcome to retest it yourself.

thanks for caring
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: 897
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

Re: EDDF-Triangle

Postby wkitty42 » Wed Jun 06, 2018 8:59 pm

visible to all is the correct setting... AL4955 should be using the same setting, too... hopefully everyone is also using 2018.2.1 at least... 2018.2.2 as of a few days ago... if that doesn't take care of it with his craft, then his craft needs to be fixed... older craft will act the same way, since they likely have the same MP code in place, so dropping back to one of those is not a solution... it probably needs to be reworked to take advantage of the newer capabilities... like packing booleans and similar...
"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: 5428
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 AAL545 » Thu Jun 07, 2018 1:35 am

hopefully everyone is also using 2018.2.1 at least.


Why do you say that, unless it'll improve our situation here?
Regarding aircraft, what I have noticed is if I install older or newer aircraft in a home folder that's the model FG will be using,
if I install it in the hidden home folder /user/.fgfs/Aircraft/org.flightgear.fgaddon/Aircraft it will update to the FG database.
Can you comment regarding installing via these two options?
I guess what I am getting at and I have commented on this, FG should be a 100% integrated system and we break the link if we/I download aircraft
that aren't 100% up to snuff with the FG program. Sure you can fly the aircraft but will issues.

FG 2018.2.1
Linux Mint 18.3
AAL4955
AAL545
 
Posts: 165
Joined: Tue Aug 08, 2017 4:14 am

Re: EDDF-Triangle

Postby fg101 » Thu Jun 07, 2018 6:05 am

MP Map 03 is up and running (mpmap03.flightgear.org). YAY!! :D :D :D
fg101
Can be seen as a LH or AF
fg101
 
Posts: 11
Joined: Mon Apr 30, 2018 6:56 am
Location: Bangalore, India
Callsign: fg101
Version: 2018.1.1
OS: Windows 7

Re: EDDF-Triangle

Postby wkitty42 » Thu Jun 07, 2018 4:03 pm

AAL545 wrote in Thu Jun 07, 2018 1:35 am:
hopefully everyone is also using 2018.2.1 at least.


Why do you say that, unless it'll improve our situation here?

since it contains bug fixes to the MP protocol, of course it will improve the MP data transfer situation... especially now with FG doing more releases a year specifically to get bugs fixed sooner and new features into testing...

AAL545 wrote in Thu Jun 07, 2018 1:35 am:Regarding aircraft, what I have noticed is if I install older or newer aircraft in a home folder that's the model FG will be using,
if I install it in the hidden home folder /user/.fgfs/Aircraft/org.flightgear.fgaddon/Aircraft it will update to the FG database.
Can you comment regarding installing via these two options?

quite simply, do not install custom scenery or craft to the system default directories... custom scenery and craft should be installed to their own directory tree and FG pointed there... this prevents the base FG installation from being polluted and keeps your custom craft and scenery separate from FG proper... that makes it easy to remove them if needed at some point...

in the case of scenery and using terrasync, the system will remove those files that are not on the official server and will download replacements for files that are on the official server but do not match... in the case of craft, i'm not sure how the launcher will handle that but it could easily mess things up if you are placing manually downloaded craft into the hanger space managed by the launcher's hanger management code... i don't think craft management code is quite as robust as the scenery management code so there's no telling what might happen if you change files behind its back...

in either case of installing custom scenery or craft, the paths added to fg-scenery and fg-aircraft need to be in the proper order so that both/all will be found as needed... for example, i have two c172p craft... the first one is the official default one in FGDATA... the second one is my local copy of the c172p development repository which is stored in my custom craft directory, ~/myflightgear/Aircraft/c172p... i point fg-aircraft to home/myuser/myflightgear/Aircraft and it locates all craft in there... i can easily choose either one of the c172p craft from the launcher to fly and neither one affects the other... there is only one possibility of interference between the two and that is the case of the saved craft configuration data in ./fgfs/aircraft-data since the saved data files have the same name but no craft version number to differentiate between craft of the same name but different versions which may have different options that can be saved... in those cases, simply deleting the craft's saved data in aircraft-data and restarting should fix the problem... of course the craft has to be reconfigured again but that's not a big deal... reconfigured as in choosing which engines, landing gear, livery and other craft-provided customization options...

AAL545 wrote in Thu Jun 07, 2018 1:35 am:I guess what I am getting at and I have commented on this, FG should be a 100% integrated system and we break the link if we/I download aircraft
that aren't 100% up to snuff with the FG program. Sure you can fly the aircraft but will issues.

correct...
Last edited by wkitty42 on Thu Jun 07, 2018 4:07 pm, edited 1 time in total.
"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: 5428
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 wkitty42 » Thu Jun 07, 2018 4:06 pm

fg101 wrote in Thu Jun 07, 2018 6:05 am:MP Map 03 is up and running (mpmap03.flightgear.org). YAY!! :D :D :D

yes it is but let's not beat it to death by sitting on it all day and chewing up its allocated transfer bandwidth... that's what happened before and it was shutdown automatically because its allocated bandwidth budget ran out... that server is running on a hosting service and it is not cheap... donations are gladly accepted and welcome... there is a donation button on that page, now ;)

NOTE: i am not the operator of that server... i'm just passing the work along...
"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: 5428
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 jomo » Fri Jun 08, 2018 3:39 pm

I tried to upgrade my Installation to FGFS 2018.2.2 (on UBUNTU version 2018.04) on last Wednesday - and killed my PC trying to fix that hanging installation - obviously not only I had troubles - because that 2018.2.2 (Ubuntu) is not available any more as of today. So today I did build up my PC completely new with FGFS 2018.2.1 ( available since 6 days !!!). The ORCAM-model of course is not changed since 4.Jan2014 -- and still working great as was proven the last weeks!!

So: Whoever wants may test his models tonight at EDDF-Triangle - but do not expect me ever again to just install new versions as soon as available!! I will not - I will have some time to be sure that new stuff works! See contradicting:
AAL545 wrote in Thu Jun 07, 2018 1:35 am:I guess what I am getting at and I have commented on this, FG should be a 100% integrated system and we break the link if we/I download aircraft that aren't 100% up to snuff with the FG program. Sure you can fly the aircraft but will issues.

I guess we should not start dreaming! There is something special about FGFS:
    FGFS is based on the free will of many many designers - that work for free --> no pay - no central design Office/Budget --> thus you do not have to pay for it - but you have a lot of very eager "nonProfessionals" doing the work. But they do have an immense task designing all this AND providing it for all available OperatingSystem! So not all Operating-System might be available at same time --> I still like that - because i do not like paying!

    If you do not like that you might be interested in Microsoft - they have a lot of highly payed professionals in a real designing environment -- but that Microsoft version cost a lot of money - and still has lots of problems --> so I rather switched to FGFS

I guess we should not expect too much of our "free designers" -- but should take some care: If using new stuff, make sure you test it OK prior to deleting the stuff that proved to work!
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: 897
Joined: Thu Feb 12, 2009 6:46 pm
Location: Mainz, Germany
Callsign: jomo jomoATC
OS: UBUNTU 18.4

PreviousNext

Return to Multiplayer events

Who is online

Users browsing this forum: No registered users and 1 guest