Re: [Flightgear-devel] Flying the f-14b...
On Sun, Sep 25, 2011 at 4:46 PM, Citronnier - Alexis Bory < alexis.b...@gmail.com> wrote: > > As always, thank you for a GREAT aircraft ;=)) > Thanks Geoff :-) The f-14b has tons of little easter eggs and details! Definitely a fun and interesting aircraft! Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://gallinazo.flightgear.org -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
On Sunday 25 September 2011 16:46:32 Scott wrote:
> From: Scott
> To: flightgear-devel@lists.sourceforge.net
> Subject: Re: [Flightgear-devel] latest Git next, endless loop from
> FGATCMgr and missing JSBsim fuel-used property
> Date: Mon, 26 Sep 2011 08:37:06 +1000
>
> On Sun, 2011-09-25 at 13:49 -0600, Ron Jensen wrote:
> > On Sunday 25 September 2011 01:36:25 Scott Hamilton wrote:
> > > Greetings,
> > >
> > > I've noticed two small problems with the current Git
> > > "next" (as at 2011-09-25), is anyone else seeing these?
> > >
> > > 1. the JSBsim
> > > per-engine /fdm/jsbsim/propulsion/engine[]/fuel-used-lbs property has
> > > disappeared
> >
> > I see it in the code, and in my fgfs. It should be automatically created
> > for every JSBSim engine. What aircraft are you flying?
>
> Hi ya Ron,
>
>I was flying the A380 and thought it was not being created as the
> A380 has a JSBsim Post function to convert it to fuel-used-kg, so I
> thought that was creating the fuel-used-lbs when reading it.
>I then tried the 747-400 and I see fuel-used-lbs is being created as
> zero, but is not been updated, it remains at zero once you start the
> engines, so that looks like the problem, it is not being updated.
>
>So I notice that when I did a 'git pull next' yesterday, a whole lot
> of FDM/jsbsim/propulsion changes, it was probably about 3 - 4 weeks
> prior that I did the last git pull next, when fuel-used-lbs property was
> updated correctly for each engine.
>
>
>
>cheers
> S.
Ah, the fuel consumption code was refactored and the mechanism for setting
that property was removed. The attached patch, which is now in JSBSim head
fixes the issue.
Sorry,
Ron
>From 67779f1d563d6d1661cb5295c210c6ac67ef74b4 Mon Sep 17 00:00:00 2001
From: rjensen
Date: Sun, 25 Sep 2011 17:53:04 -0600
Subject: [PATCH] Make the total fuel expended counter work again.
---
src/models/propulsion/FGPiston.cpp|1 +
src/models/propulsion/FGTurbine.cpp |1 +
src/models/propulsion/FGTurboProp.cpp |1 +
3 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/models/propulsion/FGPiston.cpp b/src/models/propulsion/FGPiston.cpp
index d055056..f8baaa8 100644
--- a/src/models/propulsion/FGPiston.cpp
+++ b/src/models/propulsion/FGPiston.cpp
@@ -481,6 +481,7 @@ void FGPiston::Calculate(void)
double FGPiston::CalcFuelNeed(void)
{
FuelExpended = FuelFlowRate * in.TotalDeltaT;
+ if (!Starved) FuelUsedLbs += FuelExpended;
return FuelExpended;
}
diff --git a/src/models/propulsion/FGTurbine.cpp b/src/models/propulsion/FGTurbine.cpp
index 5b676ed..b86bf76 100644
--- a/src/models/propulsion/FGTurbine.cpp
+++ b/src/models/propulsion/FGTurbine.cpp
@@ -385,6 +385,7 @@ double FGTurbine::CalcFuelNeed(void)
{
FuelFlowRate = FuelFlow_pph / 3600.0; // Calculates flow in lbs/sec from lbs/hr
FuelExpended = FuelFlowRate * in.TotalDeltaT; // Calculates fuel expended in this time step
+ if (!Starved) FuelUsedLbs += FuelExpended;
return FuelExpended;
}
diff --git a/src/models/propulsion/FGTurboProp.cpp b/src/models/propulsion/FGTurboProp.cpp
index 41f7967..7def4fb 100644
--- a/src/models/propulsion/FGTurboProp.cpp
+++ b/src/models/propulsion/FGTurboProp.cpp
@@ -410,6 +410,7 @@ double FGTurboProp::CalcFuelNeed(void)
{
FuelFlowRate = FuelFlow_pph / 3600.0;
FuelExpended = FuelFlowRate * in.TotalDeltaT;
+ if (!Starved) FuelUsedLbs += FuelExpended;
return FuelExpended;
}
--
1.7.4.4
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
From: Scott To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property Date: Mon, 26 Sep 2011 08:37:06 +1000 On Sun, 2011-09-25 at 13:49 -0600, Ron Jensen wrote: > On Sunday 25 September 2011 01:36:25 Scott Hamilton wrote: > > Greetings, > > > > I've noticed two small problems with the current Git > > "next" (as at 2011-09-25), is anyone else seeing these? > > > > 1. the JSBsim > > per-engine /fdm/jsbsim/propulsion/engine[]/fuel-used-lbs property has > > disappeared > > I see it in the code, and in my fgfs. It should be automatically created for > every JSBSim engine. What aircraft are you flying? Hi ya Ron, I was flying the A380 and thought it was not being created as the A380 has a JSBsim Post function to convert it to fuel-used-kg, so I thought that was creating the fuel-used-lbs when reading it. I then tried the 747-400 and I see fuel-used-lbs is being created as zero, but is not been updated, it remains at zero once you start the engines, so that looks like the problem, it is not being updated. So I notice that when I did a 'git pull next' yesterday, a whole lot of FDM/jsbsim/propulsion changes, it was probably about 3 - 4 weeks prior that I did the last git pull next, when fuel-used-lbs property was updated correctly for each engine. cheers S. > > Thanks, > Ron > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flying the f-14b...
Le 25/09/2011 01:07, Geoff McLane a écrit : > Evolved from [Any alpha testers with a bit of extra time on their > hands?] > > Re: Start up > > When I first loaded the f-14b the engines were NOT > running, so I searched for a 'Start-up procedure', but > mostly in vane... it turned out all I needed to do was ADD > FUEL to the beast ;=)) > > So I would suggest a line or 2 be added to the f-14b > wiki - > http://wiki.flightgear.org/index.php/Grumman_F-14_Tomcat > > Something like - > > Start up: > > If the engines are OFF (silent) when you load the f-14b, all you > maybe need to do is enter MENU tomcat controls -> Fuel and stores, > and increase the 'L Beam Box', (and 'R Beam Box') sliders > to give the beast some fuel ;=)) > > And the engines should IGNITE ;=)) > > Then you have an 'active', very fast aircraft at your > disposal ;=)) > > And this fuel added will be 'saved' so on the next run > the f-14b - it will have the fuel you exited with... > > Maybe there are other ways, but did not explore > them... > > Of course I would further recommend an 'f', to set full > flaps, before you bump the throttle... and you will be > airborne quite quickly... very BIG POWERFUL engines... > > If like me you started on KSFO 10L, quickly throttle back > to about 50%, or less, and commence a left turn, and head > back to the San Mateo bridge... another left, and line up > for a landing... to complete your first 'manual' circuit... > > Re: FUEL > > Am a bit confused by the MENU -> Tomcat controls -> > Fuel& stores - > http://geoffair.org/tmp/f-14b-fuelset.png > and the onboard fuel display - > http://geoffair.org/tmp/f-14b-fuel.png > > It _SEEMS_, in the Nasal code, the 'Sump' is ADDED to > the fuel displayed... This does not seem right!?!? > > I added 2x225 (450) pounds of fuel, but end up seeing > 1010 pounds of fuel on my panel display... > > Now maybe I do NOT understand the 'sump' (2x281), but > it seems the nasal code ADDED this as well... Yes, I asked the nasal code do that. Each sump is a tiny little tank that contains only 281 lbs of pure JP-5 (44 US gal)... ask Grumman :-) > As indicated. maybe _NOT_ a problem, but QUITE confusing > none the less... and needs explanation... The two lateral digital fuel quantity indicators can represent three different quantities depending on the respective switch setting (fuel control panel on the left console, outer left switch, WING, FEED, EXT) When on the middle position it sums the tanks for each feed group: left wing, aft, left beam box, left sump, or right wing, forward tank, right beam box and right sump. In the manual, the feed group may or may not include the wing tank... Other positions show only wing tanks or external tanks. The tapes show only internal, that is each feed group without wing. Total shows total fuel as expected. What's funny is to look at how the fuel flows from one tank to another depending on the fuel flow at the engine pumps. After a while the system can stand afterburners needs but not more. Unfortunately I didn't took the time to model the engine system yet, I did a guided missile instead (me bad boy !) > Re: autopilot (F11 and keyboard) > > Have not yet explored all of this, but the first few > tries seemed quite successful... > > Need more time to make sure the generic 'autopilot' (F11 > or through keyboard commands) of the f-14b is working > as it should... but at this time have found no > particular problems... no adverse behavior... no > 'error' outputs... > > That is at least in the low altitude, low speed, full > flaps mode, low throttle, mode I have been using... The altitude mode has a lot of trouble with the automatic unlock system which is way too sensible, and the attitude mode is not friend with the flaps compensation system. For the rest you better disable the attitude mode before doing aerobatics. But well, it works as long as you have fps > 20. Note that I didn't made any effort to keep FG standard AP in line with the F-14 system. > Re: A Question > > Through a telnet connection, I have been trying to > determine the fuel available for the f-14b... > > But when I query say - > /consumables/fuel/tank/level-gal_us > and/or > /consumables/fuel/tank[1]-[11]/level-gal_us > I find these are mostly EMPTY!!!???... Mostly half empty or mostly half full ? > So the question is - where, in what property, are > the above mentioned left/right 225 pounds stored? > > Yes, I have found the property - > /sim/model/f-14b/instrumentation/fuel-gauges/ > [left|right]-wing-display > contains the (inflated by sump) value... > > But where can I find the 'L Beam Box', and > 'R Beam Box' slider results in the properties? FWD_Fuselage consumables/fuel/tank[0] AFT_Fuselage consumables/fuel/tank[1] Left_Beam_Box consumables/fuel/tank[2] Left_Sump consumables/fuel/tank[3] Right_Beam_Box consumables/fuel/tank[4] Right_Sump consumables/fuel/tank[5] Left_Wing consumables/fuel/tank[6]
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
On Sunday 25 September 2011 01:36:25 Scott Hamilton wrote: > Greetings, > > I've noticed two small problems with the current Git > "next" (as at 2011-09-25), is anyone else seeing these? > > 1. the JSBsim > per-engine /fdm/jsbsim/propulsion/engine[]/fuel-used-lbs property has > disappeared I see it in the code, and in my fgfs. It should be automatically created for every JSBSim engine. What aircraft are you flying? Thanks, Ron -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Instrument in outside view?
Is there any way to display instruments when using any of the outside views? For example, can I place an altimeter in the corner of the chase view? I have tried changing some of the view and instrument properties, but it seems like the panel is always hidden, except for the actual inside view. Any suggestions? --Adam -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] startpos broken?
I cannot get to a parkpos wheter loading with fgrun nor afterwards with moving the airplane.Why? Is it broken in Git? -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs hangs while loading scenery
Thanks! cheers, Jorg 2011/9/25 Thomas Albrecht > > Please tell me how it was fixed? > > Uncomment a logging message in simgear/scene/model/SGPagedLOD.cxx: > http://sourceforge.net/mailarchive/message.php?msg_id=28123414 > > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs hangs while loading scenery
> Please tell me how it was fixed? Uncomment a logging message in simgear/scene/model/SGPagedLOD.cxx: http://sourceforge.net/mailarchive/message.php?msg_id=28123414 signature.asc Description: This is a digitally signed message part. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Toe brakes (was: Direct Draw Surface Scenery Textures)
They are homebrewed. The guts came out of a Saiteck 290 Pro joystick and the pedals are Thrustmasters. An hour with a soldering iron would fix the reversed pot, but 30 seconds in a text editor made it work just fine. :) http://www.jentronics.com/fgfs/simpit/pedal.jpg On Sunday 25 September 2011 03:20:23 Durk Talsma wrote: > Hi Ron, > > Thanks for reporting. Which set of pedals are you using? For me, both > brakes report -1 when not pressed and 1 when pressed. > > I am using the saitek pro pedals. When looking at the raw device output > (using jstest /dev/input/js[01]), I see that (usually), the toe brakes > output is only -32767 or +32767 (with no intermediaries). I also typically > find that when I first plug in the pedals, js_demo reports losing the > device. > > As mentioned, this is mostly how it is reported. Sometimes the correct > values are reported, which makes me believe that I'm either facing a > hardware problem (which went undetected in older kernels), or the more > recent kernels don't know how to handle the Saitek pedals. > > In any case, I might want to try downloading a debian live CD to see what > kind of behavior I'm getting there (or test an older Suse installation). > > Cheers, > Durk > > > I just looked at js_demo with my toe brakes and they show the same > > behavior, range is +/-1, left brake sense is reversed. > > > > Debian Linux 2.6.38-2-686 #1 SMP Thu Apr 7 05:24:21 UTC 2011 i686 > > GNU/Linux > > > > I have this as a configuration: (add an offset so the range is 0..2 then > > multiply by 0.5) > > > > > > Left Brake > > > > property-scale > > /controls/gear/brake-left > > -1.0 > > -0.5 > > > > > > > > > > Right Brake > > > > property-scale > > /controls/gear/brake-right > > 0.5 > > 1.0 > > > > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
On Sat, 24 Sep 2011 17:10:29 -0500, Curtis wrote in message : > Hi Geoff (and Arnt, et. al.) > > I have another update to try. This one drives the roll angle by > manipulating the ailerons directly, rather than trying to modify > /controls/flight/SAS-roll. SAS-roll worked for me, and I was just > following the example of the existing f-14b dg-heading controller. > But driving /control/flight/aileron seems to work just as well for > me. If there is some sort of order of execution problem with nasal > or something conflicting with SAS-roll, perhaps this will work > better? I'd be interested in hearing if it helps if anyone gets a > chance to try it. ..roll is _much_ smoother, for Alpha05, copy your success on the elevators too. ..on start-up, I overshoot the altitude by around 4000feet, so now I have time to try the "Go home" button. Wild enough ride, blackouts alternating with redouts, but it climbs out. ..on resets, I still land in the cockpit and are immediately launched into the drink, first run T/O were tracking left on the deck and rolling off it to the left, on my second run, both to the right, as if I had an one side flame-out on the get-go. > Download link for "Alpha04" version and instructions here: > > http://www.flightgear.org/uas-demo/ > > Curt. > > > On Sat, Sep 24, 2011 at 11:42 AM, Arnt Karlsen wrote: > > > On Sat, 24 Sep 2011 12:54:05 +0200, Arnt wrote in message > > <20110924125405.072bc...@nb6.lan>: > > > > > On Fri, 23 Sep 2011 21:06:00 -0500, Curtis wrote in message > > > : > > > > > > > Here's one for your guys. Do any nasal errors pop up on the > > > > console when things go bad? Are you able to manually fly the > > > > f-14b (non-uas version) around just fine? > > > > ..yup, even on the eeepc keyboard, one up tap elevator, full power, > > let it roll and wait out the rotation, 2 down taps on the elevator > > to keep the nose down to 15 to 30 degrees, gets it "safely" up at > > 1-2 fps. > > > > > > Once in maybe 20-50 flights I do see something go goofy with the > > > > f-14b stability augmentation's roll control. Maybe this same > > > > issue is popping up less rarely for some people? I haven't dug > > > > into how the SAS is implemented on the f-14b ... it's > > > > intricately woven I can tell ... maybe there's something > > > > lurking down in the guts of the f-14b SAS. > > > > ..or your settings. > > > > > > Curt. > > > > > > > > > > > > > > > > On Fri, Sep 23, 2011 at 8:35 PM, Arnt Karlsen > > > > wrote: > > > > > > > > > On Fri, 23 Sep 2011 23:44:02 +0200, Citronnier wrote in > > > > > message <4e7cfda2.7060...@gmail.com>: > > > > > > > > > > > Le 23/09/2011 23:12, Curtis Olson a écrit : > > > > > > > Geoff and Arnt and anyone else who is interested. I just > > > > > > > updated the zip file overlay with a few changes. > > > > > > > > > > > > > > Geoff: you may be getting tired of being a bunny, but I > > > > > > > played around with the roll controller and limited max > > > > > > > target roll angle to +/-35 degrees. I also dialed down > > > > > > > the gains a bit on final approach which will hopefully > > > > > > > slow down the wild swings. More adjustment may be > > > > > > > necessary, but I'd be interested in hearing if any of > > > > > > > this helps your situation. > > > > > > > > > > ..a wee bit, now takes off and makes it ~1000 feet up, then it > > > > > rolls to the right and makes it ~200 feet into the drink, and > > > > > repeats the stunt seated in the cockpit (rather than in the > > > > > camera), uncommanded on Reset button pushes. > > > > > > > > > > ..it's trying to orbit the carrier in the vertical plane? > > > > > > > > > > ..trying the operator click mode on targets like the > > > > > merchantman near the Nimitz, works, until the demo is > > > > > airborne, then it picks the Carrier target and tries a > > > > > vertical orbit around it. > > > > > > > > > > ..refetching the merchantman with the operator mouse click > > > > > mode, dives the demo into the drink between the 2 vessels. > > > > > > > > > > ..debug idea for Curtis: try the Nimitz too. > > > > > > > > > > > > > > > > > > > I also set the default carrier speed to zero so if we get > > > > > > > a few people out there playing around with this, we > > > > > > > should be able to see each other via MP. That could be > > > > > > > an additional fun element. I was just out there dodging > > > > > > > XIII who trailed me around the pattern and let me live > > > > > > > thankfully. :-) > > > > > > > > > > > > > > Here is the link with the zip file overlay download + > > > > > > > installation and operation instructions: > > > > > > > > > > > > > > http://www.flightgear.org/uas-demo/ > > > > > > > > > > > > > > MP Call Sign: Shrike :-) > > > > > > > > > > > > > > > > > > > Woot :-) so I missed the update, I just read this post after > > > > > > posting the previous one. And was wondering who was flying > > > > > > around there ! Model view ought to be interesting in ca
Re: [Flightgear-devel] fgfs hangs while loading scenery
Hi Michael, Please tell me how it was fixed? Kind regards, Jorg 2011/9/25 Michael Sgier > > No, now the fix by: "Csaba Halász" finally seems to work fine. Thanks > Csaba. > > > > > --- On *Sun, 9/25/11, jorg van der venne > *wrote: > > > From: jorg van der venne > Subject: Re: [Flightgear-devel] fgfs hangs while loading scenery > To: "Michael Sgier" , "FlightGear developers > discussions" > Date: Sunday, September 25, 2011, 12:48 PM > > Are you sure it's altitude related? Can you provide a way to reproduce the > problem? > > -Jorg > > > 2011/9/15 Michael Sgier > > As soon as i change altitude of some .ac in .stg fgfs hangs at "loading > scenery" > > No my syntax is ok i can also cut half .stg to load ok but not more. > > sighwasted 2 hours on such crap... > > > > > > > -- > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > > > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] database or php error in the wiki
Hm, works fine here. Anyway, forwarding this to the wiki admin. Gijs Date: Sun, 25 Sep 2011 14:52:00 +0200 From: m...@erikstreb.de To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] database or php error in the wiki Hello. I just registered for the flightgear wiki. When I try to access “my preferences” via http://wiki.flightgear.org/Special:Preferences I get the following error: --- Internal error Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. --- I just tried it with a new account and again the same issue. Who is responsible for the wiki an can fix this? Regards, Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] database or php error in the wiki
On Sun, Sep 25, 2011 at 2:52 PM, Erik Streb del Toro wrote: > > I just registered for the flightgear wiki. When I try to access “my > preferences” via http://wiki.flightgear.org/Special:Preferences I get > the following error: > > --- > Internal error > > Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php > to show detailed debugging information. > --- > > I just tried it with a new account and again the same issue. Same here. -- Csaba/Jester -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs hangs while loading scenery
No, now the fix by: "Csaba Halász" finally seems to work fine. Thanks Csaba. --- On Sun, 9/25/11, jorg van der venne wrote: From: jorg van der venne Subject: Re: [Flightgear-devel] fgfs hangs while loading scenery To: "Michael Sgier" , "FlightGear developers discussions" Date: Sunday, September 25, 2011, 12:48 PM Are you sure it's altitude related? Can you provide a way to reproduce the problem? -Jorg 2011/9/15 Michael Sgier As soon as i change altitude of some .ac in .stg fgfs hangs at "loading scenery" No my syntax is ok i can also cut half .stg to load ok but not more. sighwasted 2 hours on such crap... -- Doing More with Less: The Next Generation Virtual Desktop What are the key obstacles that have prevented many mid-market businesses from deploying virtual desktops? How do next-generation virtual desktops provide companies an easier-to-deploy, easier-to-manage and more affordable virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] database or php error in the wiki
Hello. I just registered for the flightgear wiki. When I try to access “my preferences” via http://wiki.flightgear.org/Special:Preferences I get the following error: --- Internal error Set $wgShowExceptionDetails = true; at the bottom of LocalSettings.php to show detailed debugging information. --- I just tried it with a new account and again the same issue. Who is responsible for the wiki an can fix this? Regards, Erik -- GPG-Schlüssel-ID: 0x036B38E6 Fingerabdruck: F057 EEEB F0F5 9144 D95C BD98 B822 138F 036B 38E6 Außerdem kann man per Jabber mit mir reden (chatten): Jabber-ID: wick...@jabber.org Off-The-Record: DEBD08C2 95E7C8CE 901EC136 E39A1E43 4FC13142 signature.asc Description: OpenPGP digital signature -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Any alpha testers with a bit of extra time on their hands?
Hi Curt, Ok, version 04 zip nailed it exactly ;= Now it circles PERFECTLY... I can see in Atlas that each circle exactly overlays the last... I have not yet tried adding TURBULENCE and WINDS but will... Holding exactly 150@2000, the HUD bank-o-meter seldom gets beyond the 3rd marking - that is the first big mark... I added multiplayer, but have not run across any others out there yet... This verified what I have suspected for quite a while, that the mpmap calculation of the aircraft speed is wildly erratic, showing values from 87kts to over 200kts... but I understand this is only an estimate based on current and last position over time... It is a shame the carrier, attendant boat and helicopter do not appear on multiplayer ;=() so just circling blue water... And so far, each 'gohome' has been spot on ;=)) As smooth as a babies bum... I would say, from my perspective, this bumps the demo from Alpha, to Beta or BETTER ;=)) Regards, Geoff. PS: OT: Very neat 'obscurification' of the nasal, with seemingly random generated variable names on each version... fascinating ;=() Some facts - Now I have SMOOTH graphs :- http://geoffair.org/tmp/uas-03-graph.jpg Look at the accurate circling :- http://geoffair.org/tmp/uas-03-track.jpg And the data to load into Atlas :- http://geoffair.org/tmp/uas-atlas-03.txt Or to playback in fgfs (10MB) :- http://geoffair.org/tmp/uas-03.csv Even the script I use to run the demo - http://geoffair.org/tmp/run_f14b.sh Of course it has to be ADJUSTED to suit your environment, AND uses my run_fgfs.sh to run fgfs... g. On Sat, 2011-09-24 at 17:10 -0500, Curtis Olson wrote: > Hi Geoff (and Arnt, et. al.) > > I have another update to try. This one drives the roll angle by > manipulating the ailerons directly, rather than trying to > modify /controls/flight/SAS-roll. SAS-roll worked for me, and I was > just following the example of the existing f-14b dg-heading > controller. But driving /control/flight/aileron seems to work just as > well for me. If there is some sort of order of execution problem with > nasal or something conflicting with SAS-roll, perhaps this will work > better? I'd be interested in hearing if it helps if anyone gets a > chance to try it. > > > Download link for "Alpha04" version and instructions here: > > > http://www.flightgear.org/uas-demo/ > > > Curt. > > > On Sat, Sep 24, 2011 at 11:42 AM, Arnt Karlsen wrote: > On Sat, 24 Sep 2011 12:54:05 +0200, Arnt wrote in message > <20110924125405.072bc...@nb6.lan>: > > > On Fri, 23 Sep 2011 21:06:00 -0500, Curtis wrote in message > > > : > > > > > Here's one for your guys. Do any nasal errors pop up on > the console > > > when things go bad? Are you able to manually fly the > f-14b (non-uas > > > version) around just fine? > > > ..yup, even on the eeepc keyboard, one up tap elevator, full > power, let > it roll and wait out the rotation, 2 down taps on the elevator > to keep > the nose down to 15 to 30 degrees, gets it "safely" up at 1-2 > fps. > > > > Once in maybe 20-50 flights I do see something go goofy > with the > > > f-14b stability augmentation's roll control. Maybe this > same issue > > > is popping up less rarely for some people? I haven't dug > into how > > > the SAS is implemented on the f-14b ... it's intricately > woven I can > > > tell ... maybe there's something lurking down in the guts > of the > > > f-14b SAS. > > > ..or your settings. > > > > > Curt. > > > > > > > > > > > > On Fri, Sep 23, 2011 at 8:35 PM, Arnt Karlsen > wrote: > > > > > > > On Fri, 23 Sep 2011 23:44:02 +0200, Citronnier wrote in > message > > > > <4e7cfda2.7060...@gmail.com>: > > > > > > > > > Le 23/09/2011 23:12, Curtis Olson a écrit : > > > > > > Geoff and Arnt and anyone else who is interested. I > just > > > > > > updated the zip file overlay with a few changes. > > > > > > > > > > > > Geoff: you may be getting tired of being a bunny, > but I played > > > > > > around with the roll controller and limited max > target roll > > > > > > angle to +/-35 degrees. I also dialed down the > gains a bit on > > > > > > final approach which will hopefully slow down the > wild swings. > > > > > > More adjustment may be necessary, but I'd be > interested in > > > > > > hearing if any of this helps your situation. > > > > > > > > ..a wee bit, now takes off and makes it ~1000 feet up, > then it > > > > rolls to the right and makes it ~200 feet
Re: [Flightgear-devel] fgfs hangs while loading scenery
Are you sure it's altitude related? Can you provide a way to reproduce the problem? -Jorg 2011/9/15 Michael Sgier > As soon as i change altitude of some .ac in .stg fgfs hangs at "loading > scenery" > > No my syntax is ok i can also cut half .stg to load ok but not more. > > sighwasted 2 hours on such crap... > > > > > > > -- > Doing More with Less: The Next Generation Virtual Desktop > What are the key obstacles that have prevented many mid-market businesses > from deploying virtual desktops? How do next-generation virtual desktops > provide companies an easier-to-deploy, easier-to-manage and more affordable > virtual desktop model.http://www.accelacomm.com/jaw/sfnl/114/51426474/ > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new joystick binding xml file for Logitech WingMan Interceptor
Sorry, maybe for Windows developers it is easier to get this file: http://erikstreb.de/temp/wingman-interceptor.xml.zip Erik Streb del Toro schrieb am 25.09.2011 11:33: > Hello Flight Gear developers. > > I’ve written a joystick binding xml file for the Logitech WingMan > Interceptor. The file should be placed in the > data/Input/Joysticks/Logitech directory. > > You can find the file here: > http://erikstreb.de/temp/wingman-interceptor.xml.xz > > Thank you, > Erik > > > > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2dcopy2 > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- GPG-Schlüssel-ID: 0x036B38E6 Fingerabdruck: F057 EEEB F0F5 9144 D95C BD98 B822 138F 036B 38E6 Außerdem kann man per Jabber mit mir reden (chatten): Jabber-ID: wick...@jabber.org Off-The-Record: DEBD08C2 95E7C8CE 901EC136 E39A1E43 4FC13142 signature.asc Description: OpenPGP digital signature -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] new joystick binding xml file for Logitech WingMan Interceptor
Hello Flight Gear developers. I’ve written a joystick binding xml file for the Logitech WingMan Interceptor. The file should be placed in the data/Input/Joysticks/Logitech directory. You can find the file here: http://erikstreb.de/temp/wingman-interceptor.xml.xz Thank you, Erik -- GPG-Schlüssel-ID: 0x036B38E6 Fingerabdruck: F057 EEEB F0F5 9144 D95C BD98 B822 138F 036B 38E6 Außerdem kann man per Jabber mit mir reden (chatten): Jabber-ID: wick...@jabber.org Off-The-Record: DEBD08C2 95E7C8CE 901EC136 E39A1E43 4FC13142 signature.asc Description: OpenPGP digital signature -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Toe brakes (was: Direct Draw Surface Scenery Textures)
Hi Ron, Thanks for reporting. Which set of pedals are you using? For me, both brakes report -1 when not pressed and 1 when pressed. I am using the saitek pro pedals. When looking at the raw device output (using jstest /dev/input/js[01]), I see that (usually), the toe brakes output is only -32767 or +32767 (with no intermediaries). I also typically find that when I first plug in the pedals, js_demo reports losing the device. As mentioned, this is mostly how it is reported. Sometimes the correct values are reported, which makes me believe that I'm either facing a hardware problem (which went undetected in older kernels), or the more recent kernels don't know how to handle the Saitek pedals. In any case, I might want to try downloading a debian live CD to see what kind of behavior I'm getting there (or test an older Suse installation). Cheers, Durk > > I just looked at js_demo with my toe brakes and they show the same behavior, > range is +/-1, left brake sense is reversed. > > Debian Linux 2.6.38-2-686 #1 SMP Thu Apr 7 05:24:21 UTC 2011 i686 GNU/Linux > > I have this as a configuration: (add an offset so the range is 0..2 then > multiply by 0.5) > > > Left Brake > > property-scale > /controls/gear/brake-left > -1.0 > -0.5 > > > > > Right Brake > > property-scale > /controls/gear/brake-right > 0.5 > 1.0 > > > > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
On 25 Sep 2011, at 08:36, Scott Hamilton wrote: > 2. After about 1hour of flying, FG seems to go into a endless loop; the > sound continues to play, however the screen is frozen (goes to black if you > minimise then re-maximise it), and all network activity drops off (ie: you > disappear from multi-player) > I ran it with gdb and notice the following stack; We've seen issues like that before, when _geo_inverse_wgs_84 is used over large (eg, half the planet) distances. The workaround / fix has been to switch range checks of this nature to convert coordinates to cartesian space (earth centred) and then use cartesian distance - not appropriate for navigation, but fine for a range check (and quicker too). James -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fairly recent change in sun/view position code?
On Sat, 2011-09-24 at 15:29 +0200, Frederic Bouvier wrote: > > It would be nice if Tim Moore could also fix the fog/skydome > > misalignment he introduced. > > It's a bit harsh as the previous code was also buggy It wasn't meant to be harsh but the old code worked for more than 10 years. Some problem only arose when the water reflection shader was introduced. Erik -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] latest Git next, endless loop from FGATCMgr and missing JSBsim fuel-used property
Greetings, I've noticed two small problems with the current Git "next" (as at 2011-09-25), is anyone else seeing these? 1. the JSBsim per-engine /fdm/jsbsim/propulsion/engine[]/fuel-used-lbs property has disappeared 2. After about 1hour of flying, FG seems to go into a endless loop; the sound continues to play, however the screen is frozen (goes to black if you minimise then re-maximise it), and all network activity drops off (ie: you disappear from multi-player) I ran it with gdb and notice the following stack; (gdb) bt #0 0x74be1894 in ?? () from /lib64/libm.so.6 #1 0x74be1e21 in sin () from /lib64/libm.so.6 #2 0x00be4c21 in _geo_inverse_wgs_84 (lat1=-6.78754886, lon1=-79.8275082, lat2=6.2889446375175346, lon2=99.797031571359014, az1=0x7fffd350, az2=0x7fffd348, s=0x7fffd340) at SGGeodesy.cxx:387 #3 0x00be54be in SGGeodesy::distanceM (p1=..., p2=...) at SGGeodesy.cxx:468 #4 0x00be5553 in SGGeodesy::distanceNm (from=..., to=...) at SGGeodesy.cxx:479 #5 0x004c2095 in FGATCMgr::FreqSearchRangeFilter::pass(FGPositioned *) const (this=0x7fffd550, aPos=0x2640860) at ATCmgr.cxx:260 #6 0x00a0c66c in flightgear::CommStation::findByFreq (freqKhz=11830, pos=..., filt=0x7fffd550) at CommStation.cxx:52 #7 0x004c24aa in FGATCMgr::FreqSearch (this=0xd3c9430, navcomm="comm", unit=1) at ATCmgr.cxx:271 #8 0x004c18d5 in FGATCMgr::update (this=0xd3c9430, dt=0.03) at ATCmgr.cxx:130 #9 0x004362c5 in fgMainLoop () at main.cxx:157 #10 0x004aede5 in fgOSMainLoop () at fg_os_osgviewer.cxx:283 #11 0x004389cd in fgMainInit (argc=20, argv=0x7fffda48) at main.cxx:662 #12 0x0043551c in main (argc=20, argv=0x7fffda48) at bootstrap.cxx:249 (gdb) cont Continuing. ^C Program received signal SIGINT, Interrupt. 0x74bd2024 in ?? () from /lib64/libm.so.6 (gdb) bt #0 0x74bd2024 in ?? () from /lib64/libm.so.6 #1 0x74bdce95 in atan2 () from /lib64/libm.so.6 #2 0x00be4d06 in _geo_inverse_wgs_84 (lat1=-6.78754886, lon1=-79.8275082, lat2=6.2889446375175346, lon2=99.797031571359014, az1=0x7fffd350, az2=0x7fffd348, s=0x7fffd340) at SGGeodesy.cxx:393 #3 0x00be54be in SGGeodesy::distanceM (p1=..., p2=...) at SGGeodesy.cxx:468 #4 0x00be5553 in SGGeodesy::distanceNm (from=..., to=...) at SGGeodesy.cxx:479 #5 0x004c2095 in FGATCMgr::FreqSearchRangeFilter::pass(FGPositioned *) const (this=0x7fffd550, aPos=0x2640860) at ATCmgr.cxx:260 #6 0x00a0c66c in flightgear::CommStation::findByFreq (freqKhz=11830, pos=..., filt=0x7fffd550) at CommStation.cxx:52 #7 0x004c24aa in FGATCMgr::FreqSearch (this=0xd3c9430, navcomm="comm", unit=1) at ATCmgr.cxx:271 #8 0x004c18d5 in FGATCMgr::update (this=0xd3c9430, dt=0.03) at ATCmgr.cxx:130 #9 0x004362c5 in fgMainLoop () at main.cxx:157 #10 0x004aede5 in fgOSMainLoop () at fg_os_osgviewer.cxx:283 #11 0x004389cd in fgMainInit (argc=20, argv=0x7fffda48) at main.cxx:662 #12 0x0043551c in main (argc=20, argv=0x7fffda48) at bootstrap.cxx:249 (gdb) cont Continuing. ^C Program received signal SIGINT, Interrupt. _geo_inverse_wgs_84 (lat1=-6.78754886, lon1=-79.8275082, lat2=6.2889446375175346, lon2=99.797031571359014, az1=0x7fffd350, az2=0x7fffd348, s=0x7fffd340) at SGGeodesy.cxx:398 398 tc = f*cos2saz*(4.0+f*(4.0-3.0*cos2saz))/16.0; (gdb) bt #0 _geo_inverse_wgs_84 (lat1=-6.78754886, lon1=-79.8275082, lat2=6.2889446375175346, lon2=99.797031571359014, az1=0x7fffd350, az2=0x7fffd348, s=0x7fffd340) at SGGeodesy.cxx:398 #1 0x00be54be in SGGeodesy::distanceM (p1=..., p2=...) at SGGeodesy.cxx:468 #2 0x00be5553 in SGGeodesy::distanceNm (from=..., to=...) at SGGeodesy.cxx:479 #3 0x004c2095 in FGATCMgr::FreqSearchRangeFilter::pass(FGPositioned *) const (this=0x7fffd550, aPos=0x2640860) at ATCmgr.cxx:260 #4 0x00a0c66c in flightgear::CommStation::findByFreq (freqKhz=11830, pos=..., filt=0x7fffd550) at CommStation.cxx:52 #5 0x004c24aa in FGATCMgr::FreqSearch (this=0xd3c9430, navcomm="comm", unit=1) at ATCmgr.cxx:271 #6 0x004c18d5 in FGATCMgr::update (this=0xd3c9430, dt=0.03) at ATCmgr.cxx:130 #7 0x004362c5 in fgMainLoop () at main.cxx:157 #8 0x004aede5 in fgOSMainLoop () at fg_os_osgviewer.cxx:283 #9 0x004389cd in fgMainInit (argc=20, argv=0x7fffda48) at main.cxx:662 #10 0x0043551c in main (argc=20, argv=0x7fffda48) at bootstrap.cxx:249 (gdb) The call to _geo_inverse_wgs_84() has the same values on each call, there is about 15seconds between the CTRL-C interrupts here. and I'm using the following options; --enable-real-weather-fetch --disable-ai-traffic --prop:/sim/ai-traffic/enabled=false --prop:/si
