Re: [Flightgear-devel] multiplay refuel test
Hi, NOTAM: Refueling CLOSED, temporarily at least... Ok, have finished for now my refueling sorties. As I put in the chat after one pilot reported holding a position for refueling can be quite tiring - Yes, so can even watching it ;=)) It all certainly confirmed that some FG code changes are needed to make this experience viable... like removing, or reducing the rubber-band effect, and compensating for lag which makes the view from the tanker different to the view from the aircraft. Additionally, there is NO collision detection code between the aircraft and the mp derived models, so this means even when you get the probe into the basket, if you push forward a few more feet, and the basket/drogue will enter your cockpit ;=)) But I had lots of fun, and I hope the others that joined me did also ;=)) As to the virtual bottle of red wine, I think that must go to callsign jano, who held steady very close, or touching! proximity for the longest period of time in the lightning (jsb). http://www.flightgear.org/forums/viewtopic.php?f=19t=19756#p181737 I chose a Chateau Petrus 1982, and the 'virtual' bottle is here - http://en.wikipedia.org/wiki/File:Petrus1982.jpg It is under a GFLD licence, which I understand is GPL compatible ;=)) jano later tried to repeat the feat in an f-14b (yasim), but while holding a similar relatively close position, the aircraft always looked quite 'jumpy'... maybe something to do with the different FDM? An honorable mention must go to F-JJTH who posted an image with the probe in the basket, followed by one with the basket in the cockpit ;=)) http://www.flightgear.org/forums/viewtopic.php?f=19t=19756#p181749 As per some others if you scroll down... I have now put up a page on my site with the images I took - http://geoffair.org/fg/mp I left all the images at full screen shot size, so they can take a little time to download... But a BIG thank you to ALL who came along for the ride... As stated, it was great, if not exhausting!, FUN! Regards, Geoff. -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplay refuel test
Hi Jano, Thanks for the video links... these were great... So far I have had 5 others, aside from myself, trying to get to touch the R or L drogue, and while some got quite close and were able to maintain a close position, several factors came into play which made it difficult, if not impossible... The tanker used is the 'victor', probe-drogue type, flown on autopilot at 12000 feet (STD 29.92), 220 knots on either 180 from Paris LFPY, or 360 on the return. I usually turn N shortly after Toulouse in the south... So far, as the other aircraft, have had Citation-II, Mirage_F1, m2000, f16, and ???... A big thank you to them for joining in and trying... And I understand some screen shots were posted on the PAF forum, but still to find these... a link would help... I also tried with a 2nd victor, running in a 2nd machine... Oh, and I always use mpserver14.flightgear.org, Switzerland, and perhaps attempts while using the SAME fgms server may be better... but still saw the following assumed due to 'lag' problem when flying victor to victor where this is the closest you can see the following plane, but in fact he see itself very close to the drogue This difference between whether you are looking from the aircraft to the tanker, or from the tanker to the aircraft is certainly ONE of the problems. Usually the tanker will see the aircraft still back some 10s of meters behind the drogue, while the pilots sees the drogue up very close, perhaps even touching... And assume it can be the reverse of this... http://wiki.flightgear.org/Mp-patch Have downloaded and am looking at your wiki lag patches with an aim to patch my 2.11... in Windows 7 and Ubuntu... but not sure how far I will get... It would certainly be nice if both pilots saw the same scene ;=)) But this is not the ONLY problem... basically the mp sending rate is fine with 10 pps Well yes if the packets flow, but many things do seem to interrupt that flow... One of the biggest is F3 - take a screen shot - This seems to stop packets for a seconds or more... Loading a new scenery tile can be another... new weather metar, although in the victor I usually select simple Fair weather... but there seems to be a number of things that 'change' the packet flow... I even suspect mp chat causes small blips... There is already some form of predictive code in 2.11, but this to not yet very accurate or successful, but seems a very good start... If the aircraft IS maintaining close proximity to the drogue, and I press F3 in the tanker, the tanker seems to slide forward faster and further than it should! So the aircraft pilot sees the tanker quickly move away... accelerate and moves forward... quite un-nerving... And this can happen even without a heavy F3 event... perhaps even due to system thread changes, ie nothing to do with the running fgfs... Now if [s]he does nothing but hold, usually things will settle back into close proximity, but the pilot has LOST some visual clues aiding to maintain position so by the time things resettle [s]he is no longer so near the drogue ;=(( So I must take another look at this fill-in code, and would like to hear from the person or persons who implemented it... and understand why the very apparent slide fast forward, and what controls how quickly the position returns to that of the current packets after such an artificial change... any README, links, etc... And then there is how will your 'lag' correction effect this current extrapolation code? If at all... So lots of things to explore here ;=() Over the coming days I will try to maintain my victor tanker runs... but it too can be quite stressful even just watching and chatting... Maybe later try an E-W run, since you do mention some differences depending on direction... So still invite others to try, but they should read and understand the above - it is difficult if not impossible - so expect more of the same frustrating efforts until some more CODE changes can be put in place... As one trier sort of put it - it is like the tanker has some 'shield' around it... things are good while you close in, but at very close proximity all HELL breaks loose ;=)) Have FUN! Regards, Geoff. On Thu, 2013-04-18 at 08:18 +0200, jean wrote: Hi Geoff i guess you are seing something like that: http://www.youtube.com/watch?v=VWn6_RFp97Y where this is the closest you can see the following plane, but in fact he see itself very close to the drogue and what you want is like this: http://www.youtube.com/watch?v=kGHRDrc_n98 you should have a look at this page, wip but working fine for the few pilots testing it : http://wiki.flightgear.org/Mp-patch basically the mp sending rate is fine with 10 pps, but you need a way to compensate for the lag. I can't try a refuel with you before this WE, but i will if you are still flying the victor somewhere. jano NOTAM: To flyers who fly 'probe'
Re: [Flightgear-devel] multiplay refuel test
hi Geoff , And I understand some screen shots were posted on the PAF forum, but still to find these... a link would help... http://equipe-flightgear.forumactif.com/t1096p15-vol-en-formation-avec-un-fg-patche#20638 Oh, and I always use mpserver14.flightgear.org, Switzerland, and perhaps attempts while using the SAME fgms server may be better... yep, that's the rule we are following during our formation flight: to be on the same mpserver. Being on different servers give more jitter and lag, and there's no way to compensate for the inter-server lag now, as we have no information about them. http://wiki.flightgear.org/Mp-patch Have downloaded and am looking at your wiki lag patches with an aim to patch my 2.11... in Windows 7 and Ubuntu... but not sure how far I will get... good luck :) , for your information, a patched 2.11 windows binary is available and updated once a week, if you can't compile it yourself, see detail on the wiki. It would certainly be nice if both pilots saw the same scene ;=)) But this is not the ONLY problem... basically the mp sending rate is fine with 10 pps Well yes if the packets flow, but many things do seem to interrupt that flow... One of the biggest is F3 - take a screen shot - This seems to stop packets for a seconds or more... i never use F3 for screenshots, as it freeze fg , instead i use the os printshot feature, much better and harmless (and it has the antialiasing from the gpu) Loading a new scenery tile can be another... new weather metar, although in the victor I usually select simple Fair weather... but there seems to be a number of things that 'change' the packet flow... I even suspect mp chat causes small blips... those are not change in paquet flow, but 'freeze' in FG itself, when some frame take time to render, being stuck on a model loading, or a metar change, or a F3 etc To avoid mipmap generation hang, I use dds texture for all the planes in my aircraft folder (with a script), the mipmap are not generated on the fly and the loading is faster (taking less space in ram too). that's why in the paf hangar we are providing both a .png and a .dds version of the planes. So the aircraft pilot sees the tanker quickly move away... accelerate and moves forward... quite un-nerving... And this can happen even without a heavy F3 event... perhaps even due to system thread changes, ie nothing to do with the running fgfs... we call this the rubber band phenomen :D, mainly caused by jitter, and worse if we are not on the same server. So I must take another look at this fill-in code, and would like to hear from the person or persons who implemented it... and understand why the very apparent slide fast forward, and what controls how quickly the position returns to that of the current packets after such an artificial change... any README, links, etc... the current code in AIMultiplayer.cxx got a prediction system, but try to nether use it. this is done to have only an interpolation between two packets to do. so we display the mp plane at least one packet late to have a margin. And then there is how will your 'lag' correction effect this current extrapolation code? If at all... I reused the existing code, with some modifications wich are: - very slow response to jitter: the rubber band phenomen is just a little noticeable, seen as a speed variation of the followed plane. - i'm sending and using planes's accelerations (only for yasim and jsbsim yet), so the position is predicted using position, speed and acceleration with a basic equation. If some are interested i can detail a little more this on the wiki page. if you are using the patch, be aware that non patched yasim planes transmit a velocity in airmass instead of ecef, so they are very shaky if displayed in the futur with some wind. Maybe later try an E-W run, since you do mention some differences depending on direction... this is an effect of the patch with jsbsim aircraft, i needed to find an acceleration suitable, so i added one in jsbsim, but aparently this is not perfect yet, but at 10 pps, it nearly unnoticeable. I guess this should be a jsbsim expert job :) jano -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplay refuel test
Hi Geoff i guess you are seing something like that: http://www.youtube.com/watch?v=VWn6_RFp97Y where this is the closest you can see the following plane, but in fact he see itself very close to the drogue and what you want is like this: http://www.youtube.com/watch?v=kGHRDrc_n98 you should have a look at this page, wip but working fine for the few pilots testing it : http://wiki.flightgear.org/Mp-patch basically the mp sending rate is fine with 10 pps, but you need a way to compensate for the lag. I can't try a refuel with you before this WE, but i will if you are still flying the victor somewhere. jano NOTAM: To flyers who fly 'probe' enabled aircraft in Europe... or even if NOT... I will be flying the 'victor' refueling tanker for the next few days from KFPY, south 180 track, then turn around at the southern mountains, north on 360, at 12,000 feet – FL120 STD QNA – and am interested in 'hot' flyers who want to try air-to-air REFUELING (AAR) in suitably equiped aircraft, well ANY aircraft... The tanker will maintain, under autopilot, 220 knots (KTAS), at the said 12,000 feet, either 180 or 360, under the callsign GA006. The flights will commence about noon, or before, UTC, and close about 20:00 UTC. The track can be followed using http://test.fgx.ch, or other mp map URLS. Click on 'GA006' to localize... Reason: (a) I have tried with several aircraft over the last few days, and learned that this is QUITE difficult, but I hope NOT impossible! (b) The present suggested pps (Hz) is 10 when you set up –multiplay=, but FG 2.11 has fill-in extrapolation code when fgfs packets do not arrive in time, so maybe this is too high. This is the basic question... So the idea is to reduce this IFF this fill-in code helps, ie does its job... The theoretic idea is that with this code we can reduce the bandwidth used by 10 Hz to perhaps 2-4 Hz, but this needs to be FULLY tested, and confirmed... Now I have tried this over several day, in several aircraft – A-10, f-14b, a4 and failed, FAILED to touch the trailing drogues... it is TOUGH... autopilots help you get to the 'zone' but it needs manual flying to get to the RIGHT PLACE... If you are using a joystick maybe you need to even adjust the dead spot and the 'sensitivity' of the inputs... lots of learning, understanding and doing fgdata xml changes... And I have had a few pilots joining in ad hoc, but so far no one has actually contacted with the trailing outer wing drogues... The 'victor' can refuel 2 aircraft at a time... and I would LOVE to see/capture that... One, french I think, got so frustrated at his attempts, began firing missiles at the tanker. Thankfully, he MISSED, but was CLOSE ;=)) Also if you alert me to your attempt to refuel from my tanker, via mp chat, email, fgcom, … AND I am on board at the time -: (a) I will offer a VIRTUAL bottle of good Bordeau rouge to the first pilot who maintains drogue contact for say a minute, or more ;=)) (b) I will take some screen shots and post them. Be warned, during a screen shots (F3), fgfs stops sending mp packets for up to a second or so, and in the close fgfs the fill-in (extrapolation) code is activated, with some interesting, and sometimes quite alarming effects... Also I have heard others mention that the live metar update can also cause mp packet delays. The tanker will be flying under the 'Fair weather' scenario to avoid this. Maybe you should choose this as well... I really seek help from other pilots to analyse this multiplayer bandwidth situation. We have chosen 10 Hz, but WHY? Can less than 10 Hz be used with no adverse effect? That is the BIG question... Simply, what really is the optimum packets-per-second (pps) rate? Maybe it changes depending on circumstances... We know the lower the Hz the lower the bandwidth used by FGMS servers... but can the extrapolation code fill-in for the missing packets? Is 10 Hz good? Should it be higher, or lower depending on circumstance.. Lots to learn... Of course I am sure there are OTHER ideas... Hope you can help, and have some FUN at the same time;=)). Look forward to seeing you on my rear view... and I will take some pics... Regards, Geoff. CC: to users list... BCC: to others... -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] multiplay refuel test
NOTAM: To flyers who fly 'probe' enabled aircraft in Europe... or even if NOT... I will be flying the 'victor' refueling tanker for the next few days from KFPY, south 180 track, then turn around at the southern mountains, north on 360, at 12,000 feet – FL120 STD QNA – and am interested in 'hot' flyers who want to try air-to-air REFUELING (AAR) in suitably equiped aircraft, well ANY aircraft... The tanker will maintain, under autopilot, 220 knots (KTAS), at the said 12,000 feet, either 180 or 360, under the callsign GA006. The flights will commence about noon, or before, UTC, and close about 20:00 UTC. The track can be followed using http://test.fgx.ch, or other mp map URLS. Click on 'GA006' to localize... Reason: (a) I have tried with several aircraft over the last few days, and learned that this is QUITE difficult, but I hope NOT impossible! (b) The present suggested pps (Hz) is 10 when you set up –multiplay=, but FG 2.11 has fill-in extrapolation code when fgfs packets do not arrive in time, so maybe this is too high. This is the basic question... So the idea is to reduce this IFF this fill-in code helps, ie does its job... The theoretic idea is that with this code we can reduce the bandwidth used by 10 Hz to perhaps 2-4 Hz, but this needs to be FULLY tested, and confirmed... Now I have tried this over several day, in several aircraft – A-10, f-14b, a4 and failed, FAILED to touch the trailing drogues... it is TOUGH... autopilots help you get to the 'zone' but it needs manual flying to get to the RIGHT PLACE... If you are using a joystick maybe you need to even adjust the dead spot and the 'sensitivity' of the inputs... lots of learning, understanding and doing fgdata xml changes... And I have had a few pilots joining in ad hoc, but so far no one has actually contacted with the trailing outer wing drogues... The 'victor' can refuel 2 aircraft at a time... and I would LOVE to see/capture that... One, french I think, got so frustrated at his attempts, began firing missiles at the tanker. Thankfully, he MISSED, but was CLOSE ;=)) Also if you alert me to your attempt to refuel from my tanker, via mp chat, email, fgcom, … AND I am on board at the time -: (a) I will offer a VIRTUAL bottle of good Bordeau rouge to the first pilot who maintains drogue contact for say a minute, or more ;=)) (b) I will take some screen shots and post them. Be warned, during a screen shots (F3), fgfs stops sending mp packets for up to a second or so, and in the close fgfs the fill-in (extrapolation) code is activated, with some interesting, and sometimes quite alarming effects... Also I have heard others mention that the live metar update can also cause mp packet delays. The tanker will be flying under the 'Fair weather' scenario to avoid this. Maybe you should choose this as well... I really seek help from other pilots to analyse this multiplayer bandwidth situation. We have chosen 10 Hz, but WHY? Can less than 10 Hz be used with no adverse effect? That is the BIG question... Simply, what really is the optimum packets-per-second (pps) rate? Maybe it changes depending on circumstances... We know the lower the Hz the lower the bandwidth used by FGMS servers... but can the extrapolation code fill-in for the missing packets? Is 10 Hz good? Should it be higher, or lower depending on circumstance.. Lots to learn... Of course I am sure there are OTHER ideas... Hope you can help, and have some FUN at the same time;=)). Look forward to seeing you on my rear view... and I will take some pics... Regards, Geoff. CC: to users list... BCC: to others... -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
