Re: [Flightgear-devel] dumb git question
On Tue, 2010-06-22 at 15:20 -0500, Curtis Olson wrote: > Here's a dumb git question. > > > Previously with cvs or svn, if I inadvertently removed a file, or > screwed up a file really badly and just wanted to start clean with the > repository version, I could just remove the file and run "cvs/svn > update" and the missing file would be noticed, and the system would > pull the correct version back from the repository. > > Is there an equivalent or similar way to do this in git? "git pull" > says "already up to date". "git update" says 'update' is not a git > command. git checkout --help -- Roy Vegard -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Metapost for drawing instruments?
On Friday June 11 2010 19:33:09 Curtis Olson wrote: > Hi, > > Does anyone have any examples of using metapost to draw instrument graphics > (arcs, ticks, etc.) Or are there other free tools that have > good primitives for drawing instrument/gauge graphics? Melchior made a Python script to generate svg-files: http://www.mail-archive.com/flightgear-de...@flightgear.org/msg30853.html -- Roy Vegard -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate files in base package
On Friday February 26 2010 02:18:30 syd adams wrote: > I agree , there's a lot of duplication ,(in instruments, too) but I think > the problem is author's tastes ... > I've duplicated textures because I dont care for the look , or style , > etc,of existing ones and Im sure that's the same for other contributors. I've only considered files that are bit-by-bit identical (identical SHA1 checksum). If in your example you've duplicated a bitmap from another aircraft and then changed the file, then it is not considered a duplicate. > So it might be a problem deciding who's get's used, and how many duplicates > pop up in that folder :). > But it would be nice to solve this one... > Cheers > -- Roy Vegard -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Duplicate files in base package
FSlint reports that the base package, or the data directory, contains quite a lot of duplicate files. The file that is wasting the most bytes is glass_shader.png (some instances named glass.png) with 43 974 656 bytes, or around 45MB. This file is duplicated 89 times. The second biggest waster is shader.png (here too some instances are named glass.png) with 31 457 280 bytes and 641 instances. Running fdupes in the data directory reports that duplicate files occupy about 420 megabytes of the 2.7 Gig. Thats roughly 15% (if my math is correct). Many of the duplicate files seem to be textures. This begs the question: would it be better to have a directory $FG_ROOT/Aircraft/Textures where one would put textures that are shared by several aircraft? There already is a $FG_ROOT/Textures directory, but this seems to contain only non-aircraft textures. Comments? -- Roy Vegard -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Instrumentation instrument_mgr.cxx, 1.40, 1.41 instrument_mgr.hxx, 1.6, 1.7
> Update of /var/cvs/FlightGear-0.9/source/src/Instrumentation > In directory baron.flightgear.org:/tmp/cvs-serv24388/src/Instrumentation > > Modified Files: > instrument_mgr.cxx instrument_mgr.hxx > Log Message: > Ensure we always create a GPS instrument. What if I really, really, really don't want a GPS? :-) But seriously, why must every aircraft have a GPS? -- Roy Vegard Ovesen -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Sunday 11 October 2009 14:04:19 Kishore wrote: > > Not having a common time base reference for the various subsystems can lead > to varying performance based on the underlying hardware on which flightgear > is run. The PID/Autopilot tuning for a given model should not vary based on > the hardware on which flightgear is run. Should it? Or did I get this all > wrong? The autopilot code "compensates" for varying frame rate by using the delta-time between frames in the calculation of the PID-controller output. Without this I believe that the autopilot would have been quite unusable. -- Roy Vegard Ovesen -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot and violent roll
On Saturday 10 October 2009 22:33:01 Curtis Olson wrote: > > Really, this is all in how the autopilot is tuned and configured. > > FlightGear doesn't model realistic control surface deflection rates so it's > possible to command an instantaneous deflection of the control surfaces. Control surface deflection rate can be limited by inserting a low-pass filter between the output of the final PID-controller and the control surface. THis is done in the autopilot config file. > FlightGear also doesn't model how much load the airframe can endure before > pieces began to depart and go their own separate ways. > > Thus assuming infinite control surface deflection rates and perfectly rigid > and robust airframe, and assuming the flight dynamics are configured > correctly, what you see is a realistic response. > > You can tune the control surface movement rates and maximum deflection > angles in the autopilot configuration for each aircraft. This would be an > excellent place to start. > > This isn't a systemic FlightGear problem, it's an autopilot configuration > problem that seems to be replicated across many aircraft. > > But tuning autopilots is hard for most people, and probably for most > aircraft authors so this is an area that is not attended to very well. You > might be imagining that FlightGear has a single universal autopilot that > runs all airplanes the same way, and you'd be wrong. There is an > individual config file that sets up the cascading stages and inputs and > reference values and outputs for each stage. You can do a lot of neat > stuff with it, but if it's not well tuned you'll get a lot of unstable > behavior. > > For what it's worth I recently saw a very expensive UAV flying with a > poorly tuned autopilot and the result was not smooth and graceful whereas > the aircraft flew beautifully under manual control. > > Best regards, > > Curt. -- Roy Vegard Ovesen -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Double sided in Blender
On Friday 12 June 2009 07:20:25 Innis Cunningham wrote: > Thanks Gary > I don't think that is it I have checked the normals and flip them to no > avail. Correct me if I am wrong but if the object is double sided then you > should not be able to see through it from one side.As I said before when > the faces concerned are separate objects they show double sided in FG it is > only when they are joined together that they become one sided. Assuming that you use Blender to export to AC3D format: http://wiki.flightgear.org/index.php/Normals_and_Transparency_Tutorial -- Roy Vegard Ovesen -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Saturday 07 February 2009 20:25:43 alex wrote: > On Saturday 07 February 2009 11:50:57 FGD ML wrote > > Yes, full pathname to the .png image file. There is actually a bug in the > > > exporter code that cuts one character from the path string (/home/... > > becomes /hme/...). I also tried to remove the pull path leaving only the > > filename, and copied the image file into the same directory as the .lwo > > file, but that did not work. > > > >> I read on the One Blender tutorial that if the image path to an lwo file > >> is longer than 19 characters it will not show, as 19 is the max. The image path is preceded by a byte holding the length of the path, so I guess 256 is the maximum path length. In my example the path length was 76! -- Roy Vegard Ovesen -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Saturday 07 February 2009 12:38:23 FGD ML wrote: > 2009/2/7 Roy Vegard Ovesen > > Do you mean grab a copy of LightWave? > > Yeah, why not? I heard that these days it just runs in "discovery mode" > (?) if you don't have a dongle. I've never been there so don't know how > that turns out, but I'd guess it's a chance to look it over at least. I'd > guess they wont allow you to save a model but that would mean they have to > supply access to some, and then you got a textured model to export in > blender or AC3D that's at least done right enough to be in the official LW > distribution. Then you got a menas of comparison between how it looks in > it's home and how it turns out in the conversion process or how it looks in > FG once that is possible directly and routinely. > > Newtek should be able to supply details or even the straight download on > their web site knowing them. If it's a "we'll send you a cd deal" then why > not? When was the last time you got something in the mail that you actually > wanted to see there?! ;O) I find those to be in the minorty these days, > just bills and junk mostly. I downloaded the 30 day trial version. It's full featured during the trial period. > You'd be able to see how good their docs are too. Like no other that I know > of. There may have been docs they made down the years that were inaccurate > or out of date or both, but I have yet to see one. Maybe I just got lucky, > but after all this time I think it's more probably because they simply get > down there roll up their sleeves and and just do the work required by the > job in hand, while maintaining high standards. I could also be wrong of > course. I rarely need to dip into the docs any more. I only use a limited > subset of what it can do and I generally know where that stuff is by now. > > Have fun, hope you like what you see. Now I have 24 hours of training videos to watch :-). I'm not the kind of person that is desperately trying not to learn anything new, but in the interest of saving time could you please post a link to a more complex model than the Borgbox? Surely you have lots of models. -- Roy Vegard Ovesen -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Saturday 07 February 2009 11:50:57 FGD ML wrote: > 2009/2/7 Roy Vegard Ovesen > > > On Saturday 07 February 2009 10:22:09 Roy Vegard Ovesen wrote: > > > As I said the .lwo file that Blender generated did _not_ contain any > > > reference to the texture image, so I don't think that putting the image > > > > in > > > > > the same path as the .lwo file will work. This could of course be > > > because I'm not using Blender correctly, but I think that is > > > irrelevant. We want > > > > to > > > > > test .lwo files created by LightWave, not .lwo files created by > > > Blender. > > > > Turns out I _did_ use Blender incorrectly. > > Well there you go! > > > I managed to create a Borgbox textured with a .png image from the FG data > > dir, > > and display it correctly in osgviewer. I would really like to repeat the > > test > > with a .lwo file created with the reference software LightWave. I don't > > see using Blender to create .lwo files as a realistic workflow > > We seem to be agreed there. It's OK for some I guess, I just have a > different taste when it comes to getting work done. I tend to like to be > able to see more of the job in hand, and far, far less of the interface. > > Can I take it you can now see the filename(s) in the .lwo? It's normally > down towards the end of the file. Yes, full pathname to the .png image file. There is actually a bug in the exporter code that cuts one character from the path string (/home/... becomes /hme/...). I also tried to remove the pull path leaving only the filename, and copied the image file into the same directory as the .lwo file, but that did not work. > Go grab a copy! At least know how it /can/ be done. I always do that where > the maker makes it possible without fuss or gotchas of any kind. I see it > as meeting them halfway. It then has it's one chance to impress me, just > like anything else gets. Do you mean grab a copy of LightWave? -- Roy Vegard Ovesen -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Saturday 07 February 2009 10:22:09 Roy Vegard Ovesen wrote: > > As I said the .lwo file that Blender generated did _not_ contain any > reference to the texture image, so I don't think that putting the image in > the same path as the .lwo file will work. This could of course be because > I'm not using Blender correctly, but I think that is irrelevant. We want to > test .lwo files created by LightWave, not .lwo files created by Blender. Turns out I _did_ use Blender incorrectly. I managed to create a Borgbox textured with a .png image from the FG data dir, and display it correctly in osgviewer. I would really like to repeat the test with a .lwo file created with the reference software LightWave. I don't see using Blender to create .lwo files as a realistic workflow -- Roy Vegard Ovesen -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Saturday 07 February 2009 01:48:55 FGD ML wrote: > 2009/2/6 Roy Vegard Ovesen > > Using Blender I added a texture to one of the sides of the borgbox, and > > finally exported to *.lwo format. The texture did not appear in > > osgviewer. Looking at the resulting *.lwo file in a hex editor showed > > that apparently the UV coordinates were present in the exported file, but > > I could see no reference to the image file, and the file size is > > obviously too small for the > > image to be embedded. I don't know if this is a feature of Blender's > > *.lwo exporter, or a feature of osgviewer. Would it be possible to post a > > link to a > > *.lwo file that also has textures? > > Should be no need, just put the image in there next to the model and it > will very probably find it for itself. In a genuine and correctly formed > .lwo the image names will be in there somewhere. As I said the .lwo file that Blender generated did _not_ contain any reference to the texture image, so I don't think that putting the image in the same path as the .lwo file will work. This could of course be because I'm not using Blender correctly, but I think that is irrelevant. We want to test .lwo files created by LightWave, not .lwo files created by Blender. I'm only using Blender because I don't have LigthWave. I guess I could download the trial version of LightWave, but since I'm so lazy ;-) I just ask someone else to do that work for me. -- Roy Vegard Ovesen -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
On Friday 06 February 2009 23:01:26 Vivian Meazza wrote: > > Osgconv also works, at least it does for .lwo -> .ac, but again no textures > to test. Using Blender I added a texture to one of the sides of the borgbox, and finally exported to *.lwo format. The texture did not appear in osgviewer. Looking at the resulting *.lwo file in a hex editor showed that apparently the UV coordinates were present in the exported file, but I could see no reference to the image file, and the file size is obviously too small for the image to be embedded. I don't know if this is a feature of Blender's *.lwo exporter, or a feature of osgviewer. Would it be possible to post a link to a *.lwo file that also has textures? -- Roy Vegard Ovesen -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] overflow in Instrumentation/gps.cxx
On Saturday 03 January 2009 19:21:08 James Turner wrote: > On 3 Jan 2009, at 18:10, Csaba Halász wrote: > > But you credited it to the wrong person ... > > Ooops, yes. > > Apologies to Roy and Ron for the confusion. > > (I could make a poor excuse about names that start 'Ro-' and end with > '-sen', but I think I'd be laughed at) > "marginally less silly" ;-) IMHO this is the most elegant code I've submitted in a lng time, but if it's only marginally less silly, then perhaps I don't mind not getting credit for it. :-D (I'm joking of course.) -- Roy Vegard Ovesen -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] overflow in Instrumentation/gps.cxx
On Friday 02 January 2009 18:32:58 Csaba Halász wrote:
> 0x007e1c50 in GPS::updateTTWNode (this=0xce164c0,
> c...@0x7fff664fdee0, distance_m=12822604.584446406,
> no...@0x7fff664fddd0) at src/Instrumentation/gps.cxx:483
> 483 unsigned int TTW_seconds = (int) (TTW + 0.5);
> (gdb) p TTW
> $10 = 62278235905.950584
>
> Not sure what it is calculating anyway. This happened with the
> hurricane just at startup.
> And all the "while" loops look silly too.
Please apply this patch to extract the hours minutes and seconds without using
silly while loops.
--
Roy Vegard Ovesen
diff --git a/src/Instrumentation/gps.cxx b/src/Instrumentation/gps.cxx
index 913aba7..424ed3e 100644
--- a/src/Instrumentation/gps.cxx
+++ b/src/Instrumentation/gps.cxx
@@ -485,14 +485,9 @@ GPS::updateTTWNode(UpdateContext& ctx, double distance_m, SGPropertyNode_ptr nod
unsigned int TTW_minutes = 0;
unsigned int TTW_hours = 0;
char TTW_str[9];
- while (TTW_seconds >= 3600) {
-TTW_seconds -= 3600;
-TTW_hours++;
- }
- while (TTW_seconds >= 60) {
-TTW_seconds -= 60;
-TTW_minutes++;
- }
+ TTW_hours = TTW_seconds / 3600;
+ TTW_minutes = (TTW_seconds / 60) % 60;
+ TTW_seconds = TTW_seconds % 60;
snprintf(TTW_str, 9, "%02d:%02d:%02d",
TTW_hours, TTW_minutes, TTW_seconds);
node->setStringValue(TTW_str);
--
___
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 Wednesday 17 December 2008 23:04:28 John Denker wrote:
> A couple more six-legged crawly things:
>
> 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.
Unfortunately I am unable to build FG at the moment but I think this patch
will display the target altitude at initialisation.
diff --git a/Aircraft/Generic/kap140.nas b/Aircraft/Generic/kap140.nas
index 1b76255..1e129c9 100644
--- a/Aircraft/Generic/kap140.nas
+++ b/Aircraft/Generic/kap140.nas
@@ -226,7 +226,7 @@ var apInit = func {
annunciatorFpm.setBoolValue(0);
annunciatorAlt.setBoolValue(0);
annunciatorAltArm.setBoolValue(0);
- annunciatorAltNumber.setBoolValue(0);
+ annunciatorAltNumber.setBoolValue(1);
annunciatorGs.setBoolValue(0);
annunciatorGsArm.setBoolValue(0);
annunciatorPtUp.setBoolValue(0);
> 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.
Displaying the target altitude at all times will of course still result in the
beeping as you describe, but I guess it will be more expected. Can you
confirm that the RW KAP-140 behaves like this?
> 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.
I was too lazy to document all the features, so I just pointed to the Pilot's
Guide :-) Feel free to add a mention of the altitude alerter in the Wiki.
--
Roy Vegard Ovesen
--
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: source/src/Navaids navdb.cxx, 1.27, 1.28 navdb.hxx, 1.11, 1.12 navlist.cxx, 1.21, 1.22 navlist.hxx, 1.17, 1.18 navrecord.cxx, 1.1, 1.2 navrecord.hxx, 1
On Saturday 13 September 2008 10:49:54 James Turner wrote:
> I'm getting more and more encouraged to write a set of course and
> bearing helpers to deal with the normalisation and differencing. I've
> lost count of the number of times I've seen the:
>
>if ( az1 > 180.0) az1 -= 360.0;
>if ( az1 < -180.0) az1 += 360.0;
>
> Idiom repeated in the code, and lots of classes already have helpers
> for this - the KLN-89b and Mk-VIII, for example. Maybe there's some
> standard ones in SimGear I haven't spotted yet?
There is
// normalize a value to lie between min and max
template
inline void SG_NORMALIZE_RANGE( T &val, const T min, const T max ) {
T step = max - min;
while( val >= max ) val -= step;
while( val < min ) val += step;
};
in simgear/sg_inlines.h
--
Roy Vegard Ovesen
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GIT
On Wednesday 27 August 2008 12:26:34 Frederic Bouvier wrote: > I am not saying it is useless. It is just that nobody explained me the > benefits of using GIT over a well known system such as CVS and SVN. I am > aware of the serious lacks of CVS, that's why I am advocating switching to > SVN. Now someone has to explain why GIT is superior. A wiki page would be > just fine. Linus Torvalds' talk about git: http://www.youtube.com/watch?v=4XpnKHJAok8 Try to ignore Linus' bashing of cvs and svn (and the apparent aesthetic qualities of their users). Focus on the distributed part! Randal Schwartz's talk: http://video.google.com/videoplay?docid=-352944619245780 Intro to Distributed Version Control (Illustrated): http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/ -- Roy Vegard Ovesen - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] xmlauto.cxx
On Tuesday 05 February 2008, LeeE wrote:
> Thanks for the updates to xmlauto.cxx.
>
> As well as fixing the reload bug in cvs, the enabled tag for the
> filters is very useful.
>
> Would it be possible to add a null filter type i.e. a filter that
> acts as a simple pass-though?
Try the attached diff. This adds a new filter type named pass. It only needs
an input and an output. Something like this:
pass-through-filter
false
pass
/instrumentation/airspeed-indicator/indicated-speed-kt
/autopilot/KAP140/settings/airspeed-kt
> The reason I think this would be useful is that it would provide a
> very low-cost method of re-routing control inputs between different
> sub-systems and controllers - the sort of stuff you really need to
> do in Fly-By-Wire/Flight Control Systems.
>
> Also on my wish-list for this area would be the ability to change
> some of the pid controller parameters 'in-flight' without having to
> re-load the A/P e.g. reducing elevator control gain as airspeed
> increases. Because the resolution/frequency of the controllers is
> effectively limited by the frame-rate there can be practical
> difficulties in tuning a controller to work optimally over wide
> ranges such as you'd get with most of the fast jets - typically
> ~120-150kts during approach and landing up to 700kts (AFAIK YASim
> doesn't do supersonic so I don't try to seriously tune for the
> supersonic regime).
Thats an interesting thought. We could do soething like this:
10.0
...
for the parameters that are to be exposed on the property tree. Any parameter
without the prop attribute gets a constant value as before. Nasal can be used
to change the value of the exposed parameters.
Another method could be:
/autopilot/KAP140/settings/controller01-gain
10.0
...
which is consistent with how it's done for the input to the PID controllers,
but this will break all autopilots.
> Just for info, while re-working the YF-23 I've been playing with
> using closed feedback loop pid controllers as flight surface and
> engine control drivers/servos with some good results:)
>
> The config below is what I'm using as an elevator input driver/servo
> (there's also an identical controller for elevator-trim input,
> aileron input, rudder input and throttle & reheat control inputs)
> and so far it's working pretty well here.
>
>
> Ruddervator Surface Driver
> false
>
> /autopilot/FCS/locks/elevator
> true
>
>
> /autopilot/FCS/controls/flight/elevator-norm
>
>
> /autopilot/FCS/internal/target-elevator-norm
>
>
> /autopilot/FCS/controls/flight/elevator-norm
>
>
> 0.05
> 0.45
> 0.1
> 0.1
> 0.0
> 0.05
> 0.0
> -1.0
> 1.0
>
>
Of course now you can do that with a filter, which should be simpler an less
expensive.
--
Roy Vegard Ovesen
? xmlauto.diff
Index: xmlauto.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Autopilot/xmlauto.cxx,v
retrieving revision 1.28
diff -p -u -r1.28 xmlauto.cxx
--- xmlauto.cxx 4 Feb 2008 20:01:20 - 1.28
+++ xmlauto.cxx 5 Feb 2008 18:49:01 -
@@ -662,6 +662,8 @@ FGDigitalFilter::FGDigitalFilter(SGPrope
filterType = movingAverage;
} else if (cval == "noise-spike") {
filterType = noiseSpike;
+} else if (cval == "pass") {
+filterType = pass;
}
} else if ( cname == "input" ) {
input_prop = fgGetNode( child->getStringValue(), true );
@@ -683,11 +685,15 @@ FGDigitalFilter::FGDigitalFilter(SGPrope
void FGDigitalFilter::update(double dt)
{
-if ( input_prop != NULL &&
- enable_prop != NULL &&
- enable_prop->getStringValue() == enable_value) {
+if ( (input_prop != NULL &&
+ enable_prop != NULL &&
+ enable_prop->getStringValue() == enable_value) ||
+ (enable_prop == NULL &&
+ input_prop != NULL) ) {
+
input.push_front(input_prop->getDoubleValue());
input.resize(samples + 1, 0.0);
+
if ( !enabled ) {
// first time being enabled, initialize output to the
// value of the output property to avoid bumping.
@@ -696,11 +702,6 @@ void FGDigitalFilter::update(double dt)
}
enabled = true;
-} else if (enable_prop == NULL &&
- input_prop != NULL) {
-input.push_front(input_prop->getDoubleValue());
-input.resize(samples + 1, 0.0);
-enabled = true;
} else {
Re: [Flightgear-devel] autopilot controller & filter weirdness
On Friday 11 January 2008, Curtis Olson wrote: > On Jan 11, 2008 3:14 PM, Roy Vegard Ovesen wrote: > > Try commenting out the call to build() from the code that you quoted > > above. > > build() is called inside init(), so there should be no need to call it > > again > > after init(). > > I suspect the build() is there so you can change the autopilot config file > while flying and reload it. That way you don't need to restart the sim to > fiddle with the gains. > > Curt. Yes, but there is no need to call build() two times in order to reload. I did a simple test revealing that after an autopilot reload, components contained twice as many elements as before the reaload. As would be expected by calling build() twice. I firmly belive that the call to build() in FGXMLAutopilot.reinit() should be removed. -- Roy Vegard Ovesen - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot controller & filter weirdness
On Friday 11 January 2008, LeeE wrote:
> I've had a look at the relevant code but as I'm not up on c++ I'm
> not sure about what I'm looking at but at lines 798-802 there's:
>
> void FGXMLAutopilot::reinit() {
> components.clear();
> init();
> build();
> }
>
> I could find init() & build() and thought that components.clear()
> must be what removes old instances and must be a more generic
> function. However, when I grepped through the SimGear & FlightGear
> source the only occurrence I could find of this function was at
> that single point in xmlauto.cxx. I then searched for
> components.clear() in C/C++ reference manuals on the web and didn't
> find anything there either. Perhaps I just wasn't looking in the
> right place though.
>
> In any case, it seems strange to me that if components.clear() is a
> generic function, it's only used in this one place in the entire
> SG/FG source.
Actually it's only the clear() part that it "generic". clear() is a method of
the vector template.
> I might be barking up the wrong tree entirely here, but I can't see
> what else might be causing the behaviour I'm seeing.
Try commenting out the call to build() from the code that you quoted above.
build() is called inside init(), so there should be no need to call it again
after init().
--
Roy Vegard Ovesen
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] two issues (bugs?) with fresh osg, Simgear, flightgear
On Monday 07 January 2008, dave perry wrote:
> 2. Some aircraft-defined keyboard toggles work only once in osg branch
>
> Examples: pa24-250-set.xml and the pa28-161 both use the keys "!",
> "@", "#", "$", "%", "^", "(", and ")". With older osg builds and
> current V1.0 and plib builds these work. With yesterdays osg build,
> most of these only work the first time. I tried other AC and some
> of their toggles also only worked the first time. Casaba indicated
> (IRC) with an older osg build, these toggles work repeatedly. By
> the way, the pannel hot spots use the same nasal functions to do the
> toggle and they all still toggle repeatedly.
>
> I have tried both osg 2.2 and osg cvs with the same results on both issues.
Same here. CVS from a couple of weeks ago.
--
Roy Vegard Ovesen
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot filters upset after reloading autopilot
On Tuesday 18 December 2007, LeeE wrote: > Hi all, > > I've noticed recently that after re-loading an autopilot the filters > that are being used seem to be getting a bit 'confused'. I spotted > it when I was comparing the unfiltered input with the filtered > output and saw that the input was stable to 2 decimal places but > the filtered output seemed to be oscillating very quickly up to the > first decimal place. > > I don't know if this happens with all filter types - all the ones > I've been using are noise-spike types. I've seen something similar after I added an option to the filters on my local branch. Whenever I enable a filter by setting some property to true (just like enabling PID controllers), I see the output from the filter, wich is connected to the control surface, makes the plane do some wild flying. I believe that I need to add some initialization code to the filters so that they behave nicely when they are enabled. I'm working on this. Also I'll remove the build() call in reinit() inless there is a good reason for calling build() twice. -- Roy Vegard Ovesen - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Communicating with IVAO client
On Tuesday 11 December 2007, Pep Ribal wrote: > With this new build I experience a small problem: as it works perfectly > well with the --ivao option, sending the right packets, when it comes to > shutdown FG, an error dump appears in my terminal window. However, if I > run FG without the --ivao option, no error is produced. I'm getting a very similar error when I exit fgfs: *** glibc detected *** build_sdl/src/Main/fgfs: corrupted double-linked list: 0x00d4bcb0 *** === Backtrace: = /lib/libc.so.6[0x2ae1dcd46067] /lib/libc.so.6[0x2ae1dcd47921] /lib/libc.so.6(cfree+0x8c)[0x2ae1dcd4b6fc] /usr/local/lib64/libosg.so.25(_ZN3osg8StateSetD0Ev+0x2d9)[0x2ae1d9efb0f9] build_sdl/src/Main/fgfs[0x4e71d3] build_sdl/src/Main/fgfs[0x4e7261] ... ... And this is with the CVS version. > I assume I've made some mistake, as I'm not familiar with FG > architecture. What I've done exactly is to download the latest stable > source code (0.9.11), and added/edited these few files before compiling, > wich I'm attaching in this mail. I've attached as well the terminal > command-line used and the resulting messages. You seem to be contradicting yourself here as I believe the latest stable, or release, is 0.9.10. Perhaps you mean the 0.9.11-pre1 version. In any case I get a similar error and I of course do not have your IVAO code, so it might not be your fault after all. -- Roy Vegard Ovesen - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for Input/input.cxx
On Sunday 09 December 2007, Melchior FRANZ wrote: > * Roy Vegard Ovesen -- Sunday 09 December 2007: > > I noticed that when I use "sync to VBlank" to restrain the > > framerate to the monitor's update rate, large jumps happen quite > > often when the mouse cursor is warped to the center. > > Not here. Is this with glut or sdl? Does anyone else see that? > I thought we fixed that a while ago. I just recompiled FG "--with-sdl", and the same happens on that version. Note that I _only_ rebuilt FlightGear, _not_ SimGear. Would that make a difference? Also note that it seems to only happen when I enable "sync to VBlank". If I don't enable "sync to VBlank" I get a framerate way over the 60 Hz my monitor is capable of. I believe it's a timing issue. When a jump happens FGInput::doMouseMotion needs to call fgWarpMouse(x, y) two times in order to get the cursor centered. -- Roy Vegard Ovesen - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for Input/input.cxx
On Sunday 09 December 2007, Melchior FRANZ wrote: > * Roy Vegard Ovesen -- Sunday 09 December 2007: > > I noticed that when I use "sync to VBlank" to restrain the > > framerate to the monitor's update rate, large jumps happen quite > > often when the mouse cursor is warped to the center. > > Not here. Is this with glut or sdl? Does anyone else see that? > I thought we fixed that a while ago. > glut. -- Roy Vegard Ovesen - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Patch for Input/input.cxx
Hi,
This patch prevents large jumps when using the mouse to look around the
cockpit, or flying with the mouse.
I noticed that when I use "sync to VBlank" to restrain the framerate to the
monitor's update rate, large jumps happen quite often when the mouse cursor
is warped to the center. This patch ignores such large jumps by not updating
whatever the mouse is bound to if the delta is too big.
--
Roy Vegard Ovesen
0xC21956ABDBDD7827E1973FE65516268A1853A876.asc
Description: application/pgp-keys
Index: input.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/input.cxx,v
retrieving revision 1.99
diff -p -u -r1.99 input.cxx
--- input.cxx 1 Dec 2007 23:37:58 - 1.99
+++ input.cxx 9 Dec 2007 18:11:59 -
@@ -382,13 +382,17 @@ FGInput::doMouseMotion (int x, int y)
// so we can play with it.
if (x != m.x) {
int delta = x - m.x;
-for (unsigned int i = 0; i < mode.x_bindings[modifiers].size(); i++)
- mode.x_bindings[modifiers][i]->fire(double(delta), double(xsize));
+if (abs(delta) < xsize * 0.2) {
+ for (unsigned int i = 0; i < mode.x_bindings[modifiers].size(); i++)
+mode.x_bindings[modifiers][i]->fire(double(delta), double(xsize));
+}
}
if (y != m.y) {
int delta = y - m.y;
-for (unsigned int i = 0; i < mode.y_bindings[modifiers].size(); i++)
- mode.y_bindings[modifiers][i]->fire(double(delta), double(ysize));
+if (abs(delta) < ysize * 0.2) {
+ for (unsigned int i = 0; i < mode.y_bindings[modifiers].size(); i++)
+mode.y_bindings[modifiers][i]->fire(double(delta), double(ysize));
+}
}
// Constrain the mouse if requested
signature.asc
Description: This is a digitally signed message part.
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, John Denker wrote: > > The problem that I am addressing is the fact that an object can not move > > from one position to another in an instant. > > Why? Simply because it's impossible, but if it can move faster than our simulator rate, then it does not matter. Or was this a rhetorical question. :-) > d) slew rate limiting in the hydraulic system ??? > That's something yet again, not mentioned until now. > > e) programmed slew rate limiting in the autopilot ??? > > Since very few of our users have force-feedback joysticks, there > is no realistic way to model (a), (b), or (c) ... and attempting > to model any of those with the suggested low-pass filter is a > bad idea ... worse than no filter at all. > > Item (d) makes more sense; it should be modeled by the FDM on > the few aircraft that actually exhibit a significant amount of > this behavior. This is readily possible in JSBSim. I was not aware of this when I posted my initial RFC. > Item (e) should be modeled within the autopilot. Real autopilots > are sure-as-shootin slew rate limited. ... and this is readily possible in the autopilot configuration using the noise spike filter, where you can set the max rate of change. > > To repeat: > > 1) In the overwhelming majority of aircraft, Asking the FDM to >low-pass filter the controls (to any significant degree) is >unrealistic. > > 2) In the few aircraft where there is a significant limitation >in the fly-by-wire system, sure, go ahead and model it. This >will require a lot more than a low-pass filter. > > 3) As the proverb says, pilots are judged on their smoothness, >not on their quickness. Smoothness is built into the pilots; >it is not usually built into the hardware. -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, Roy Vegard Ovesen wrote: > I think moving a control surface, like for example the rudder, from full > left deflection to rull right deflection in an instant is unrealistic. To > make this more realistic I think we should put in a low pass filter > somewhere in the chain from crontrol device to FDM. My first thought would > be to do the filtering just befir handing the value over to the FDM. Turns out that JSBSim and YASim already has what I'm looking for. My question then is reduced to: why doesn't more FDM modellers use these features of JSBSim and YASim to create cotrol surfaces that seem to have mass -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, David Megginson wrote: > That's true for control surface movement in general, but I had > (mis)understood that Roy was proposing this specifically for the '5' > key -- that's a simulator-specific key that has no real-life > equivalent, so binding it to a new command that has a low-pass filter > would probably be a good idea. We don't have to worry about realism > for this key, just controllability. I mentioned the "5" key only as an example. I am not proposing to put a filter on that command. -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
On Sunday 02 December 2007, John Denker wrote: > That's not a good solution. That's highly unrealistic. > > In real life, in a small airplane, if I decide to stomp on the > rudder pedal, the rudder is going to move real fast. The > realistic time scale is not long compared to 1/30th of a > second i.e. the inverse frame rate. That is to say, any > filter with a realistic timescale wouldn't solve the > problem. OK, thats one end of the scale. How about the other end, a big aircraft with huge control surfaces? The filtering would have to be configurable on at least a per aircraft basis. Possibly on a per control surface basis. > The problem (as usual) lies with the nut behind the steering > wheel. If you don't want the rudder to move real fast, don't > command the rudder to move real fast. > -- Specifically, if the problem is a noisy joystick, fix the > joystick somehow; don't mess up the FDM. > -- If "5" is doing the wrong thing, make "5" do the right > thing. The problem that I am addressing is the fact that an object can not move from one position to another in an instant. That would of course require an unlimited amount of force. -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] RFC: Control surface position damping
When prssing the 5 key on the numeric keypad to reset the controls to zero, the control surfaces instantly move to their origin. Similar effects can also happen when an autopilot controller is activated, and when a noisy joystick is interfering with an autopilot controller. I think moving a control surface, like for example the rudder, from full left deflection to rull right deflection in an instant is unrealistic. To make this more realistic I think we should put in a low pass filter somewhere in the chain from crontrol device to FDM. My first thought would be to do the filtering just befir handing the value over to the FDM. Does anyone on the list have comments on this? -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Informal version number poll
On Friday 30 November 2007, Curtis Olson wrote: > How about a quick, friendly, positive, informal thread here to do a poll on > what what folks are thinking for the next version number. > 1.0 But I allso like the way Ubuntu does it: yy.mm It's simple, informative, and there is no mind games involved. -- Roy Vegard Ovesen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor keyboard reassignment
On Saturday 10 November 2007, gerard robin wrote: > A stupid question: > > Why is it necessary to have a key for lights, isn't it a cockpit feature > with hotspot, and switch ? I'm guessing because pressing a key on the keyboard resembles the gesture of pressing a key inside a cockpit of a real aircraft. -- Roy Vegard Ovesen - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Crash during startup with OSG version
On Thursday 19 July 2007 20:02, Morten Oesterlund Joergensen wrote: > I have very little knowledge about this, but for more than a month ago > did I have a problem, which looks like this one. It turned out that > RoyVegard also had it. > It had something to do with a null pointer in > src/osgUtil/RenderStage.cpp around line 854 in the OpenSceneGraph source > code. > I got FlightGear working again by using osgViewer instead of SDL. I'll just pop in and say that --enable-osgviewer worked for me too. -- Roy Vegard Ovesen - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] On-screen stick deflectionindi cators forautopilot
On Tuesday 03 July 2007 16:12, Reagan Thomas wrote: > Now, how does one go about implementing that? It seems like at least > part of it would have to be done by the person building the aircraft model. I'm guessing it should be fairly trivial. Create a duplicate of the 3D yoke and make it transparent. Bind this new ghost yoke's rotation and position to the joystick position properties. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control lockingbyautopilot
On Thursday 28 June 2007 19:50, woodyst wrote: > With my yoke stopped, with js_demo i see a lot of lines as: > | -0.0 +0.1 +1.0 -1.0 -1.0 +0.0 +0.0 . | > > all of them without changes. Since it only shows one decimal digit, a change of 0.002 would not be shown in js_demo. > > So autopilot may change axis values (because my yoke is not noisy) and > this difference (position 0 of yoke and autopilot setting) may be greater > than a.tolerance, so it vibrates (I think, correct me if it is not > correct). I think you have misunderstood how input.cxx works. It does not look at the difference between the joystick position and the autopilot stick position. It looks at the joystick position from the previous sample and if the joystick hasn't moved more than tolerance, then its new position is not applied. You could hold the joystick in the full right position, far away from the position that the autopilot wants the stick to be in. But if you can hold it still there then input.cxx will not update the position and the joystick will not fight with the autopilot. > > > No, it is not noisy. I have tested it with utils and found that my yoke > > > is very quiet. I think my previous afirmation may be correct. > > > > Very quiet might not be quiet enough. If the noise is more than the > > tolerance value hardcoded into input.cxx (0.002) then you will see what > > you are seeing. > > When I do not touch my yoke it does not pass any event. So there may be > another problem with it. Please probe it by your own keeping your > joystick stopped > (test it with js_demo or something similar). You will see what is my > problem. I have actually seen the problem. My joystick (Thrustmaster® Top GunTM Fox 2 ProTM USB) is actually quiet enough that when it sits on my table untouched in the center position, it does not fight with the autopilot. If I bump the table, jump up and down on the floor, listen to loud crappy music, etc. then it will vibrate, and it will fight with the autopilot. _I_ am still convinced that your joystick is more noisy than the tolerance limit in input.cxx. I have a few suggestions you could try: - If the joystick driver has a dead zone option try that. - Try setting the tolerance limit in input.cxx to a higher value. - Remove the noise from your joystick: clean or replace the pots. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] On-screen stick deflection indicators forautopilot
On Sunday 01 July 2007 17:16, pebble garden wrote: > Here's a picture of what I'm talking about: > > http://userimages.imvu.com/userdata/00/01/03/89/userpics/apStickDeflection_ >0.jpg > > Users could disengage the autopilot anytime they like, but it'd be no > trouble at all to move the joystick box over to the AP stick position > before disengaging. > > Just a thought. Another thought is to have a "ghosted" (50% transparent or something like that) yoke showing the position of the joystick. When the autopilot is desengaged the ghosted yoke would for example be disabled by a simple select animation. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control locking byautopilot
On Wednesday 27 June 2007 23:05, woodyst wrote: > > >> The diffs are at > > >> http://www.eurogaran.com/fgfs/fgfs_ap_joy_locking.diff and > > >> http://www.eurogaran.com/fgfs/kap140_locking_controls_capable.diff AFAIK real life autopilots can be overpowered by the pilot. Wheter this is done by brute force or if the servos can sense that they are being overpowered and then let go, I don't know. Since we don't have any force feedback support in Flightgear, we'll have to make the autopilot sense that it is being overpowered. The hard part will be how to decide that the pilot is trying to overpower the autopilot. One possibility is to press a button to tell that you are overpowering. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch for control locking byautopilot
On Wednesday 27 June 2007 23:05, woodyst wrote: > My yoke is CH Products Yoke. I think (as I see in the code) than > FlightGear tests yoke position every input.cxx pass. > > If it finds that yoke position is different of the virtual yoke it > applies real yoke position. And when the autopilot is changing virtual > yoke it is different. Not quite. It tests if the current joystick position is more than a tolerance value from its previous position. If it is then the joystick position is applied to the "virtual yoke". > No, it is not noisy. I have tested it with utils and found that my yoke > is very quiet. I think my previous afirmation may be correct. Very quiet might not be quiet enough. If the noise is more than the tolerance value hardcoded into input.cxx (0.002) then you will see what you are seeing. -- Roy Vegard Ovesen - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch: don't warn if a soun d is clipped,was Re: For the - Author of Conco rde - Continued (Email inUnicode format)
On Tuesday 29 May 2007 10:22, Erik Hofman wrote: > > Indeed and that's what the warning is for; the author should fix the > sound configuration file. I added beeping from the KAP140 and I see that that sound gets clipped. Here's a diff for the C172p sound configuration file. Please apply. -- Roy Vegard Ovesen Index: c172-sound.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/c172p/c172-sound.xml,v retrieving revision 1.2 diff -p -u -r1.2 c172-sound.xml --- c172-sound.xml 26 Apr 2007 18:04:55 - 1.2 +++ c172-sound.xml 29 May 2007 15:21:00 - @@ -241,11 +241,8 @@ /autopilot/KAP140/annunciators/beep/state - -0.5 - - + - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Weekly CVS Changelog Summary: SimGear
On Sunday 08 April 2007 07:00, Curtis L. Olson wrote: > 2f585eeea02e2c79d7b1d8c4963bae2d > > - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel Empty? Surely there were changes to both Simgear and Flightgear this week. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flasher in nasal
On Friday 06 April 2007 19:53, Melchior FRANZ wrote: > Simpler, yes, though not much. What the code does is similar to > overloading in C++. Two possible argument sets to the same function. > Named args alone wouldn't help here at all. What would help is named > args with default values. But that only works if they are always > used in order, which is not the case here. I assumed that it was possible to name the arguments when calling the function, like in Python. And that you could then give them in arbitrary order. How do I add a argument to the aircraft.light.new method? If I add it before then that will certainly break things. If I add it after then is no longer optional. Another solution would be to set the last element of the pattern to the number of times to repeat the pattern, -1 meaning repeat forever. But that will also break things. Third option is to set the last element in pattern to the negative number of times to repeat. [0.5, 0.5, -3], repeat 3 times. [0.5, 0.5], repeat forever. This avoids breaking stuff. But now it's becoming hairy. :-( -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flasher in nasal
On Friday 06 April 2007 18:28, Melchior FRANZ wrote: > > Why don't you use the sophisticated aircraft.light flasher? > Re-inventing the wheel? :-) Didn't know about that wheel ;-) After playing around with it a bit I see that it does not quite meet the requirements that I have. I need to blink an arbitrary number of times and then stop in either the on or off state. As far as I can see the aircraft.light class loops through the pattern forever. I assume that you are the author of aircraft.nas. I want to add a new method to the light class where one can go through a pattern an abritrary number of times. Or is that already possible somehow? I see that aircraft.light uses typechecking and stuff to extract the correct arguments. Wouldn't this be much simpler with named arguments instead of arg[]? -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flasher in nasal
Hi
I'm trying to create a new flasher for the KAP140 autopilot. This is what I
have so far:
NewFlasher = {};
NewFlasher.new = func {
obj = { parents : [NewFlasher],
count : 0,
times : arg[1],
property : arg[0] };
return obj;
}
NewFlasher.flash = func {
if (me.count < me.times)
{
if (me.property.getValue() == 0)
{
me.property.setBoolValue(1);
}
elsif (me.property.getValue() == 1)
{
me.property.setBoolValue(0);
}
me.count = me.count + 1;
print(me.count, "\n");
settimer(me.flash, 1.0);
}
}
testFlasher = NewFlasher.new(annunciatorBeep, 100);
testFlasher.flash();
When i call the flash() method it executes fine the first time, but the second
time, when it is being called from settimer(), I get this error:
Nasal runtime error: undefined symbol: me
at /blah-blah/Aircraft/Generic/kap140.nas, line 138
Line 138 is the first if statement in flash().
--
Roy Vegard Ovesen
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Error building FG
On Thursday 05 April 2007 21:02, Alex Romosan wrote: > there are two patches i posted. you need to apply both. > > --alex-- I'm sorry, I can not extract the patches from the mailing list archives on Sourceforge. Can you please repost them here on the devel-list? -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Error building FG
On Thursday 05 April 2007 01:40, Gabor Toth wrote: > Hi, > > I've got the hint on the IRC channel from Jester to use OSG revision 6398 > to avoid this error. It worked for me. > > Regards, > Gabor Thanks! That worked fine. I tried the patch from the users list first, but while it got past model_panel.cxx I gor similar errors on Main/renderer.cxx. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Error building FG
Hi I get this error when bulding Flightgear: Making all in Model make[2]: Entering directory `/home/royvegard/src/FlightGear/source/src/Model' if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -I/usr/local/include -g -O2 -D_REENTRANT -MT model_panel.o -MD -MP -MF ".deps/model_panel.Tpo" \ -c -o model_panel.o `test -f 'model_panel.cxx' || echo './'`model_panel.cxx; \ then mv -f ".deps/model_panel.Tpo" ".deps/model_panel.Po"; \ else rm -f ".deps/model_panel.Tpo"; exit 1; \ fi model_panel.cxx: In function 'osg::Node* load_panel(SGPropertyNode*)': model_panel.cxx:28: error: cannot allocate an object of abstract type 'FGPanelNode' panelnode.hxx:23: note: because the following virtual functions are pure within 'FGPanelNode': /usr/local/include/osg/Drawable:425: note: virtual void osg::Drawable::drawImplementation(osg::RenderInfo&) const make[2]: *** [model_panel.o] Error 1 make[2]: Leaving directory `/home/royvegard/src/FlightGear/source/src/Model' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/royvegard/src/FlightGear/source/src' make: *** [all-recursive] Error 1 I'm on Gentoo. OSG and friends are from CVS/SVN. Flightgear and Simgear are from CVS. The rest of the dependencies are from Portage (Gentoo packages). -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] access to flightgear-cvslogs
On Sunday 01 April 2007 15:02, gh.robin wrote: > hello, > > Trying to access to > http://sourceforge.net/mailarchive/forum.php?forum=flightgear-cvslogs > > I get > > > > > * SF.net > * Error > > Error > > ERROR > > No Forum Chosen > < > > Where is the error. > > Regards. Try http://sourceforge.net/mailarchive/forum.php?forum_name=flightgear-cvslogs It looks like SF changed their argument from forum to forum_name at some time. On the same note; the links to the mailing-list archives on the Flightgear website are also wrong. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter - encoder - kap140.nas
On Saturday 24 March 2007 04:01, Dave Perry wrote: > Hi all, > > Does anyone know what happened to John Denker? I am still interested in > the improved altimeter/atmosphere model being added to FlightGear. I > keep adding these back in after cvs/svn updates. I think we should ask someone to add these changes into cvs now. All the patches from John Denker should be available from his web site http://www.av8n.com/fly/fgfs/ -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] encoder/altimeter & kap140.nas
On Saturday 03 March 2007 08:31, Melchior FRANZ wrote:
> I don't think it can be applied as it is. I'm no physicist and
> can't comment on the logic, but there are some formal aspects
> to fix IMHO:
>
> atmo.?xx:
>
> - code on the top level must not be indented
> - proper indentation everywhere (Frankly, 2 spaces aren't enough
> for my taste. They produce visual spaghetti code.)
I'll add:
There is a mixture of tabs and spaces here too.
> - comments in a block shall be indented aligned with the block,
> not begin in column 0
> - if (a_tvs_p) delete a_tvs_p; shall be just delete a_tvs_p;
> - cout/cerr must not be used (use SG_LOG with proper log level)
I believe that MSVC needs the iterator to be declared before the loop:
int i;
for (i = 0; ; i++)
> - for (int ii = 0; ; ii++) shall be for (int i = 0; ; i++)
> - don't add empty *and* commented out class definitions
>
> altimeter.cxx:
>
> - don't introduce tab indentation in a file that uses 4 spaces
> - if qqq stands for "quantum, then call it quantum:
> Altimeter::Altimeter ( SGPropertyNode *node, const double qqq)
If qqq is going to default to 10 (from instrument_mgr.cxx: new Altimeter(
node , 10)), I think we can just drop it all together and put
_quantum(node->getDoubleValue("quantum", 10)) in altimeter.cxx.
--
Roy Vegard Ovesen
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sunday 25 February 2007 06:30, Dave Perry wrote: > I want both John and Roy to try this patch before we consider submitting > it to cvs. Of course, anyone can try it and comment. I had a nice flight over Norway today from ENHD to ENTO. ATIS at ENHD told med that baro setting should be 29.50. So I set the altimeter and the KAP140 to that. I set the altitude preselect to 7000 ft and took off. The altitude was captured at approx. 6980 ft and settled at that altitude. A single press of the UP button took me upt to 7000 ft as indicated by the altimeter. Visiblility at ENTO was very bad, so I had to use ILS. In addition I was unable to head what the nice lady was saying in the ATIS at ENTO, so I didn't know what the altimeter setting should have been. The KAP140 steered me down towards the runway in approach mode. At the middle marker I disengaged the autopilot, still no runway visible through the fog. I continued down not knowing my altitude, when I see the blue ocean. Dang! I haven't downloaded the scenery for that part :-( -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sunday 25 February 2007 19:44, John Denker wrote: > Parts? I didn't know the class has an altimeter part separate > from the encoder part. The class can be /configured/ to be one > or the other. It cannot and should not be configured to be both. I suggested an encoding altimeter as an instance that has both. Do you think that makes sense? > > > AFAIK an encoder never outputs > > indicated altitude. > > 1) We can agree that /usually/ the encoder does not put out indicated > altitude. But there *are* backup altimeters that do display an > indicated altitude derived from the encoder (quantization and all). > This is not super-important. > > 2) The main reason for that feature was (a) because it was easy to do, and > (b) to make life super-easy when writing autopilot code, so that the > Kollsman shift could be calculated in one simple step, by subtraction. > If the autopilot authors are not interested in doing that, they are > requested to please ignore the indicated altitude output. Please > don't complain about "bugs" in something that is both realistic and > harmless. > > I've heard opinions, but I haven't heard any explanation of why > quantizing the pressure altitude is either unrealistic *or* unhelpful. I have not, and I don't think Dave Perry has either, expressed optinions to indicate that the pressure altitude should not be quantized. What we have said is that indicated altitude should not be quantized. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sunday 25 February 2007 06:30, Dave Perry wrote: > > I want both John and Roy to try this patch before we consider submitting > it to cvs. Of course, anyone can try it and comment. Is the encoder > used anywhere other than by the KAP140? If so, we should use a separate > instantiation as suggested by John. About the old encoder. I was thinking we could print a message to the console that this instrumentation module is depricated and wil be removed in a future version (or something like that). -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altimeter, encoder, and kap140
On Sunday 25 February 2007 17:49, John Denker wrote: > On 02/25/2007 08:39 AM, Dave Perry wrote: > >>> I also rearranged the truncation of pressure altitude in John's code so > >>> the indicated altitude is computed before the pressure altitude is > >>> rounded and saved. John, you may have already caught and corrected > >>> this bug. > > This is not a bug. It was my intent to model an encoder that > rounds the pressure altitude, just as it happens in real life. I have to agree with Dave on this. The indicated altitude should _not_ be quantized. The indicated altitude "belongs" to the altimeter part of the class, and _not_ to the encoder part. AFAIK an encoder never outputs indicated altitude. > > > You must not have realy tried your patch in this area. Your patch used > > the rounded PA to compute the indicated altitude. That makes the > > altimeter jump in 10 ft jumps. > > 1) I did test my code. > > 2) Yes, the altitude coming off the digital encoder does jump. > In real life, one sometimes sees backup altimeters that are > based on the output of the encoder. They jump. This is not > a bug. It's just how things work. Knowing very little about backup altimeters, I would say that such an altimeter based on the output from the encoder would be a fully electronic device. Consequently it should have its own class, being so fundamentally different from a "normal" altimeter (tied to the static port and all). > > I say again: > -- If you want an analog "steam gauge" altimeter, use an /instance/ >of the altimetry object configured to do that. > -- If you want a digital encoder, use an /instance/ of the altimetry >object configured to do that. > -- Do not expect a single /instance/ to both jump and not jump. What about an encoding altimeter, shouldn't that be able to have an indicated altitude that is not quantized and pressure altitude that is quantized!? > As an almost-separate matter, I have a question for the community: The > question is whether the configuration option should be removed > from the new altimeter object. > ++ The argument for keeping it is that real encoders do quantize the >pressure altitude. So writing the quantized pressure altitude to the >property tree, as my code does, must be considered realistic. > -- The argument for removing it is that if users consider realistic >behavior to be a bug, there's no point in offering the behavior. > -- Also, the c++ implementation isn't necessary, because if the autopilot >wants to round the indicated altitude, it can do so. That's at most >one line of nasal code. > -- Similarly, if the autopilot wants to round the pressure altitude, >it can find the Kollsman shift (by subtracting pressure altitude from > indicated altitude), round the pressure altitude, and add the Kollsman >shift back in. In the worst case that's three lines of nasal code, >usually less. > > > Any opinions? Other suggestions? Keep it! -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot, Was: C172p stra nge behaviour with --flight-plan
On Sunday 11 February 2007 02:14, leee wrote: > I thought I'd give it another go, with debug on the pitch-hold controller > and waddya know - this time the pitch hold worked and the alt hold failed. > > Ok - so I set debugging on all three of the pitch related controllers and > on the next test it was back to the pitch hold problem again but with no > heading hold either. Anyway, there was no output from the pitch hold > controller although I could see the climb rate and altitude controllers > come in as they were engaged. Are you able to run inside a debugger and step through the FGPIDController::update() method in source/src/Autopilot/xmlauto.cxx to see what is going on. > > I paused the sim once I was above the target altitude, inserted some blank > lines into the debug o/p, so I could find the point again, and reset the > a/p. After doing this I could then see debug o/p from the pitch controller. > > Do you want to see the debug o/p? Gérard posted his output, so I don't think I need to see your. -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Sunday 11 February 2007 00:29, gh.robin wrote: > I have settled Heading Bug =180 > autopilot does not work (crazy) > > I get messages > here an extract > > .. > Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 > input = -0.128936 ref = 0 > ep_n = 0.128936 ep_n_1 = 0.129309 e_n = 0.128936 ed_n = 0.128936 Tf = > 1e-06 edf_n = 0.128936 delta_u_n = -1.58609e-05 > P:-3.73499e-05 I:2.14893e-05 D:-2.32856e-10 > output = 0.000653603 > Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 > input = -0.12854 ref = 0 > ep_n = 0.12854 ep_n_1 = 0.128936 e_n = 0.12854 ed_n = 0.12854 Tf = 1e-06 > edf_n = 0.12854 delta_u_n = -1.81036e-05 > P:-3.95257e-05 I:2.14234e-05 D:-1.30541e-09 > output = 0.000635499 > .. The autopilot is holding the wings level, right. I think characterizing this as "crazy" is very misleading. One might think that it was turning left and right. > And after reloading autopilot > autopilot works > > I get messages > Here an extract > .. > > Updating Heading Bug Hold (DG based) Stage 1 Ts 0.017 > input = -86.2699 ref = 0 > ep_n = 86.2699 ep_n_1 = 86.3099 e_n = 86.2699 ed_n = 86.2699 Tf = 1e-06 > edf_n = 86.2699 delta_u_n = -0.103803 > P:0.0399801 I:-0.143783 D:1.29082e-08 > min saturation > output = -20 > Updating Heading Bug Hold (DG based) Stage 2 Ts 0.017 > input = -17.7823 ref = -20 > ep_n = -2.21771 ep_n_1 = -2.22147 e_n = -2.21771 ed_n = 17.7823 Tf = > 1e-06 edf_n = 17.7823 delta_u_n = 6.21317e-06 > P:0.000375831 I:-0.000369619 D:9.22063e-10 > output = -0.00492783 > ... > > > I can notice with the first example (before reload) only stage2 gives > messages > > With second example (after reload) with autopilot working i do have both > stage1 and stage2 It looks like the stage 1 controller fails to initialize at startup. Is this consistent, or are you, like Lee was, seeing some randomness in what controllers aren't working before autopilot reload? > > If you are getting crazy inputs and outputs, you should run fgfs in a > > debugger like ddd and step through the FGPIDController::update() method > > in source/src/Autopilot/xmlauto.cxx to see what is going on. > > Because i am not developer , i will not be able to do it Sure you can! ;-) -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Saturday 10 February 2007 01:08, gh.robin wrote: > Hello Roy, > I do not notice any differences regarding /autopilot/new-config dir > between first load values (after FG loaded) and after reload autopilot. > > i get two pi-simple-controllers and sixteen pid-controllers. OK, you said that the heading hold in the dc3 was "crazy". The dc3 uses the generic autopilot, then all aircraft using the generic autopilot should experience the same crazieness in heading hold mode. Could you try activating the debug option of the two pid-controllers that are used in heading hold mode? Open data/Aircraft/Generic/generic-autopilot.xml and set the debug flag to true for the controllers named "Heading Bug Hold (DG based) Stage 1", and "Heading Bug Hold (DG based) Stage 2". When you activate the heading hold mode you should get debug messages from those two controllers on the console. This is what I get when I'm in a left turn chasing the heading bug in the dc3 (# My comments): Updating Heading Bug Hold (DG based) Stage 1 Ts 0.0416667 input = -50.076 ref = 0 # We are -50.076 degrees from our desired heading. ep_n = 50.076 ep_n_1 = 50.1743 e_n = 50.076 ed_n = 50.076 Tf = 1e-06 edf_n = 50.076 delta_u_n = -0.110384 P:0.0982607 I:-0.20865 D:5.29441e-06 min saturation output = -20 # The controller has commanded a 20 degree left bank. Updating Heading Bug Hold (DG based) Stage 2 Ts 0.0416667 input = -16.6732 ref = -20 # We are currently at 16.6732 degrees left bank. ep_n = -3.32684 ep_n_1 = -3.34097 e_n = -3.32684 ed_n = 16.6732 Tf = 1e-06 edf_n = 16.6732 delta_u_n = 2.75638e-05 P:0.00141368 I:-0.00138618 D:6.68812e-08 output = -0.00296141 # This is the commanded aileron, a tiny bit of left aileron makes sense. # 0.03 seconds later: Updating Heading Bug Hold (DG based) Stage 1 Ts 0.033 input = -49.9996 ref = 0 ep_n = 49.9996 ep_n_1 = 50.076 e_n = 49.9996 ed_n = 49.9996 Tf = 1e-06 edf_n = 49.9996 delta_u_n = -0.09026 P:0.0764119 I:-0.15 D:-6.55459e-06 min saturation output = -20 Updating Heading Bug Hold (DG based) Stage 2 Ts 0.033 input = -16.6844 ref = -20 ep_n = -3.31557 ep_n_1 = -3.32684 e_n = -3.31557 ed_n = 16.6844 Tf = 1e-06 edf_n = 16.6844 delta_u_n = 2.10212e-05 P:0.0011263 I:-0.00110519 D:-8.62141e-08 output = -0.00294038 As you can see the inputs and outputs to/from these controllers look reasonable. Are you getting crazy inputs and outputs when you try the same? And are you getting sane inputs and outputs after a autopilot reload? If you are getting crazy inputs and outputs, you should run fgfs in a debugger like ddd and step through the FGPIDController::update() method in source/src/Autopilot/xmlauto.cxx to see what is going on. -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] autopilot, Was: C172p strange behaviour with --flight-plan
On Friday 09 February 2007 21:13, leee wrote: > Just tried another quick test. > > Opened five property browsers - autopilot/locks, autopilot/settings, > autopilot/internal, autopilot/FCS/locks & autopilot/FCS/controls - all > seemed ok but then I pre-set most of the nodes during aircraft > initialisation. The one I asked Gérard to look at was /autopilot/new-config. When you have pinpointed that a certain controller is not outputting what it should, look in /autopilot/new-config to see if the controller is actually there. If it is there, try enabling the debug option for that controller. > > On this test the altitude hold failed to work. The altitude hold > controller reads the filtered target alt and outputs to > autopilot/settings/target-climb-rate-fps. When the altitude hold > controller was engaged it failed to update the target climb rate. Agl > hold, which also outputs to the same target climb rate node in > autopilot/settings, was ok and I could see the node being updated. > > I switched back to altitude hold and forced a climb by over-typing a +ve > climb rate into the non-updating node. Once I got to around 10k ft I reset > the A/P and the climb rate started updating. It looks like the controllers are not getting built correctly at FG startup. When you do a autopilot-reset, the controllers in /autopilot/new-config are cleared and the autopilot config xml file is re-read and the controllers re-built. -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 20:22, leee wrote: > > It's difficult to imagine a system problem that might cause this behaviour, > in view of the fact that resetting appears to fix the problem. > > However, I know that there are a few problems that I've seen here that no > one else appears to have experienced on their systems, one long running > example being problems with the wind and visibility settings not being > honoured. > > If it is a system problem, I simply don't know where to start looking. > Could a compiler problem cause this? It's the only thing I can think of in > view of the fact that I'm using Debian Stable and the gcc version is pretty > old. I'm not sure that would explain the history of the problem either, > that is, it was working ok then stopped working ok. > > I'm afraid I can't do a lot of testing for you on this. I just tried the SU-37, and the autopilot seemed to work OK. I have not been able to reproduce the problems that you and Gérard are having with the autopilot, so it looks like I can't do _any_ testing on this. :-( Could you try the tip I suggested to Gérard about looking at the controllers before and after autopilot reload? -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 19:26, gh.robin wrote: > Hello Roy , > Every Aircraft which basicaly use the Generic autopilot (no KAP140 or > else). > > I tested it with a lot of the nice aircraft from Lee which do not work > and among the others examples > the dc3 Autopilot is right with Altitude but crazy with Heading. I just tried the dc3. Heading hold is working "perfectly". Could there be something on your and Lee's system that is causing this? I tried the first time you reported this issue, and was unable to reproduce what you saw then too. Are anyone else on this list seeing the problems that Lee and Gérard are seeing? > > Like i noticed before, if during the flight if i try to get an autopilot > with heading , i reload /menu/bug/autopilot and i get the autopilot > working. Could you check the property browser before and after you reload the autopilot? Look at the /autopilot/new-config dir. Are all the controllers there prior to reloading the autopilot? (In the cd3 I see two pi-simple-controllers and sixteen pid-controllers.) -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 18:24, leee wrote: > > Hi Roy, > > I am getting this with the SU-37 and I believe the version in cvs displays > the problems. This is a pretty complex A/P setup with cascading up to > three levels and it also includes filters to un-tie some tied nodes so that > I could use listeners on the preperties. There are also still some > redundant controllers in there as well, just to confuse matters further. Could you be more specific? Witch of the 21 pid controllers are not working in the SU-37 autopilot? Also could you tell me how to use the autopilot(s) in the SU-37? From the readme I gathered that it can be cotrolled from the mini-panel, but I'm unable to get the mini-panel to show, I tried "c" but that didn't seem to work. -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p strange behaviour with --flight-plan
On Friday 09 February 2007 02:54, Dave Perry wrote: > On Fri, 2007-02-09 at 00:25 +, leee wrote: > > Just checked again, with current cvs osg/simgear/flightgear, and I still > > got the same problems. As before, re-setting the A/P via the menu seems > > to kick everything into life. There also seems to be a random element to > > this problem - in half a dozeeen tests, most of the time it was the same > > controllers that seemed not to be working but in two tests there seemed > > to be a couple of additional ones that didn't want to play. > > The power check I added to kap140.nas moves the call to initialize the > autopilot (apInit) to inside the apPower loop. apPower is called by a > setlistener that monitors power="/systems/electrical/outputs/autopilot > to makes sure there is power to the autopilot before starting the power > monitor apPower to prevent a "nil used in numeric context" nasal > error. I believe that the problem Gérard and Lee has seen is not specific to the KAP140 autopilot. apInit in kap140.nas _only_ initializes the properties that belong to the KAP140 autopilot. The initialization that Durk is talking about is certainly not the same as apInit. So far I have been unable to reproduce this. Lee and Gérard, could you please tell us what aircraft you are seeing this with. Is it aircraft that use the generic autopilot and/or aircraft that use a customized autopilot? -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier. Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] removal ofInstrumentation/annunciator.[ch]xx
On Monday 29 January 2007 17:37, Melchior FRANZ wrote: > I'd like to remove the annunciator instrument from the C++ > sources and replace it with a Nasal version. Obviously, I agree. :-) -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot broken by recent osg branch fgfsupdate
On Tuesday 23 January 2007 16:00, gh.robin wrote: > On Tue 23 January 2007 03:27, Dave Perry wrote: > > I updated both SimGear, fgfs source, and data for the osg branch > > yesterday. After the compiles and installs with no errors, none of the > > autopilots are working. This includes the default autopilot from the > > gui as well as the kap140 (I am testing the new version from Roy Vegard > > Oveson). All were working before the cvs update. The kap140 files are > > from before the update. > > > > I tried the pa28-161 with the default autopilot and the symptoms were > > the same as with the kap140. > > > > With the PRE_OSG_Plib branch fgfs and the /data from the osg branch > > test, everything still works as expected. > > > > The altitude capture still works but the HDG, APR, and NAV do nothing > > except wing level. Turning the HI heading bug has no affect. The locks > > are updating in the property list. > > > > Are others seeing this behavior? > > > > Regards, > > Hello, Dave > > Yes i did noticed it , and said that bug on that mailing-list, but could > not explain it > > http://sourceforge.net/mailarchive/message.php?msg_id=37840820 > follow the thread > Regards Just updated from CVS (HEAD (OSG)), and it seems to me that the autopilots are working. I tried the KAP140, and the generic in the pa28-161. Both worked fine in heading mode, and the followed the bug on the HSI. Gérard, are you still heaving trouble with the autopilot? If you are could you please tell us excactly what isn't working. Are the controllers not activated at all? Are they using non-existent input properties? Have you tried to activate the debugging of the controllers (writes debugging info to the console)? -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altAlert problems
On Sunday 21 January 2007 19:15, John Wojnaroski wrote: > Likewise, not sure where you're going with this. ATC simply reports the > current altimeter setting to the pilot. Above FL180 all altimeters are > set to 29.92 or 1013. Encoding report aircraft altitude, otherwise ATC > relies on what the pilot reports as aircraft altitude. I did a lot of research when I wrote the code for the encoder and transponder. Unfortunately I didn't note where I found the information. I seem to remember that the encoder encoded the pressure to pressure altitude, _not_ ASL altitude. I'm searching the web right now to try and find info that can confirm this. > > But you might try > > Ref. Aviation Formulary, Ed Williams, www.best.com/~williams/avform.htm > > for data on a standard atmosphere Thanks for the link, I'll look into that. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altAlert problems
On Sunday 21 January 2007 17:42, Martin Spott wrote: > Roy Vegard Ovesen wrote: > > I asked on the developer list if anyone knew how ATC converted from > > pressure altitude to altitude, because I think that would be the correct > > way to do it. Does anyone know? > > How do you mean this ? They simply 'know' the reference pressure in the > area where you're currently flying. It seems I didn't unterstand why > you're asking What I'm asking for is an equation to convert from pressure altitude to ASL altitude. Something like ASL_alt = f(pressure_alt, ref_pressure) -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] altAlert problems
On Sunday 21 January 2007 03:20, you wrote: > Hi Roy, > I did a lot of testing today. While using "real weather" with the baro > setting, I noticed that the captured altitude was off by about 1000 ft > times the delta between baro setting and 29.92. Looking at the nasal > for the new altAlert , it looks like we using pressure altitude for > altFt and then comparing that with altPreselect. Note that altFt and > pressure altitude are equal only when the altimeter setting is 29.92. In > short we are driving the pressure altitude to the altPreselect which > agrees with the above error. This should be easy to fix. The previous > code (pre the type conversions) worked correctly. Yes, I know. The previous code didn't use the encoder to find the altitude, it used the pressure in the static port. The new code uses the encoder, and I ignored the baro setting because I couldn't figure out how to convert from pressure altitude to altitude via the baro setting. I believe I have found a way to do the conversion in the file attached. (Not to the devel list.) I'm converting pressure altitude to pressure with the heightToPressure() function. Then I'm converting pressure to altitude with the pressureToHeight() function using the baro setting as reference pressure (p0). I asked on the developer list if anyone knew how ATC converted from pressure altitude to altitude, because I think that would be the correct way to do it. Does anyone know? -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] kap140 bug+fix
On Sunday 14 January 2007 03:54, Dave Perry wrote: > I downloaded the file and did the edits to check for power. I am > getting "nil used in numeric context" because > /instrumentation/encoder/pressure-alt-ft is required in altAlert but has > no value in the property tree. This is the same for the c172p, c182, > and pa24-250. I am running from a Thursday compile from cvs, osg branch, > both source and SimGear. I believe the c172p is using the generic-instrumentation.xml instrumentation config file, so it should have a working encoder. Is /instrumentation/encoder/serviceable set to true? > All the annunciators are lit and all the > buttons cause > Nasal runtime error: no such member > at /sim[0]/bindings/panel/binding[n], line 2 errors where n varies with > the button. > I am getting the same error and behavior with your unedited file and the > c172p. Do I need other patches? You need to also replace "KAP140TwoAxisAlt.xml" in data/Aircraft/Instrumentation? All the function names have changed name. And you need to replace "KAP140.xml" in data/Aircraft/c172p/Systems. The locks have changed data type (from strings to bools). -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] kap140 bug+fix
On Saturday 13 January 2007 17:20, Dave Perry wrote: > On Sat, 2007-01-13 at 11:05 +0100, Melchior FRANZ wrote: > > * Dave Perry -- Saturday 13 January 2007: > > > When Vegard Ovesen edits are available, I plan to incorporate them in > > > the pa24 version. I've put the files here: http://81.166.142.135/FG/ > > > > Excellent. There should only be one generic kap140.nas (in > > Aircraft/Instruments/ or Aircraft/Generic/?) and it should > > only contain the kap140 logic, with no aircraft specific > > aspects. If some aircraft doesn't provide some necessary > > input yet, then it's better to add that there. Agreed. > > Just checked the c172p and the c182 for the property > /systems/electrical/outputs/autopilot. It has a value > 26 so the > version of kap140.nas in the pa24-250 folder would work fine with both. > Are there other AC using the kap140 that I need to check? > > There were several typos in the original kap140.nas that could affect > performance that have been corrected in the pa24 version. So, if there > are no objections, after merging the Vegard Ovesen updates into the pa24 > version, I would suggest that we move both this file and the kap140 xml > file to a central location per Melchior's suggestion and make the > appropriate changes to the pa24-25, the c172p, and the c182 to use these > files. I think it's better to keep the kap140.xml file aircraft specific as different aircraft will need different controller tunings. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C182 creeping features
On Monday 08 January 2007 19:12, John Denker wrote: > Don't take the following too seriously: > > In the long term, I have fantasies about allowing the point of view > to change ... not just changing the tilt/pan/zoom from a fixed point, > but actually moving the pilot's *point* of view. That would allow > peering around the yoke to see switches ... and perhaps more importantly, > it would allow moving the PoV to the side to peer around the cowling > to better see what's going on during landing. I reckon this would be > a royal pain to implement, and inconvenient to use in practice, but it > would be the bees' knees in terms of realism. This was implemented a long time ago. In view mouse mode (two right clicks, until the cursor becomes <->) hold the middle mouse button and move the mouse. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 20:13, gh.robin wrote: > On Sun 7 January 2007 19:40, Roy Vegard Ovesen wrote: > > On Sunday 07 January 2007 19:25, gh.robin wrote: > > > And if you don't trust me, when i say its working, look at this > > > http://perso.orange.fr/GRTux/pressure-inhg.jpg > > > > Nick is right, /Systems/... _is_ a typo. Can someone with CVS write access please fix this, thanks. > > > > The reason why it is working for Gérard is because at runtime the > > default /Systems/... is overridden by what is in his intrumentation > > configuration file (/systems/...). > > I am glad to learn that it is possible to have a Cockpit with working > instruments , without any instrumentation configuration file, and possible > to read the value on the VSI instrument. > I will spare a lot of time during the cockpit development. If you don't specify any instrumentation config file in your *-set.xml file then it will of course use what is in preferences.xml. That is data/Aircraft/Generic/generic-instrumentation.xml. The same is true for systems config file. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 19:25, gh.robin wrote: > > > > You must first check it , because the existing code is working right > > > > with "/Systems/static/pressure-inhg" > > > > > And if you don't trust me, when i say its working, look at this > http://perso.orange.fr/GRTux/pressure-inhg.jpg Ok! Now I'm just confused. Gérard is trying to prove that "/Systems/static/pressure-inhg" is working by sending a screenshot showing "/systems/static/pressure-inhg". Nick, how did you get it to fall back to "/Systems/..."? Did you use a custom instrumentation config file, or did you forget to also update the base package (data) from CVS? -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 19:44, Nick Warne wrote: > On Sunday 07 January 2007 18:40, Roy Vegard Ovesen wrote: > > On Sunday 07 January 2007 19:25, gh.robin wrote: > > > And if you don't trust me, when i say its working, look at this > > > http://perso.orange.fr/GRTux/pressure-inhg.jpg > > > > Nick is right, /Systems/... _is_ a typo. > > > > The reason why it is working for Gérard is because at runtime the > > default /Systems/... is overridden by what is in his intrumentation > > configuration file (/systems/...). > > Also something to do with the aircraft xml cfg files using > which uses something else, I believe. The tag in instrumentation configuration files is no longer used. It has been replaced with the tag where one can specify the complete path to the property that one wish to use. I hunted down all the instrumentation configuration files and replaced before sending for committ to CVS, but I can not guarante that I found them all. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] PRE_OSG cvs BUG in VSI with code fix
On Sunday 07 January 2007 19:25, gh.robin wrote: > > And if you don't trust me, when i say its working, look at this > http://perso.orange.fr/GRTux/pressure-inhg.jpg Nick is right, /Systems/... _is_ a typo. The reason why it is working for Gérard is because at runtime the default /Systems/... is overridden by what is in his intrumentation configuration file (/systems/...). -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch for Yasim (printing out inertia tensor)
On Friday 05 January 2007 19:33, Joacim Persson wrote: > Er, no mixed it up (again! ;): > Yasim usess a mix of unit systems: pounds for mass, but metres for lengths > > So moment of inertia becomes "pounds per square metre", which doesn't make > anyone happy. English is not my first language, but doesn't "pounds per square meter" mean lb/m² ? lb/m² could be interpreted as pressure. lb*m² is moment of inertia. > > I'm quite sure my conversion to kg/m² is correct (the values I get looks kg/m² could be pressure. > sane), but numbers in pounds, slugs, gallons, feet etc are about as > meaningful to me as if they were given in "yellow striped hedgehogs per > square prostethnic waterfalls". Actually feet and inches are pretty meaningfull since you can use your limbs as reference. :-) > ...think it should be divided by about ten rather than multiplied. ...? I'm pretty sure what you had in your patch and what I wrote in my last post is correct. According to http://www.wsdot.wa.gov/reference/metrics/factors.htm 1 ft² = 0.09290304 m² => 1 m² = 1/0.09290304 ft² = 10.763910 ft² -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] patch for Yasim (printing out inertia tensor)
On Friday 05 January 2007 18:25, Joacim Persson wrote: > I screwed up again, didn't I? > > How *do* I convert "metres per square feet" to "pounds per square feet" > really? m/ft² -> lb/ft² ? That does not make sense, or do you still mean m² -> ft²? 1m² = 10.76391041670972230833ft² -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Improved c172p autopilot
On Wednesday 03 January 2007 10:27, woodyst wrote: > It can be fixed in "kap140.nas" file, I think. I would study that file well > and if I can, I will send another patch. I've overhauled kap140.nas quite extensively. I've changed to more sensible property data types like boolenas instead of text. I've also fixed the bug that Joacim Persson reported. I'll try to hand it over to someone with write access to CVS tonight. Because of this you should hold off studying the code until the new version is in CVS. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] implemented: interval timer (aka approachtimer) [aka stopwatch]
On Tuesday 02 January 2007 21:18, John Denker wrote: > On a related note, can anybody explain why the searches > http://www.google.com/search?q=stopwatch.xml+site:flightgear.com Unless flightgear.com is just a typo in this mail then it should be obvious. ^^^ > > Whether or not such a structural change is possible, a procedural approach > might be helpful. For example, when committing something new to CVS, it > would be helpful to post some sort of "advertisement" to the mailing lists. > An entry in the CVS log that says "stopwatch.xml" is not nearly as useful > as a message saying what it is, why we should care, how to find usage > examples, et cetera. As a measure of my sincerity, you may observe that I > posted such a message about my hackish interval timer. I even put multiple > synonyms in the subject line, so that would-be users would not have to play > the Rumplestiltskin game to guess what the thing is called. Of course one must agree to this and many folks do post a note on the devel list about new features. How long have you been lurking? > As another category of data supporting the same general point, according to > > http://www.google.com/[EMAIL PROTECTED]:flightg >ear.org there are 1700 places on the flightgear.org site that refer to the > wrong mailing list (flightgear-devel@flightgear.org). Or rather the old mailing list. The search returns references to the mailing list archives. Naturally messages in the archives will contain the old mailing list address. > Suggestion 1: Perhaps somebody should walk through the whole project > workspace and replace each occurrence of the wrong address with the right > address. You can't possibly mean replacing every occurence of the old list address in the archive. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] won't compile ... also configuration issues:openAL +- osg +- whatever
On Tuesday 02 January 2007 16:42, John Denker wrote: > Uhhh, what has OSG got to do with it? I don't see an OSG requirement > mentioned anywhere in the documentation. > > Do I need OSG on top of plib? Or OSG instead of plib? Is this optional, > or is it a new requirement? OSG on top of plib. We still use plib for some things (the gui and joystick I believe). If you use CVS HEAD then OSG is required. There was recently a fork in CVS to separate the plib-only and the plib OSG versions. I believe that the plib-only fork will eventually be abandoned and/or merged with the plib OSG version. > > Suggestion (again): Whatever the actual requirements are, they should be > documented, and they should be enforced by the configure script. Probably the most up-to-date documentation about Flightgear is located on the Wiki page. There's even a section about OSG: http://wiki.flightgear.org/flightgear_wiki/index.php?title=OpenSceneGraph > > Debian etch offers an libopenscenegraph-dev package; that's easy enough > to install. But naive users would have a hard time guessing that it's > needed. Depends on the naiveness ;-) -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] implemented: interval timer (aka approachtimer) [aka stopwatch]
On Tuesday 02 January 2007 19:20, Nick Warne wrote: > On Tuesday 02 January 2007 18:24, AJ MacLeod wrote: > > > > You can find the code in gui/dialogs/stopwatch.xml > > I have the latest CVS and I do not have that file either - plus it isn't in > the on-line repository either: > > http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/FlightGear/src/GUI/?pat >hrev=HEAD It's not in the source tree, but in the data tree: http://cvs.flightgear.org/cgi-bin/viewvc/viewvc.cgi/data/gui/dialogs/?pathrev=HEAD Another rule of thumb when developing and when updating from CVS is to keep both source _and_ data up-to-date. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest OSG note...
On Thursday 07 December 2006 07:20, syd wrote: > I just compiled CVS OSG tonight (avoiding the broken Producer) and > everything compiled fine , no errors, but I get a steady stream of > "Warning: detected OpenGL error 'invalid enumerant' after > RenderBin::draw(,) " > while running Flightgear.It doesnt seem to effect performance , but > doesnt leave room for any other messages. > Has this been seen by anyone else, or any idea where to begin looking > for the cause of the problem ? I also see this. It seems to only happen when there is a light (airport lights, vasi etc.) visible in the scene. -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPL Violation?
On Friday 17 November 2006 18:23, Curtis Olson wrote: > > I'll probably vote for putting him in a cage for 10 minutes with Arnt. > lol! -- Roy Vegard Ovesen - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Making of: jitter.png (Unix)
On Saturday 19 August 2006 09:44, Melchior FRANZ wrote: > * Roy Vegard Ovesen -- Saturday 19 August 2006 09:36: > > I've also used kst to plot properties in real-time. I used Flightgear's > > own logging. > > How are you doing it? Via FIFO or by writing to a file and letting kst > read from it? I use FlightGear's logging system to log to a csv file, and let kst read that file. Kst updates as the file grows. The csv file has headings at the top and the first column is the time in seconds since start of fg. I use the "Data Wizard" in kts to open the csv file. Kts recognises the column names and it automatically creates a culumn called INDEX. The INDEX column is probably supposed to be used for the horizontal x-axis, but since we already have a timestamp comlumn it's better to use that one for the x-axis. It makes sense to check the "Read to end" checkmark in the select data screen of the wizard. After I'm done configuring kst and setting up all the plots that I need I save the kst plot file. The next time I start fg with logging I open that plot file in kst and it will of course read the data that fg is putting into the log file. I don't have to go through the wizard and the configuration of the plot layot every time. > The most obvious way -- directly piping -- didn't work for > me, as kst gives up if there are no data within a few seconds. And fgfs > takes a while to spit out anything. I "complained" to the kst mailing list > and don't know yet what they think. But the FIFO isn't that bad for now. I haven't tried the FIFO method, but the log file method works grat for me. Another advantage is that the data is stored in the log file. Not knowing everything about FIFOs I'm guessing that the data is only "stored" in kst with this method. -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Making of: jitter.png (Unix)
On Friday 18 August 2006 17:41, Melchior FRANZ wrote: [SNIP] > Used software: > fgfs, awk, kst (http://kst.kde.org/ -- free & GPL) > > > (A) make sure fgfs outputs the relevant data. Logging could certainly be > used for that, but I'm not half as familiar with it as with Nasal, so > I simply put a line like the following in a Nasal file: I've also used kst to plot properties in real-time. I used Flightgear's own logging. This is very usefull when trying to tune the autopilot controllers. [SNIP] > > PS: yes, I'm aware of gnuplot :-) Before someone on this list suggested using kst I used gnuplot, but I think kst is bettet suited as I can pan and zoom easily with the mouse. -- Roy Vegard Ovesen - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
På 16.06.2006 10:19 CEST skrev Vivian Meazza <[EMAIL PROTECTED]> snip... >I also have a patch prepared which prevents xmlauto.cxx from generating >spurious instruments, and which uses whichever Heading Indicator that is >present. That's probably a 'fancy waistcoat', and I'm still pondering if >it's worth submitting. As you can see the "helpers" in xmlauto are hardcoded to the instruments that existed and were also hardcoded at the time. I think that these "helper" values should be moved into the instrument code that they belong to. For example the heading error should be moved into the heading indicator instrument code. This would result in the heading error only being available when the heading indicator instrument was present in the instrumentation configuration file. Some other "helper" values are IMHO redundant and should be removed all together (vertical speed conversion into feet/s). -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] generic-instruments.xml and a second DME device
ons, 22,.03.2006 kl. 20.41 +0200, skrev Paul Surgeon: > After some debating in IRC ... > > Can we please add a second DME device to Generic/generic-instruments.xml? > > i.e. > > dme > 1 > > > It is ***NOT*** possible to create extra devices within an aircraft's local > config files. I've tried it and it does NOT work. > All you end up with are some properties but nothing that drives them. An aircraft's local instrumentation config file is just a replacement that overrides Generic/generic-instruments.xml, so in principle, if it does not work with the local config file it wouldn't work any better in generic.instruments.xml. Remember that you also have to supply power to your new DME, and that the serviceable property should be set to "true". > If the tacan, KT-70, wxradar, mk-viii which are not generic can live in > generic-instruments.xml then I see no argument against a second dme > instrument living in there too especially if that's the only place to do it. When I created the generic-instruments.xml file I included whatever existed hardcoded at the time. Since then new instruments have been added. It would be preferable if every aircraft had its own customized instrumentation config file (and systems config file). -- Roy Vegard Ovesen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] SV: [Flightgear-devel] KAP140 query
På 10.03.2006 00:31 CET skrev David Luff <[EMAIL PROTECTED]> >After setting the vertical speed on the KAP140, the display of vertical speed >disappears after a few seconds, even though the autopilot is still holding (or >trying to) the target vertical speed. Is this correct, or should the target >speed be displayed persistently? This is with the 2D c172p panel, although I >believe the 3d one displays the same behaviour. According to the Pilots Guide the preselected altitude is normally displayed. When you change the vertical speed setting, the vertical speed is displayed for 3 or 5 seconds (I forget), after that the display reverts to the preselected altitude. So, I guess the current behaviour is correct. -- Roy Vegard Ovesen --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot on default Cessna
On Saturday 28 January 2006 16:52, Curtis L. Olson wrote: > For what it's worth, it would be great if someone could figure it all > out and write a up a little mini-howto so the rest of us don't have to > wade through 100 page manual. There is a very short quick guide on the wiki page: http://www.seedwiki.com/wiki/flight_gear/bendixking_kap140_autopilot.cfm?wpid=226748 There is also a link to the pilot guide on that page. The sections from the pilot guide that you want to concentrate on are the "System Operating Modes" at pages 12, 59 and 86. -- Roy Vegard Ovesen --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tying scenario specific code to aircraft
On Friday 30 December 2005 22:25, Paul Surgeon wrote: > Hmmm ... I didn't know that the network interface was that flexible. > So I can read and write any properties in the property tree from an > external app? Yes, with the telnet interface you can. There are examples in source/scripts. > Playing sounds from an external app (which is an absolutely neccessary for > what I want to do) would be a problem for some people who's sound cards > don't do hardware mixing. I assume playing sounds from nasal would get > mixed inside FG's openal setup? Yes, but AFAIK you would have to define the sounds as sound effects that react to certain properties, in an xml file, just like c172-sound.xml. And that could become ugly very fast. :-( I also think that they have to be wav files and that could become very large very fast. -- Roy Vegard Ovesen --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tying scenario specific code to aircraft
On Friday 30 December 2005 22:07, Roy Vegard Ovesen wrote:
> On Friday 30 December 2005 21:45, Curtis L. Olson wrote:
> > Note also that you could do much, if not all of this from an external
> > perl/python script as well and interface to FG through the network
> > interface.
>
> With perl/python you can do alot more that you can do with nasal. Play mp3,
than
--
Roy Vegard Ovesen
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tying scenario specific code to aircraft
On Friday 30 December 2005 21:45, Curtis L. Olson wrote: > Note also that you could do much, if not all of this from an external > perl/python script as well and interface to FG through the network > interface. With perl/python you can do alot more that you can do with nasal. Play mp3, vorbis or even speex encoded sounds. FileIO, for example for evaluation reports. > 101 ways to skin a cat ... Indeed! -- Roy Vegard Ovesen --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
