Re: [Flightgear-devel] fgfs aborted with the dc3
Ron Lange wrote: Hallo Boris, Boris Koenig schrieb: More precisely the file with the checksums for 0.9.5final is at: http://www.geocities.com/sandreas41/data/fgfs-base-0.9.5.md5.gz I've just patched with this file and everything seems to be right. Alright, thanks for providing feedback ! Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
Arnt Karlsen wrote: On Sun, 01 Aug 2004 20:31:49 +0200, Boris wrote in message [EMAIL PROTECTED]: one other thing: I mentioned already that I didn't have the original pre-release available to create that patch, meanwhile Stewart Steven have released a patch that's based on the _original_ pre2-release, which *differs* from mine, you can get that file at: http://www.geocities.com/sandreas41/data/base-0.9.5p2-0.9.5.tar.gz ..ah, that means at least one of you guys has been a naughty boy and worked from something _other_ than an official FG release. ;-) Arnt, how about starting to actually *read* my postings - at least those that you reply to ? :-) I did mention _all the time_ that I didn't have the original (pre)releases available and hence decided to use a CVS checkout as reference basis for the patch. Having meanwhile had the chance to test it, it does seem work anyway, just more files being put into the folder - but I didn't really check it thorougly. Contary to that, the 0.9.4 final = 0.9.5 final patch is based on official releases, which I also mentioned ;-) As I said already: I would not mind creating such a patch chain, but first we would need to know whether things are working as expected and THEN I would still need access to the original pre-releases in order to create the necessary patch archives. ..another idea to test these; provide test scripts. I have bandwith and disk space and vacant cpus, but no time. that would then be very specific to FlightGear, and I think Steven Stewart are right in trying to keep things as general as possible, e.g. that way they can use that script for _many_ purposes, so it does have its justification outside the FG world. IF such an extension is considered a good idea by several users here, one could think about providing externals means for it. ..basically, something like for FG in FlightGear SimGear plib ; ;for V in 0.9.5 0.9.4 # etc for SimGear plib too ;do wget -c $FG.org/downloads/FG-$V.tar.bz2 ;tar jxvf $FG$V.tar.bz2 ;done # etc ;done so you are talking of an automated updater ? regarding that one really has to be careful, not everybody has a full GNU toolchain available, even though there are things like Cygwin they do significantly complicate things for novice users - or at least for those who are not really familiar with Unix. (I know that stuff like wget is also available as a standard Win32 compiled version, but it's not per default available on windows ...) diff -ruN $FG$V $FG$($V-1) diff-from-$FG$($V-1)-to-$FG$V md5sum diff-from-$FG$($V-1)-to-$FG$V bzip2 diff-from-$FG$($V-1)-to-$FG$V md5sum diff-from-$FG$($V-1)-to-$FG$V.bz2 # etc. ..the md5sums are neat to verify that we wind up with the same source tarballs, without having to build them. not sure about how much sense something like that would make, we will have to wait for other opinions, but it's gonna certainly be beyond the scope of tardiff. ..expanding on this idea, it is possible to have newbies use this upgrade script to update their old FG to the current, I really doubt, how feasible something like that would be for for newbies, I know a lot of windows users who would certainly not manage to make use of something like that - and as soon as you are a user of a unix-based OS the debate becomes pointless as you are likely to be somewhat more familiar with your system anyway and certainly would not care doing the required steps manually. first chking for their old FG, then fetch Boris' tardiffs tardiff itself comes from Steven Stewart Andreason - so it certainly was _not_ mine idea - just to clarify things and give credit where it's due. and patch up their FG install to the latest official FG, SimGear and plib. I think we'll really have to wait for other opinions, I really doubt that it would pay off - simply because the work that needs to be done would probably take relatively long compared to that group of users who might really make use of something like that, but that's my personal view ... ..at some stage, the official tarballs (or a cvs co to the latest cvs release tag) becomes more comvenient, so don't over-engineer it. ;-) I agree, I've talked to Steven Stewart about that and they also think that the current version is going to be the final version for the near future, maybe there'll be one or two small fixes but not many enhancements anymore. It might still become useful to add one or two small features when changes in the fgfs base archive require more sophisticated tracking mechanisms. The only thing that I can currently think of would be an addition to support simultaneous creation of ZIP archives, simply as there are a lot more common for winows and more familiar to its users so it might really make things simpler for those users... -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.5
Martin Spott wrote: The package is present at the usual place: ftp://ftp.uni-duisburg.de/FlightGear/Solaris/fgfs-0.9.5-Solaris.tar.gz Curt, this package already includes the GCC runtime libraries - not need anymore to download the GCC-3.3 runtime package as advised on the FlightGear Download page, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFD: how to handle add-on ground scenery distribution
Erik Hofman wrote: Yes. Maintaining can be done using CVS and when the official release is out it can be just a matter of letting a script generate the tarballs for the static scenery. It may be something which would benefit from a more regular snapshot though - so that new scenery is available as soon as it's uploaded. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
On Mon, 02 Aug 2004 08:18:00 +0200, Boris wrote in message [EMAIL PROTECTED]: Arnt Karlsen wrote: On Sun, 01 Aug 2004 20:31:49 +0200, Boris wrote in message [EMAIL PROTECTED]: one other thing: I mentioned already that I didn't have the original pre-release available to create that patch, meanwhile Stewart Steven have released a patch that's based on the _original_pre2-release, which *differs* from mine, you can get that file at:http://www.geocities.com/sandreas41/data/base-0.9.5p2-0.9.5.tar. gz ..ah, that means at least one of you guys has been a naughty boy and worked from something _other_ than an official FG release. ;-) Arnt, how about starting to actually *read* my postings - at least those that you reply to ? :-) ..heh, good catch, could looong length be an issue? ;-) I did mention _all the time_ that I didn't have the original (pre)releases available and hence decided to use a CVS checkout as reference basis for the patch. Having meanwhile had the chance to test it, it does seem work anyway, just more files being put into the folder - but I didn't really check it thorougly. Contary to that, the 0.9.4 final = 0.9.5 final patch is based on official releases, which I also mentioned ;-) As I said already: I would not mind creating such a patch chain, but first we would need to know whether things are working as expected and THEN I would still need access to the original pre-releases in order to create the necessary patch archives. ..another idea to test these; provide test scripts. I have bandwith and disk space and vacant cpus, but no time. that would then be very specific to FlightGear, ..yup, thats precisely the idea. and I think Steven Stewart are right in trying to keep things as general as possible, e.g. that way they can use that script for _many_ purposes, so it does have its justification outside the FG world. ..it (tardiff) does, and it looks good, so build on it. IF such an extension is considered a good idea by several users here, one could think about providing externals means for it. ..in this meritocraty, _only_ those ideas that are _acted_ upon, prevails. ;-) ..basically, something like for FG in FlightGear SimGear plib ; ;for V in 0.9.5 0.9.4 # etc for SimGear plib too ;do wget -c $FG.org/downloads/FG-$V.tar.bz2 ;tar jxvf $FG$V.tar.bz2 ;done # etc ;done so you are talking of an automated updater ? ..define automated. The idea is the user should find an update script over at fg.org, and be able to update to the latest official release, and at least say Yes. ;-) regarding that one really has to be careful, not everybody has a full GNU toolchain available, even though there are things like Cygwin they do significantly complicate things for novice users - or at least for those who are not really familiar with Unix. (I know that stuff like wget is also available as a standard Win32 compiled version, but it's not per default available on windows ...) ..so test for it and haul it home where needed. ;-) diff -ruN $FG$V $FG$($V-1) diff-from-$FG$($V-1)-to-$FG$V md5sum diff-from-$FG$($V-1)-to-$FG$V bzip2 diff-from-$FG$($V-1)-to-$FG$V md5sum diff-from-$FG$($V-1)-to-$FG$V.bz2 # etc. ..the md5sums are neat to verify that we wind up with the same source tarballs, without having to build them. not sure about how much sense something like that would make, we will have to wait for other opinions, ..what suddenly stopped you from forming and voicing your own opinions here? ;-) but it's gonna certainly be beyond the scope of tardiff. ..it _is_. ;-) ..expanding on this idea, it is possible to have newbies use this upgrade script to update their old FG to the current, I really doubt, how feasible something like that would be for for newbies, I know a lot of windows users who would certainly not manage to make use of something like that - and as soon as you are a user of a unix-based OS the debate becomes pointless as you are likely to be somewhat more familiar with your system anyway and certainly would not care doing the required steps manually. first chking for their old FG, then fetch Boris' tardiffs tardiff itself comes from Steven Stewart Andreason - so it certainly was _not_ mine idea - just to clarify things and give credit where it's due. ..true. And when you use their tardiff script to diff tarballs, those tardiffs or better, diffballs are yours. and patch up their FG install to the latest official FG, SimGear and plib. I think we'll really have to wait for other opinions, I really doubt that it would pay off - simply because the work that needs to be done would probably take relatively long compared to that group of users who might really make use of something like that, but that's my personal view ... ..see above. ;-) ..at some stage,
Re: [Flightgear-devel] ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
A short message for Arnt ! Arnt Karlsen wrote: On Mon, 02 Aug 2004 08:18:00 +0200, Boris wrote in message [EMAIL PROTECTED]: Arnt, how about starting to actually *read* my postings - at least those that you reply to ? :-) ..heh, good catch, could looong length be an issue? ;-) in general I'd agree, but not all messages that I post here are that long - so maybe we could at least agree on reading what we are replying to ;-) and I think Steven Stewart are right in trying to keep things as general as possible, e.g. that way they can use that script for _many_ purposes, so it does have its justification outside the FG world. ..it (tardiff) does, and it looks good, so build on it. I'm currently thinking about Erik's idea to use the CVS timestamps for comparison purpose and to tell then which files have changed, that way it should be possible to determine differences between two CVS versions without the need to really check out both revisions. That way only the stuff that got really changed would be downloaded. IF such an extension is considered a good idea by several users here, one could think about providing externals means for it. ..in this meritocraty, _only_ those ideas that are _acted_ upon, prevails. ;-) yes, I've also come to the conclusion that this is somewhat true here ...ideas/suggestions only seem to be considered really as long as there is something ready ... so you are talking of an automated updater ? ..define automated. = to require as few user interaction as necessary for the updating process. The idea is the user should find an update script over at fg.org, and be able to update to the latest official release, and at least say Yes. ;-) I think we agree here (see above) regarding that one really has to be careful, not everybody has a full GNU toolchain available, even though there are things like Cygwin they do significantly complicate things for novice users - or at least for those who are not really familiar with Unix. (I know that stuff like wget is also available as a standard Win32 compiled version, but it's not per default available on windows ...) ..so test for it and haul it home where needed. ;-) what you are basically suggesting here is an automated install wizard tool - with the ability to retrieve dependencies ... people are working on similar projects, but they are usually pretty complex ... not sure about how much sense something like that would make, we will have to wait for other opinions, ..what suddenly stopped you from forming and voicing your own opinions here? ;-) Nothing, nor do I think that there would be a peaceful way to achieve something like that :-) I was just implying that it certainly does not make sense to put much work into it before several people have come to the conclusion that it might be useful, I still doubt that something like that could be really simple enough for *everybody* ...at least of you want to keep the application itself AND external pre-requisites simple. To be honest: implementing such an application for easy updating as a *shell* script is certainly not going to appeal to the majority of windows users, never forget: only few of the regular (windows) users are really familiar with a shell at all, so in order not see them freak out, one would have to use some graphical frontend, tcl/tk comes to my mind ... Then again everybody would need to have the necessary runtime stuff installed :-/ If you have a good suggestion, don't hesitate to tell me, cause I really think the advantage would be mainly significant if such a tool used (optionally) a graphical frontend... Hey, about integrating the necessary functionality into FlightGear itself, then we'll have a graphical UI :-)) ..I'd rather see them suggest useing tgz, if the idea is get Winzip working. okay, thanks for that suggestion - that's a good one, unix users shouldn't care either way and if it makes things simpler for windows users it should really be named that way, it's going to be added/changed in the next version :-) Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Data source battle?
Jon Berndt said: I don't use real weather because most of my flying is to test the fdms I'm working on, Just so I am clear, when you say fdms are you referring to Flight Dynamics Model source code, or are you referring to something I'd call an Aircraft Flight Model (AFM) or Aircraft Flight Model Definition (AFMD). I don't mean to sound snobbish, but when I think of FDM I think of math (equations of motion). The aircraft definition files - whether it be a JSBSim aircraft definition file, a YASim one, or whatever - define the aircraft - which the FDM code interprets and brings to life. We've never really discussed terminology as far as I can remember, but maybe a clarification would be good - if only so that my filter rules don't categorize messages incorrectly. :-) If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the source code that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? Or maybe I'm just not very good at it :-) Heh...probably the later! Anyway, I knew exactly what Lee meant. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim strangeness
Matthew Law said: David Megginson wrote: I cannot reproduce it on my system: fgfs [EMAIL PROTECTED] --aircraft=j3cub I put on the parking brake (who'd have thought the J3 Cub had a parking brake?) and tried moving all of the control surfaces. They had no effect on the aircraft, either with the engine on or with the engine off. I'm not surprised you couldn't replicate it. I found a pesky old .fgfsrc file containing: [EMAIL PROTECTED] I'll get my coat :-/ Lol... nah don't go. We've all done something like that. Well, maybe not everyone... ;-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Data source battle?
Jim Wilson wrote: If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the source code that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? This is absolutely true. It's almost an art form in itself. But, the aircraft definition is a complete, static, specification file for a specific aircraft. The flight dynamics model (I'm referring to JSBSim, YASim, or UIUC-LaRCsim source code compiled into FlightGear) _implements_ the flight dynamics guided by the specific aircraft flight model. Just my $0.03. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Flight Instrument Accuracy
Jim Wilson writes: If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the source code that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? Hmmm, speaking of accuracy. Do all the new aircraft use the output of the Instrumentation model to drive the flight instruments? If that is the case, then the 747, YF-23, T-38, 737, etc, etc are using data based on a light aircraft pitot-static ssytem and vacuum driven gauges and the associated lags and delays. For my 747 project I've decided to dig into JSBSim to get the raw data and pass that through an INS/ADC model to drive the glass displays. Depending on your purpose and application it might be a don't care, but it would have an impact on things like autopilots and error tracking/man-machine interface research. Just a thought Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flight Instrument Accuracy
John Wojnaroski said: Jim Wilson writes: If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the source code that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? Hmmm, speaking of accuracy. Do all the new aircraft use the output of the Instrumentation model to drive the flight instruments? If that is the case, then the 747, YF-23, T-38, 737, etc, etc are using data based on a light aircraft pitot-static ssytem and vacuum driven gauges and the associated lags and delays. For my 747 project I've decided to dig into JSBSim to get the raw data and pass that through an INS/ADC model to drive the glass displays. Depending on your purpose and application it might be a don't care, but it would have an impact on things like autopilots and error tracking/man-machine interface research. Just a thought The 747-400 3D models of displays and instruments do not use the cooked instrumentation outputs. Off the top of my head the backup AI might be an exception...not sure. In any case I've assumed the modern airliner displays to be quite accurate and responsive and just run directly off the FDM output. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flight Instrument Accuracy
- Original Message - From: Jim Wilson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Monday, August 02, 2004 2:58 PM Subject: Re: [Flightgear-devel] Flight Instrument Accuracy John Wojnaroski said: Jim Wilson writes: If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the source code that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? Hmmm, speaking of accuracy. Do all the new aircraft use the output of the Instrumentation model to drive the flight instruments? If that is the case, then the 747, YF-23, T-38, 737, etc, etc are using data based on a light aircraft pitot-static ssytem and vacuum driven gauges and the associated lags and delays. For my 747 project I've decided to dig into JSBSim to get the raw data and pass that through an INS/ADC model to drive the glass displays. Depending on your purpose and application it might be a don't care, but it would have an impact on things like autopilots and error tracking/man-machine interface research. Just a thought The 747-400 3D models of displays and instruments do not use the cooked instrumentation outputs. Off the top of my head the backup AI might be an exception...not sure. In any case I've assumed the modern airliner displays to be quite accurate and responsive and just run directly off the FDM output. Best, Jim Have you looked at the .xml files in the base package? I'm not all that conversant in xml or how the properties work, but it appears that some of the pressure instrument readings are drawn from the instrumentation property node and some for the /orientation node and in the case of the 737 some from the /fdm/jsbsim nodes. Perhaps someone could prove me wrong, but I can't find another altimeter model in the source except for the one in the /Instrumentation directory. The steam.cxx has been removed ( was it 0.9.1 or 0.9.2 ) Some other excerpts from instruments-3D property/instrumentation/airspeed-indicator/indicated-speed-kt/property property/instrumentation/altimeter/indicated-altitude-ft/property property/instrumentation/vertical-speed-indicator/indicated-speed-fpm/pro perty property/instrumentation/magnetic-compass/indicated-heading-deg/property Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Flight Instrument Accuracy
John Wojnaroski said: - Original Message - From: Jim Wilson [EMAIL PROTECTED] To: FlightGear developers discussions [EMAIL PROTECTED] Sent: Monday, August 02, 2004 2:58 PM Subject: Re: [Flightgear-devel] Flight Instrument Accuracy John Wojnaroski said: Jim Wilson writes: If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the source code that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? Hmmm, speaking of accuracy. Do all the new aircraft use the output of the Instrumentation model to drive the flight instruments? If that is the case, then the 747, YF-23, T-38, 737, etc, etc are using data based on a light aircraft pitot-static ssytem and vacuum driven gauges and the associated lags and delays. For my 747 project I've decided to dig into JSBSim to get the raw data and pass that through an INS/ADC model to drive the glass displays. Depending on your purpose and application it might be a don't care, but it would have an impact on things like autopilots and error tracking/man-machine interface research. Just a thought The 747-400 3D models of displays and instruments do not use the cooked instrumentation outputs. Off the top of my head the backup AI might be an exception...not sure. In any case I've assumed the modern airliner displays to be quite accurate and responsive and just run directly off the FDM output. Best, Jim Have you looked at the .xml files in the base package? I'm not all that conversant in xml or how the properties work, but it appears that some of the pressure instrument readings are drawn from the instrumentation property node and some for the /orientation node and in the case of the 737 some from the /fdm/jsbsim nodes. Perhaps someone could prove me wrong, but I can't find another altimeter model in the source except for the one in the /Instrumentation directory. The steam.cxx has been removed ( was it 0.9.1 or 0.9.2 ) Some other excerpts from instruments-3D property/instrumentation/airspeed-indicator/indicated-speed-kt/property property/instrumentation/altimeter/indicated-altitude-ft/property property/instrumentation/vertical-speed-indicator/indicated-speed-fpm/pro perty property/instrumentation/magnetic-compass/indicated-heading-deg/property The 747 xml files myself and they are stored in the Aircraft/747/Models directory. It looks like that analog backup altimeter and backup airspeed indicator are using the cooked values. The glass displays and the attitude indicator do not. FWIW it is somewhat better to work with the standard FDM interface properties rather than the fdm/JSBSim properties. If there is something you need that isn't already published (in the standard: position/ orientation/ velocities/ engine/ gear/ surface-positions/ paths) then maybe it needs to be added somewhere. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..update script tardiff (or cvs) idea, was: fgfs aborted with the dc3
On Mon, 02 Aug 2004 16:08:52 +0200, Boris wrote in message [EMAIL PROTECTED]: A short message for Arnt ! ..Winston Churchill had a great way of having bureaucrats trim their language; it had to be readable without glasses, from across the room, on one sheet of paper, nailed to the wall. ;-) Arnt Karlsen wrote: On Mon, 02 Aug 2004 08:18:00 +0200, Boris wrote in message [EMAIL PROTECTED]: Arnt, how about starting to actually *read* my postings - at least those that you reply to ? :-) ..heh, good catch, could looong length be an issue? ;-) in general I'd agree, but not all messages that I post here are that long - so maybe we could at least agree on reading what we are replying to ;-) ..maybe. ;-) and I think Steven Stewart are right in trying to keep things as general as possible, e.g. that way they can use that script for _many_ purposes, so it does have its justification outside the FG world. ..it (tardiff) does, and it looks good, so build on it. I'm currently thinking about Erik's idea to use the CVS timestamps for comparison purpose and to tell then which files have changed, that way it should be possible to determine differences between two CVS versions without the need to really check out both revisions. That way only the stuff that got really changed would be downloaded. ..act on it. ;-) IF such an extension is considered a good idea by several users here, one could think about providing externals means for it. ..in this meritocraty, _only_ those ideas that are _acted_ upon, prevails. ;-) yes, I've also come to the conclusion that this is somewhat true here ...ideas/suggestions only seem to be considered really as long as there is something ready ... .. ;-) so you are talking of an automated updater ? ..define automated. = to require as few user interaction as necessary for the updating process. The idea is the user should find an update script over at fg.org, and be able to update to the latest official release, and at least say Yes. ;-) I think we agree here (see above) .. ;-) regarding that one really has to be careful, not everybody has a full GNU toolchain available, even though there are things like Cygwin they do significantly complicate things for novice users - or at least for those who are not really familiar with Unix. (I know that stuff like wget is also available as a standard Win32 compiled version, but it's not per default available on windows ...) ..so test for it and haul it home where needed. ;-) what you are basically suggesting here is an automated install wizard tool - with the ability to retrieve dependencies ... people are working on similar projects, but they are usually pretty complex ... ..so simplify it. ;-) ..hint; don't wait for some fool to write some kinda one-big-app-does-it-all, look around for scripts that does _part's_ of what you want done, and piece those script bits together with your own set of scripts, chk out http://tldp.org/LDP/Bash-Beginners-Guide/html/ http://tldp.org/LDP/intro-linux/html/ http://tldp.org/LDP/abs/html/ ..the bash classics: http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html http://tldp.org/HOWTO/Bash-Prompt-HOWTO/ ..general classics: http://tldp.org/HOWTO/Tips-HOWTO.html ..wintendo support: http://cygwin.com/ http://www.cygwin.com/cygwin-ug-net/cygwin-ug-net.html not sure about how much sense something like that would make, we will have to wait for other opinions, ..what suddenly stopped you from forming and voicing your own opinions here? ;-) Nothing, nor do I think that there would be a peaceful way to achieve something like that :-) I was just implying that it certainly does not make sense to put much work into it before several people have come to the conclusion that it might be useful, I still doubt that something like that could be really simple enough for *everybody* ...at least of you want to keep the application itself AND external pre-requisites simple. To be honest: implementing such an application for easy updating as a *shell* script is certainly not going to appeal to the majority of windows users, never forget: only few of the regular (windows) users are really familiar with a shell at all, so in order not see them freak out, one would have to use some graphical frontend, tcl/tk comes to my mind ... Then again everybody would need to have the necessary runtime stuff installed :-/ If you have a good suggestion, don't hesitate to tell me, cause I really think the advantage would be mainly significant if such a tool used (optionally) a graphical frontend... Hey, about integrating the necessary functionality into FlightGear itself, then we'll have a graphical UI :-)) ..whenever pigs fly. Meanwhile, start with a set of shell scripts, and hide them from those chicken Wintendo users who clicks Graphical Upgrade Wizard, and show real people
Re: [Flightgear-devel] Flight Instrument Accuracy
On Monday 02 August 2004 21:22, John Wojnaroski wrote: Jim Wilson writes: If it wasn't for the great work on JSBsim and YASim we'd have very few aircraft. But I think those config files, along with the source code that ends up interpreting and processing them, both make up the FDMs. There is considerable skill and effort involved in producing accurate flight models for new aircraft isn't there? Hmmm, speaking of accuracy. Do all the new aircraft use the output of the Instrumentation model to drive the flight instruments? If that is the case, then the 747, YF-23, T-38, 737, etc, etc are using data based on a light aircraft pitot-static ssytem and vacuum driven gauges and the associated lags and delays. For my 747 project I've decided to dig into JSBSim to get the raw data and pass that through an INS/ADC model to drive the glass displays. Depending on your purpose and application it might be a don't care, but it would have an impact on things like autopilots and error tracking/man-machine interface research. Just a thought Regards John W. FWIW, I've not attempted any 'proper' panels yet and the instruments that I've included on the panels I've done so far are more for monitoring what the a/c is doing, rather than being designed for flying the a/c. As such, many of them do not use data from the 'instrument' sub-system but show absolute readings from the property tree. I'd like to do 'proper' panels and instruments but until I have a better understanding of how they work and how they're used, in real-life, I'm holding off trying any. LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] updated ThrustMaster FCS config
Hello all, The following patch updates the ThrustMaster FCS joystick configuration. I have Nasal-ized the joystick bindings, drawing ideas from the Cyborg-Gold-3d-USB configuration file. I also changed some of the bindings, so the joystick setup is more like the default four-axis-joystick config. When I submitted the original config file, I had the hat switch bound to the rudder and elevator trim. Since the vast majority (all?) of the other joystick configs use the hat switch to control view direction, I think it would be best for the defaults for this joystick to conform to the rest in order to obey the principle of least surprise for the unsuspecting user. The patch may be downloaded from: http://www.personal.psu.edu/elh102/FCS.diff Thanks, -Eric Hathaway ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
