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
[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#174; 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
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#174; 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 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 01:48:55 FGD ML wrote: 2009/2/6 Roy Vegard Ovesen roy.v.ove...@haugnett.no 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 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 12:38:23 FGD ML wrote: 2009/2/7 Roy Vegard Ovesen roy.v.ove...@haugnett.no 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. shrug 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 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 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 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 class T
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=100url=/
___
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=100url=/ ___ 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:
filter
namepass-through-filter/name
debugfalse/debug
typepass/type
input/instrumentation/airspeed-indicator/indicated-speed-kt/input
output/autopilot/KAP140/settings/airspeed-kt/output
/filter
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:
config
Kp prop=/autopilot/KAP140/settings/controller01-gain10.0/Kp
...
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:
config
Kp
prop/autopilot/KAP140/settings/controller01-gain/prop
value10.0/value
/Kp
...
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.
pid-controller
nameRuddervator Surface Driver/name
debugfalse/debug
enable
prop/autopilot/FCS/locks/elevator/prop
valuetrue/value
/enable
input
prop/autopilot/FCS/controls/flight/elevator-norm/prop
/input
reference
prop/autopilot/FCS/internal/target-elevator-norm/prop
/reference
output
prop/autopilot/FCS/controls/flight/elevator-norm/prop
/output
config
Ts0.05/Ts
Kp0.45/Kp
beta0.1/beta
alpha0.1/alpha
gamma0.0/gamma
Ti0.05/Ti
Td0.0/Td
u_min-1.0/u_min
u_max1.0/u_max
/config
/pid-controller
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 {
enabled
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] 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 enabled 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. 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
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
[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] 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
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, 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, 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] 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 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: 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] [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] 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 @@ condition property/autopilot/KAP140/annunciators/beep/state/property /condition - volume -offset0.5/offset - /volume /kap140beep /fx - + /PropertyList - 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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 repeat argument to the aircraft.light.new method? If I add it before switch then that will certainly break things. If I add it after switch then switch 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=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=lnkkid=120709bid=263057dat=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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 static-port which uses something else, I believe. The static-port tag in instrumentation configuration files is no longer used. It has been replaced with the static-pressure 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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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.phpp=sourceforgeCID=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 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=lnkkid=120709bid=263057dat=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 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=lnkkid=120709bid=263057dat=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
[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=lnkkid=110944bid=241720dat=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=lnkkid=103432bid=230486dat=121642 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
