Re: [Flightgear-devel] Feedback forces
Thank you. And what about null forces position? It must by used for triming. THX -mamu- Curtis Olson napsal(a): > On Mon, Jul 6, 2009 at 6:47 AM, ing. Petr Ondra wrote: > >> Hi. >> Please where are information about forces on aileron, rudder and >> elevator in internal properties? I can't find it :-( > > > It is probably best to ask about this on the JSBSim mailing list. As far as > I know, neither JSBSim nor YASim compute these forces. > > Curt. > > > > > -- > > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Feedback forces
On Mon, Jul 6, 2009 at 6:47 AM, ing. Petr Ondra wrote: > Hi. > Please where are information about forces on aileron, rudder and > elevator in internal properties? I can't find it :-( It is probably best to ask about this on the JSBSim mailing list. As far as I know, neither JSBSim nor YASim compute these forces. Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Oh, I'm well aware of that (former development professional, not just 3d games. 10 years of it), and it's not a big issue indeed, but nevertheless a cosmetic issue that shouldn't be neglected when possible. So let's forget I even mentioned it happens to cvs users : it happens to stable releases using official aircraft. It's not a showstopper, but seeing as very little effort is necessary to preserve MP visuals across model versions (and that's the extent of backward compatibility I'm talking about, don't anyone go putting words in my mouth). So before more folks chime in saying cvs is unstable, blabblabla, a fact I'm well aware of, let's focus on the fact that it's an universal issue, ranging across flight gear versions, platforms and branches. . This issue has nothing to do with development versions vs release : MP is an heterogenuous network, it's one of its great strengths, let's not go out of our ways to brake visuals consistency. This is basic common sense, but call it barebones userbase pampering if you will ;) I can live with all the glitches and hack my way out of some of them, time allowing, not sure average joe who's an aviation enthusiast and just wants to fly with friends in this particular simulator should have to hack things around. That he can is fabulous. Doesn't mean he has to. Not expecting or demanding anything, just wanted to voice a thought and to remind, as Syd proved it, that the fear of maintenance hell is just that, a fear. And Syd doesn't really care for MP :) That didn't prevent him from coming through, big time. As for external models, I was using that as an example, I certainly don't expect cvs contents to allow for them or correct errors in them... Rather, I was saying that if someone leaves, and is going to break compatibility it might be courteous to change the names of the aircraft, as in the folder name (and thus the paths inside all the xml files) to prevent this kind of problem. Prevention, not medication !!! ;) That should be food for thought, and that was all the whole point of mentioning the whole thing : I don't think it's much to ask that MP visual consistency be taken into account by aircraft authors in the absence of a system that would do it for them : an aircraft using the same folder name is the same aircraft as far as fgfs is concerned, so let's try to avoid situations where *changes in cvs models break MP visuals for stable releases. * Do we want to keep the flexibility of the MP system, or have it degenerate into a version/build discrete system that only shows you the a/c flying the exact same setup as you ? The latter would be a shame. Again, with a lack of a unified or official approach to the problem, all I'm asking is a little thought and not outright dismissal of keeping MP visuals consistent. Point, à la ligne. One last thing : thank you all for your hard work, I appreciate and am enjoying the hell out of it. Cheers, have a nice day, Nic On Sun, Jul 5, 2009 at 11:19 PM, Rob Shearman, Jr. wrote: > Nic, > > It's also worth pointing out (again!) that users of CVS must accept that FG > and its associated models are constant works-in-progress. Issues like you > describe are easily fixable prior to an official release, but are difficult > to manage in the constant state of flux between them. I'm in agreement with > Syd that the benefits from changes which simplify an aircraft model's > delivery outweigh the relatively small and temporary annoyance that comes > with them. > > Cheers, > -R. > > > > > > -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How does the Radar work?
Aeitsch wrote > >Unfortunately the "weather" bit is > >broken, and is likely to remain so until we can figure out a way to > >detect cloud > >locations. > > Which should imho maybe possible, as the the position of each cloud can be > find in the property browser. Maybe Stuart can help here- our clouds > deserves now really a nice weather radar! > > Regards > HHS > Would be entirely possible, we have to get the cloud locations into the same frame of reference as the radar, and to work out some rules for detection. We just haven't really applied ourselves to that issue yet. Contributions welcome. Vivian -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Feedback forces
Hi. Please where are information about forces on aileron, rudder and elevator in internal properties? I can't find it :-( THX -mamucz- -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous
On dimanche 05 juillet 2009, Martin Spott wrote: > Hi Nicolas, > > Nicolas Quijano wrote: > > The specific "culprits" today are Syd Adams (dhc2, for sure and dhc6 > > also, I think) and Gerard Robin (PBY-Catalina). There might have been > > more cases today, and I think we have a few more a/c in cvs who exhibit > > those symptoms > > [...] > > > Or, if the aircraft now exists in cvs and externally maintained versions, > > the considerate thing would be to rename the externally maintained > > version's folder [...] > > If you're expecting a 'stable' setup, please make sure that everyone's > using either the latest release or current CVS. I don't see why > aircraft developers should maintain backward compataibility in a > development !! tree just for users/gamers pleasure. > Well, and If you're using aircraft which are maintained externally > nobody but you is responsible for your choice. > > Cheers, > Martin. Hello Nicolas, Like said Martin, the most difficult could be with "Externals Models". The PBY-Catalina ( that one which is in CVS) got the wrong name since the beginning. I could notice (recently) some misunderstanding on the French Forum, the right name should be "Pelican Jaune" since the model is supposed to be the French fire bomber adapted from the real Consolidated PBY-6 version. The choice of Catalina name itself could be wrong since it could be Canso depending on the place it was built ( Canada or England ) Anyhow, data/Aircraft/PBY-Catalina/Models/nn.xml file which is called from the set.xml file is significant over MP, could be, by any user playing with MP, linked ( ln ) with an old and generic name. Sorry for the trouble with that model , and sorry for the trouble regarding all others models which are in my home page whose name has changed, since they are new versions, 3d models and FDM ( and different license ) versus the the old CVS. -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] How does the Radar work?
Hi >Unfortunately the “weather” bit is >broken, and is likely to remain so until we can figure out a way to >detect >cloud >locations. Which should imho maybe possible, as the the position of each cloud can be find in the property browser. Maybe Stuart can help here- our clouds deserves now really a nice weather radar! Regards HHS -Original Message- From: ÁèÉÇ¿ [mailto:lingsq2...@hotmail.com] Sent: 04 July 2009 11:48 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] How does the Radar work? I made a study on the 777-200er's radar display. To figure out how it works I read the soure code ,wxradar.cxx which is in the libinstruments.After read the src ,I know how the radar detects the ai planes or mp planes. But I really want to know how radar outputs the detected targets to the radar display.I mean the radar display could be a 3d model, but I found no where in the -xml files and -nas files that tells the radar where to output the data. Best Regards! Steven_Lingsq 把MSN装进手机，更多聊天乐趣等你挖掘！ 立刻下载！ -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
