Re: [Flightgear-devel] NAV display proof-of-concept
An unrelated question for you - I'm using the B1900d to test my GPS > changes, since it has the best GPS setup that I can find - I'm a > little surprised by the way CDI deviation is handled - I was led to > believe that in normal VOR mode, one 'dot' of CDI deviation usually > corresponded to 1nm, but in the B1900d, one dot seems to correspond to > 2.5nm (full deviation being 5nm). Is this intentional? > Ok , I did some test flights , now I see what you mean With the EFS 40/50 the deviation scale units depend on the navigation source: VOR/TAC 1 dot = 5 degrees ADF 7.5 degrees LNAV or RNAV 2.5 NM LNAV/RNAV appr 0.625 NM GPS ENROUTE 2.5NM GPS TERMINAL 0.5 NM GPS APPROACH0.15 NM Hope that helps , I'm going over the animations again to see if I got the scale right. Cheers -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On 12/17/2008 08:04 PM, Csaba Halász wrote: > I assume you are not using sync-to-vblank or fps throttle. That's a correct assumption. Forsooth, I've never heard of sync-to-vblank or fps throttle in this context. The names sound nice, but -- They are not mentioned in --help --verbose -- They do not appear in the drop-down menus AFAICT. -- They do not appear in the getstart manual or in any of the plain-text documents in data/Docs AFAICT. I mention this because I'm trying to test things from the user's point of view. If these features are going to be important to users, it would be useful to put them where users can find them. Or ... maybe turn them on by default. Recomputing the image at a rate that exceeds the refresh rate of the display seems kinda pointless, unless I'm overlooking something. >> 44:: Memory hog: When the sim is paused, if you leave it alone for 15 >> minutes or so, it starts eating virtual memory at the rate of several >> megabytes per minute. > Are you on multiplayer by any chance? This issue should be investigated. Not on multiplayer. No funny options. All I did was fire up fgfs, pause it, and go out to dinner. As I said at the top of this thread, I haven't had time to give rc2 a thorough workout. I'm just reporting bugs that leap out at me when I try to use some of the basic features. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On Thu, Dec 18, 2008 at 3:04 AM, John Denker wrote: > > 43:: CPU hog: When the sim is paused, it eats CPU cycles. It will > happily use 99+% of the CPU if there is no competition. I don't > understand why any appreciable CPU cycles are needed during pause. I assume you are not using sync-to-vblank or fps throttle. Those would keep resource usage limited. I don't think any further optimization for the paused state is worthwhile. > 44:: Memory hog: When the sim is paused, if you leave it alone for 15 > minutes or so, it starts eating virtual memory at the rate of several > megabytes per minute. ... > These observations lead me to conjecture that some > type of events or messages are getting backlogged during pause, but > are belatedly processed when the pause ends, thereby freeing up some > space on the free list. Are you on multiplayer by any chance? This issue should be investigated. -- Csaba/Jester -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
43:: CPU hog: When the sim is paused, it eats CPU cycles. It will happily use 99+% of the CPU if there is no competition. I don't understand why any appreciable CPU cycles are needed during pause. 44:: Memory hog: When the sim is paused, if you leave it alone for 15 minutes or so, it starts eating virtual memory at the rate of several megabytes per minute. That's a lot. I'm talking about the "VIRT" quantity reported by top(1) ... in contrast to ps(1) which does not make the problem quite so obvious. I conjecture that the reason for the delay is that the sim has a certain amount of memory already availble on its free list, and the memory hog has to chew through that before new memory needs to be requested from the VM system. I observe that if the simulator is un-paused, virtual memory size increases for a while, then levels out. I also observe that after an un-pause, it takes another 15 minutes of pause before obvious memory eating resumes. These observations lead me to conjecture that some type of events or messages are getting backlogged during pause, but are belatedly processed when the pause ends, thereby freeing up some space on the free list. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV display proof-of-concept
James Turner wrote: > On 17 Dec 2008, at 20:28, Syd wrote: > > >> Just a request while your tweaking the route-manager , I'll keep my >> fingers out of it :) >> I use it as an FMS for my aircraft with such instruments , but what >> would be convenient is a property to flag when the TTG switches from >> hours to minutes ... >> > > Please keep the requests coming! > > Actually what I've done is make the route-manager an abstract thing, > it will gradually evolve to deal with 'flight plans' and hence drive > ATC in the distant future. > > For FMS functionality, I'm extending the GPS code, so wherever I say/ > write GPS, you can read FMS as well. I'm aware that's a somewhat broad > definition, but internally it makes a lot of sense, since there is so > much overlap. > > So, the route-manager no longer computes TTG at all - that > functionality has been moved to the GPS code, which always reports a > particular format (hh:mm:ss). I realise that's not flexible, so I will > probably do two things: make the raw seconds available as a double, > and allow the string to be specified via a format string in the > config/ properties sections of the GPS. > > Does this seem reasonable? > > Sounds reasonable. > An unrelated question for you - I'm using the B1900d to test my GPS > changes, since it has the best GPS setup that I can find - I'm a > little surprised by the way CDI deviation is handled - I was led to > believe that in normal VOR mode, one 'dot' of CDI deviation usually > corresponded to 1nm, but in the B1900d, one dot seems to correspond to > 2.5nm (full deviation being 5nm). Is this intentional? > > On the gps display , the default scale is 5nm full deviation,in approach arm mode 1 nm full, but I didnt animate that ... there are still dozens of pages that need done yet. Ive been tempted to switch to the kln89 instead of trying to do this with nasal ... I might have scaled the instrument needles wrong , I'll double check tonight. > Oh, and another thing - I'm proposing to make the 'slaved-to-gps' flag > of the navradio actually work, so that the GPS code will read OBS from > the nav gauge, and output CDI deflection back to it. I.e simulate the > 'wiring' that is normally done using property copies inside the GPS > code (when the GPS/NAV switch is in the GPS position). I think / hope > this would make installation in many aircraft easier, and make the > set_course / update_course logic in the B1900d flightdirector.nas > unnecessary - am I right or not? > > Yes it would be nice to get rid of the unneccesary calculations in nasal. > James > > > -- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV display proof-of-concept
On 17 Dec 2008, at 20:28, Syd wrote: > Just a request while your tweaking the route-manager , I'll keep my > fingers out of it :) > I use it as an FMS for my aircraft with such instruments , but what > would be convenient is a property to flag when the TTG switches from > hours to minutes ... Please keep the requests coming! Actually what I've done is make the route-manager an abstract thing, it will gradually evolve to deal with 'flight plans' and hence drive ATC in the distant future. For FMS functionality, I'm extending the GPS code, so wherever I say/ write GPS, you can read FMS as well. I'm aware that's a somewhat broad definition, but internally it makes a lot of sense, since there is so much overlap. So, the route-manager no longer computes TTG at all - that functionality has been moved to the GPS code, which always reports a particular format (hh:mm:ss). I realise that's not flexible, so I will probably do two things: make the raw seconds available as a double, and allow the string to be specified via a format string in the config/ properties sections of the GPS. Does this seem reasonable? An unrelated question for you - I'm using the B1900d to test my GPS changes, since it has the best GPS setup that I can find - I'm a little surprised by the way CDI deviation is handled - I was led to believe that in normal VOR mode, one 'dot' of CDI deviation usually corresponded to 1nm, but in the B1900d, one dot seems to correspond to 2.5nm (full deviation being 5nm). Is this intentional? Oh, and another thing - I'm proposing to make the 'slaved-to-gps' flag of the navradio actually work, so that the GPS code will read OBS from the nav gauge, and output CDI deflection back to it. I.e simulate the 'wiring' that is normally done using property copies inside the GPS code (when the GPS/NAV switch is in the GPS position). I think / hope this would make installation in many aircraft easier, and make the set_course / update_course logic in the B1900d flightdirector.nas unnecessary - am I right or not? James -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On mercredi 17 décembre 2008, Frederic Bouvier wrote: > - "gerard robin" a écrit : > > On mercredi 17 décembre 2008, Frederic Bouvier wrote: > > > - "gerard robin" a écrit : > > > > On mardi 16 décembre 2008, Durk Talsma wrote: > > > > > Hi Fred, > > > > > > > > > > On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote: > > > > > > I replied that the target is next Friday. After that I may > > > > have > > > > > > > > difficulties to build a binary from where I will be. > > > > > > > > > > > > -Fred > > > > > > > > > > How would your availability be after Friday. As it turns out, I > > > > have > > > > > > a > > > > > > > > > Christmas dinner this Friday, so I won't be able assemble the > > > > final > > > > > > release > > > > > > > > > by then. Saturday will be fine for me, so I hope to roll up the > > > > > > > > release > > > > > > > > > then. > > > > > > > > > > Cheers, > > > > > Durk > > > > > > > > Hello, Durk > > > > > > > > How do you schedule the period test with OSG 2.8 before rolling > > > > up > > > > > > the > > > > release ? > > > > OR do you avoid any test with it ? > > > > > > A lot of people are already using OSG/SVN. So tests are going on > > > > under the > > > > > hood. > > > > > > -Fred > > > > Sorry for that question which seems to annoy everybody. > > I agree, the question was not realistic and not constructive, it was > > stupid. > > I am glad to know that there is a LOT of persons testing it. > > > > :) :) > > > > Merry Christmas :) > > See you next year. > > Is it me or are you implying you are the only one to care, and there are > nobody at the moment committing patches and building binaries for the > community ? > > Anyway merry christmas. > > -Fred Fred, I only apologized regarding my question (a stupid question which got, from you, the suitable answer). I know, that, the effort i did, to get the right computer/configuration in order to build FG with OSG 2.75, and the feedback that i gave about the new 3D Clouds with Metar, was not useful. In anycase less useful than your contributions, like you suggested. Anyhow, i am leaving out, from any computer until next year. Greetings to everybody -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Ok, this might be a silly question but here it goes, Will the final 1.99 release be on the main flightgear website and replace 1.0 on the site? Thanks -- Michael Smith (mdsmith2) -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] (no subject)
Stuart Buchanan wrote: > Attached is a very small patch that fixes the issue reported by > Martin where --prop:/environment/weather-scenario=METAR had no > effect. Oh, great ! thanks a lot, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
* Melchior FRANZ -- Wednesday 17 December 2008: > [...] 0.95 (or something like that) Err ... 1.95 > Before we drop the 0.9* idea, [...] and 1.9*. But I guess you got the idea. :-) m. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
* Durk Talsma -- Wednesday 17 December 2008: > would it be an idea to release this version as 2.0?. I'm against that. fgfs is in acceptable shape for a minor release, but it would be an embarrassment for a major release. Curt says he doesn't care about version numbers, but the "community" certainly does. 2.0 sounds like a big(ger) step forward, and at the moment I don't see that. Just teleport or reset and you are likely to run into your terminal being flooded with NaN messages, from which you can only escape by aborting. That doesn't sound like 2.0 material, and I don't think it will be fixed by the weekend. Rushing out releases is never a good idea, but it's especially bad for a major "symbolic" release. 0.95 (or something like that) would be OK -- as a kind of preview for the "big release". Before we drop the 0.9* idea, I'd rather defer the release a few months. If we don't want that release numbers imply anything other than "next step", then we have to just number them 1..infinity or label them with their release date, without "major", "minor" numbers. Otherwise there *is* a meaning to about anyone, whether we like it or not. m. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
A couple more six-legged crawly things: 41:: c172p: As of rc2, if the pilot is tall or if the pilot's seat is cranked up high, a weird artifact appears in the field of view. To demonstrate this, use the property viewer to set /sim/current-view/y-offset-m to 0.4 (instead of the default value of 0.3). I don't know what this artifact is or where it came from. Perhaps it is a misplaced scrap of upholstery. I'm pretty sure it can be deleted with no regrets. 42:: Instrument: KAP-140: As of rc2, as installed in the c172p and presumably others, on initial startup the display of the Sim World KAP-140 is blank. This is already a bug, because the display of the Real World KAP-140 is never blank (unless you pull the circuit breaker, which is not relevant to the present discussion). In particular, the altitude alerter function is always active and cannot be turned off, even in the rather common case where the auto-bank and auto-pitch functions are on standby. In this case, the RW KAP-140 displays the target altitude. It would be nice if the SW KAP-140 did the same. The nightmare scenario for the noobie pilot is taking off from an airport situated above 1000 MSL and flying to an airport at 950 MSL. Since the "default" target altitude is zero, there will be an alert on short final at 1000 MSL == 50 feet AGL. Unexpected beeping warnings at 50 feet AGL are not a good thing. We note in passing that the instructions at http://wiki.flightgear.org/index.php?title=Bendix/King_KAP140_Autopilot do not even mention the alerter. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
> > There are still problems with the clouds (the draw order > problem with > particles), and Tim has already mentioned his intention to > start > committing the code required for shadows after this > release. I believe > that code also makes landing lights a possibility. I'd > be tempted to > make the first release including both of those features 2.0 > > Jon > I agree! I'm pretty fine with 1.99.5 - with these announces by Tim with shadows, light sources, the improvements by Yon we really should wait. I can remember that we wnated to have 1.0.0 when we have landing lights. So this time we should really name it 2.0.0 when we have back the shadows and maybe the landinglights. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Durk Talsma wrote: > Just to make a blunt suggestion, although not completely of my own > imagination: would it be an idea to release this version as 2.0?. Initially, > we wanted to do a 1.9.0 release, because we felt that the OSG transition > wasn't quite there yet. Since then, enormous progress has been made, in > particular in the 3D clouds departments. So given this unexpected progress, > would labeling this release as 2.0 be a viable option? I know that Curt's > been in favor of calling this release 2.0. I initially was a bit more > reluctant, but given the enormous progress, I have to say I'd be open to the > suggestion. > > I agree with Tat that we need to think of a good versioning system for future > releases. There are still problems with the clouds (the draw order problem with particles), and Tim has already mentioned his intention to start committing the code required for shadows after this release. I believe that code also makes landing lights a possibility. I'd be tempted to make the first release including both of those features 2.0 Jon -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Hi Tat et al., On Tuesday 16 December 2008 18:16:29 Tatsuhiro Nishioka wrote: > Hi guys, > > >> Personally, I think a big build up to an oddball version number like > >> 1.99.5 is a little strange, but again, I'm not so hung up on version > >> numbers as long as they keep increasing. It would also be odd to > >> backtrack since the point of version numbers is to distinguish > >> releases in some logical order. > Just to make a blunt suggestion, although not completely of my own imagination: would it be an idea to release this version as 2.0?. Initially, we wanted to do a 1.9.0 release, because we felt that the OSG transition wasn't quite there yet. Since then, enormous progress has been made, in particular in the 3D clouds departments. So given this unexpected progress, would labeling this release as 2.0 be a viable option? I know that Curt's been in favor of calling this release 2.0. I initially was a bit more reluctant, but given the enormous progress, I have to say I'd be open to the suggestion. I agree with Tat that we need to think of a good versioning system for future releases. Cheers, Durk -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NAV display proof-of-concept
James Turner wrote: > On 9 Dec 2008, at 00:53, Syd wrote: > > >> Looks good so far , Ive been thinking along the same lines for the >> Primus 1000. >> I dont know the specs for that instrument , but the Primus can only >> display a maximum of 4 airports, 4 navaids , etc , which should be >> easier on performance , determining which should be displayed when >> there >> are more might be tricky... but your way ahead of me , so I'll be >> watching your progress :) >> > > Ah, that's good things to know about the Primus. In general, the > reference points I'm working on are the G1000 (which I have a PDF > manual for), the Boeing 747-400 / 777 style displays (ditto), and the > KLN89B (again, have a PDF manual). I'd love to have a reference > describing the Primus, since it seems to be installed in many > aircraft. (I'd also love to have an Airbus ref, to see how different > it is from the Boeing display). > > In general, I'm initially focusing on features and visual appearance, > not accurate modelling of any specific system. I'm hoping to get > something we can hack into many aircraft quickly - all the Boeings and > Airbuses, but also the Primus-equipped aircraft. If people's biggest > complaint is that feature XYZ is not exactly correct for the A330-400 > variant, I will be happy :) > > If you have some spare time, could you add clickable models / hot- > spots for the ND-MCP panel on the 777-200? (and maybe pass the panel > onto Gijs for the 747-400, they seem to be virtually identical). I > could hook up the range and CTR functions now, and I'll be in a > position to do the layer switches in the next few days. I'm hoping to > implement the modes via a Nasal script that configures properties on > the C++ instrument, but I'd like to confirm that's a valid approach. > > Regards, > James > > > -- > SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. > The future of the web can't happen without you. Join us at MIX09 to help > pave the way to the Next Web now. Learn more and register at > http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > Just a request while your tweaking the route-manager , I'll keep my fingers out of it :) I use it as an FMS for my aircraft with such instruments , but what would be convenient is a property to flag when the TTG switches from hours to minutes ... Merry Christmas. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
- "gerard robin" a écrit : > On mercredi 17 décembre 2008, Frederic Bouvier wrote: > > - "gerard robin" a écrit : > > > On mardi 16 décembre 2008, Durk Talsma wrote: > > > > Hi Fred, > > > > > > > > On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote: > > > > > I replied that the target is next Friday. After that I may > have > > > > > difficulties to build a binary from where I will be. > > > > > > > > > > -Fred > > > > > > > > How would your availability be after Friday. As it turns out, I > have > > > > > > a > > > > > > > Christmas dinner this Friday, so I won't be able assemble the > final > > > > > > release > > > > > > > by then. Saturday will be fine for me, so I hope to roll up the > > > > > > release > > > > > > > then. > > > > > > > > Cheers, > > > > Durk > > > > > > Hello, Durk > > > > > > How do you schedule the period test with OSG 2.8 before rolling > up > > > the > > > release ? > > > OR do you avoid any test with it ? > > > > A lot of people are already using OSG/SVN. So tests are going on > under the > > hood. > > > > -Fred > > Sorry for that question which seems to annoy everybody. > I agree, the question was not realistic and not constructive, it was > stupid. > I am glad to know that there is a LOT of persons testing it. > :) :) > > Merry Christmas :) > See you next year. Is it me or are you implying you are the only one to care, and there are nobody at the moment committing patches and building binaries for the community ? Anyway merry christmas. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
Hi Gerard, > Hello, Durk > > How do you schedule the period test with OSG 2.8 before rolling up the > release ? > OR do you avoid any test with it ? > > Cheers As Fred mentioned, I'm routinely building and testing FlightGear against OSG/SVN. I haven't noticed any problems. I have the impression that most developers are doing that, but I could be wrong. Are there any issues that would make it undesirable to build FlightGear against the last stable release of OSG? I have seen some discussion regarding that point, but haven't watched it that closely. Cheers, Durk -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Output communication problem
Hello, I have encounterd a little bit strange thing in Flightgear v1.0.0. I'm implementing I/O communication with Flightgear using native-fdm protocol and TPC sockets. I would like implement following communication. 1. In Matlab - Simulink are computed positions, velocities etc using Simulink aircraft model. These data are consequently sent to FG (set to use external model). 2. Content of internal FG variables is sent back to Matlab to obtain control inputs from /controls/flight variables and other values which are used as inputs of aircraft model. I think it should be possible to implement this, because although when I'm using external model, control internal properties are filled with values from joystick etc. And now I'm getting to the mentioned problem. When I'm using external model in FG, data are received from Matlab and everything works fine. However there is problem sending values in opposite direction (FG to Matlab). I have observed various variables in received FGNetFDM structures and all of them were set to zero during whole simulation, but they should have been assigned nonzero values. I tried to send data from FG with external model using generic protocol and got the same result. I would like to ask whether this behavior is bug or not, and whether is there some way how to work it out. Thank you very much for your help. Jan -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On mercredi 17 décembre 2008, Frederic Bouvier wrote: > - "gerard robin" a écrit : > > On mardi 16 décembre 2008, Durk Talsma wrote: > > > Hi Fred, > > > > > > On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote: > > > > I replied that the target is next Friday. After that I may have > > > > difficulties to build a binary from where I will be. > > > > > > > > -Fred > > > > > > How would your availability be after Friday. As it turns out, I have > > > > a > > > > > Christmas dinner this Friday, so I won't be able assemble the final > > > > release > > > > > by then. Saturday will be fine for me, so I hope to roll up the > > > > release > > > > > then. > > > > > > Cheers, > > > Durk > > > > Hello, Durk > > > > How do you schedule the period test with OSG 2.8 before rolling up > > the > > release ? > > OR do you avoid any test with it ? > > A lot of people are already using OSG/SVN. So tests are going on under the > hood. > > -Fred Sorry for that question which seems to annoy everybody. I agree, the question was not realistic and not constructive, it was stupid. I am glad to know that there is a LOT of persons testing it. :) :) Merry Christmas :) See you next year. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR Patch (was : no subject)
I wrote: > Subject: > > Hi All, > > Attached is a very small patch that fixes the issue reported by Martin where > --prop:/environment/weather-scenario=METAR had no effect. > > I think this is a pretty safe patch that should be included in the release. > > -Stuart Sorry for the lack of subject. -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
Hi All, Attached is a very small patch that fixes the issue reported by Martin where --prop:/environment/weather-scenario=METAR had no effect. I think this is a pretty safe patch that should be included in the release. -Stuart flightgear.patch.gz Description: GNU Zip compressed data -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bug (and fix!)
It seems I introduced a bug in the airports code some time ago, which has gone rather unnoticed, or somehow I escaped the blame for it: in the 'tower' view, where the tower position is explicitly given in apt.dat (most of the larger airports), I was incorrectly treating the tower elevation as ASL, when it's AGL. The fix is one line, but my apt_loader.cxx has Yon's performance patch applied, so I can't easily generate a useful patch. If someone with commit access could verify that the tower heights are indeed silly at, for example, EDDM, change apt_loader.cxx around line 266 to look like: last_tower = SGGeod::fromDegFt(lon, lat, elev + last_apt_elev); instead of last_tower = SGGeod::fromDegFt(lon, lat, elev); And verify that all is well, that would terrific. EDDM is a good test case because the field elevation is 1400ASL - so the tower is a long way below the terrain. At airports with tall towers or close to sea level, (EHAM, EGLL, etc) it won't be so noticeable. Airports without an explicit tower entry compute a position, and use apt_elevation + a hardcoded value (50') for the elevation, so they're fine regardless of this fix. Thanks, James -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
- "gerard robin" a écrit : > On mardi 16 décembre 2008, Durk Talsma wrote: > > Hi Fred, > > > > On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote: > > > I replied that the target is next Friday. After that I may have > > > difficulties to build a binary from where I will be. > > > > > > -Fred > > > > How would your availability be after Friday. As it turns out, I have > a > > Christmas dinner this Friday, so I won't be able assemble the final > release > > by then. Saturday will be fine for me, so I hope to roll up the > release > > then. > > > > Cheers, > > Durk > > > Hello, Durk > > How do you schedule the period test with OSG 2.8 before rolling up > the > release ? > OR do you avoid any test with it ? A lot of people are already using OSG/SVN. So tests are going on under the hood. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] units analysis ... factor label method
On mercredi 17 décembre 2008, John Denker wrote: > On 12/17/2008 12:33 AM, James Turner wrote: > > On 17 Dec 2008, at 01:03, Melchior Franz wrote: > >> + var KT2MPS = 0.51; # knots to m/s > >> + var MPS2KT = 1 / KT2MPS; > >> + > >> var LB2KG = 0.45359237;# pounds to kilogram > >> var KG2LB = 1 / LB2KG; > > > > Personally I think all these constants would be easier to read if they > > were written the same way as the Simgear ones, i.e MPS_TO_KT, NM_TO_M > > and so on. I understand the logic behind using '2' but it makes the > > identifiers rather dense. > > The tradition in the scientific community in recent decades > has been to do neither of the above. The best current > practice is called "unit analysis" or the "factor label > method". > > The essential idea is to consider _units_ as first-class > algebraically-meaningful objects. > > Here are some examples: Given any self-consistent set of > base units (usually SI but not necessarily) we can write: > inch = .0245 * meter; > foot = 12 * inch; > mile = 5280 * foot; > furlong = (1/8) * mile; > minute = 60 * second; > hour = 60 * minute; > day = 24 * hour; > fortnight = 14 * day; > > Then, given that set of units, if you want to express (say) a > velocity that was measured in units of furlongs per fortnight, > you just say so: > v = 1.2345 * furlong / fortnight; [1] > > Equation [1] converts _from_ arbitrary units _to_ base units. > If you want to convert the other way around, you use the > reciprocals of the units. > > The advantages in terms of concision, precision, and clarity > are rather dramatic. > > In this system, you don't need a conversion factor such as > furlong_per_fortnight_2_meter_per_second ... the question > just never comes up, because there are easier ways to do > what needs to be done. BTW: there is a nice stand alone tool that i am using. http://convertall.bellz.org/ You may notice the units.dat file which is using that "scientific" notation Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal globals.nas, 1.42, 1.43
On 17 Dec 2008, at 15:44, Syd wrote: > I dont know if this makes sense to anyone else , but to me the first > version is a word , the second option is a sentence :) Agreed completely - the issue is, I think of all these things as sentences (well, phrases, anyway) - so I find FOO2BAR rather like reading German :) (not that German isn't a wonderful language, except when spoken by me, as people may discover at LinuxTag) This mostly stems from my background in Cocoa development, where allMethodsHaveNamesLikeThis - very 'sentancy' as Syd would say. But, let's not worry about this anymore, it looks like opinion is to stick with what is used at present, and that's less work as well. James -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] units analysis ... factor label method
On 12/17/2008 12:33 AM, James Turner wrote: > On 17 Dec 2008, at 01:03, Melchior Franz wrote: > >> + var KT2MPS = 0.51; # knots to m/s >> + var MPS2KT = 1 / KT2MPS; >> + >> var LB2KG = 0.45359237;# pounds to kilogram >> var KG2LB = 1 / LB2KG; > > Personally I think all these constants would be easier to read if they > were written the same way as the Simgear ones, i.e MPS_TO_KT, NM_TO_M > and so on. I understand the logic behind using '2' but it makes the > identifiers rather dense. The tradition in the scientific community in recent decades has been to do neither of the above. The best current practice is called "unit analysis" or the "factor label method". The essential idea is to consider _units_ as first-class algebraically-meaningful objects. Here are some examples: Given any self-consistent set of base units (usually SI but not necessarily) we can write: inch = .0245 * meter; foot = 12 * inch; mile = 5280 * foot; furlong = (1/8) * mile; minute = 60 * second; hour = 60 * minute; day = 24 * hour; fortnight = 14 * day; Then, given that set of units, if you want to express (say) a velocity that was measured in units of furlongs per fortnight, you just say so: v = 1.2345 * furlong / fortnight; [1] Equation [1] converts _from_ arbitrary units _to_ base units. If you want to convert the other way around, you use the reciprocals of the units. The advantages in terms of concision, precision, and clarity are rather dramatic. In this system, you don't need a conversion factor such as furlong_per_fortnight_2_meter_per_second ... the question just never comes up, because there are easier ways to do what needs to be done. -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal globals.nas, 1.42, 1.43
Melchior FRANZ wrote: > * James Turner -- Wednesday 17 December 2008: > >>> + var KT2MPS = 0.51; # knots to m/s >>> > > >> Personally I think all these constants would be easier to >> read if they were written the same way as the Simgear ones, >> i.e MPS_TO_KT, NM_TO_M and so on. >> > > I find them equally easy to read and decided to use the way > that YASim uses (from the same author as Nasal, as you probably > know). See ./src/FDM/YASim/FGFDM.cpp. I only made the DEG2RAD > even shorter (which might indeed have been a mistake). But you > can easily do something like this in your Nasal code (once there > is something like "your Nasal code", that is ;-): > > var MPS_TO_KT = MPS2KT; > > What do other Nasal developers think? I'm willing to change > it if others have problems with that, too. (And to change all > occurrences in the repository.) > I prefer the KT2MPS version myself ... no difficulty in understanding what they mean either way. I dont know if this makes sense to anyone else , but to me the first version is a word , the second option is a sentence :) Cheers -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear-1.99.5-RC2
On mardi 16 décembre 2008, Durk Talsma wrote: > Hi Fred, > > On Saturday 13 December 2008 18:50:51 Frederic Bouvier wrote: > > I replied that the target is next Friday. After that I may have > > difficulties to build a binary from where I will be. > > > > -Fred > > How would your availability be after Friday. As it turns out, I have a > Christmas dinner this Friday, so I won't be able assemble the final release > by then. Saturday will be fine for me, so I hope to roll up the release > then. > > Cheers, > Durk > Hello, Durk How do you schedule the period test with OSG 2.8 before rolling up the release ? OR do you avoid any test with it ? Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal globals.nas, 1.42, 1.43
Melchior FRANZ wrote: > var MPS_TO_KT = MPS2KT; > > What do other Nasal developers think? I'm willing to change it if > others have problems with that, too. (And to change all occurrences > in the repository.) No problem here with shorter names for the constants. For me they are easy to recognize and my lines are already too long. Alexis -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Nasal globals.nas, 1.42, 1.43
Melchior FRANZ wrote: > * James Turner -- Wednesday 17 December 2008: > > > + var KT2MPS = 0.51; # knots to m/s > > > Personally I think all these constants would be easier to > > read if they were written the same way as the Simgear ones, > > i.e MPS_TO_KT, NM_TO_M and so on. > > I find them equally easy to read and decided to use the way > that YASim uses (from the same author as Nasal, as you probably > know). See ./src/FDM/YASim/FGFDM.cpp. I only made the DEG2RAD > even shorter (which might indeed have been a mistake). But you > can easily do something like this in your Nasal code (once there > is something like "your Nasal code", that is ;-): > > var MPS_TO_KT = MPS2KT; > > What do other Nasal developers think? I'm willing to change > it if others have problems with that, too. (And to change all > occurrences in the repository.) Well, it's been a while since I wrote some Nasal code, but I personally prefer the longer names. But then my code tends to be very verbose anyway. :) > BTW (or BY_THE_WAY, as some say): LAUGH_OUT_LOUD -Stuart -- SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada. The future of the web can't happen without you. Join us at MIX09 to help pave the way to the Next Web now. Learn more and register at http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
