[Flightgear-devel] Version numbers on the splash screen ?
Hi all, I just thought that displaying Flightgear and the aircraft version numbers on the splash screen could help a bit the supporting effort we do on the forum and the users list. Thinking out loud, Alexis -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Git advice
James Turner wrote: On 27 Dec 2008, at 15:04, Tim Moore wrote: Here's my workflow for using git with the FlightGear sources in CVS. Note that there are separate repositories for Fightgear, Simgear and the Flightgear data. This is inconvenient and there may a workaround using git submodules, but I haven't explored that yet. Finally got around to following this advice, thanks Tim. Two questions: (for anyone who knows git, not just Tim) - when I want to sync the main repo with the cvs-import one, your instructions say 'git fetch', but I seem to need to 'git pull' to get the master branch in sync with the origin. It works fine, I guess I'm just mis-understanding what fetch actually does? As Thomas mentioned, git fetch only updates your local copy of the remote branches; git pull does that and then merges the remote branch with your local. I like to fetch and then rebase my local work without merging; it makes it much easier to get the commits into CVS via git-cvsexportcommit. When we move to git and publish (sometimes) personal branches, I'll probably switch back to git-pull. - when I rebase my topic branches (having fetch + pull-ed to the master), I'm getting some (10 at the moment of these:) /Users/jmt/Code/Macflightgear/flightgear/FlightGear-git/.git/rebase- apply/patch:31: trailing whitespace. I assume this is innocuous, but I wonder if anyone can explain what I might have done to cause this? Linus doesn't like whitespace at the end of lines or whitespace before a tab at the beginning of a line. Git can be configured to reject changes that introduce bogus whitespace, but by default just warns you. Tim -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] X-15 update
Hum experiencing some unexpected results. I have reworked the engine parameters (the old files will definitely NOT work on the current version of FlightGear). I have also removed all form of SAS so that I can start working in Nasal (to simulate hydraulics ...). Here are the results. a/ The aircraft flies quite well without SAS . It is less stable, but also more responsive, as could be expected, and there is no longer the vibrating tail phenomenon (unlimited speed elevators). Also there is no longer the overresponse in pitch down. b/ You can retain a LOT of aerodynamic control even at 400 000 feet. I expect this to be due to a wrong extrapolation of pressure/density for high altitude, but it is really a nuisance for the X15 since the aircraft went completely ballistic at 200 000ft. 500KIAS at those altitudes is just not convincing. Have to check whether this is really due to the modelling of atmosphere or improper computation of the Airspeed. If it is an issue with atmosphere, would it be a problem if I tried to extend the model to higher altitudes ? c/ Having looked in the source of JSBSIM I read that a rocket connected to only a fuel tank is assumed to be a solid rocket. Annoying if you consider that hydrazine and hydrogen peroxide have been used as liquid monopropellants for restartable rockets (STS OMS and H2O2 RCS on the lunar lander come to my mind)... Message du 05/01/09 à 01h44 De : Jon S. Berndt jonsber...@comcast.net A : flying.toas...@voila.fr, 'FlightGear developers discussions' flightgear-devel@lists.sourceforge.net Copie à : Objet : RE: [Flightgear-devel] X-15 update Sounds good. However, on the topic of the rockets (and if you are referring to the existing JSBSim X-15 FDM), I just reworked the rocket engine code shortly ago. Don't use the external_forces section for rocket control. I've got tons of information on the X-15, some of which was gained using FOIA requests. Nowadays, you can simply use the NTRS, like you mentioned. Jon -Original Message- From: flying.toaster [mailto:flying.toas...@voila.fr] Sent: Sunday, January 04, 2009 4:08 PM To: flightgear-devel Subject: [Flightgear-devel] X-15 update I have resumed work on the X-15. I want to model every single thing (from the last bottle of hydrogen peroxide to the historical launch sites) for three aircraft configuration : X15 #1 : Old style flight deck, old style SAS and RAS (later standing for Reaction Augmentation System). X-15 #2 : X-15A2 configuration with drop tanks and new airframe (the one that set the speed record and almost burnt in the process of doing so) X15 #3 : New style flight deck, Adaptive Flight Control System (a.k.a.: MH96), but basic airframe Here are a few hurdles I still have to overcome : I've got myself a lot of documentation (in part thanks to the Nasa Technical Report Server), yet some of the documentation may not be available for download (have to collect a list and then see if it can be ordered) Quite interestingly I guess there is some inconsistency in the references of the current FDM. Particularly, an article on the MH96 is mentionned as the basis of the SAS gains...That would make the current FDM representative of the X15 #3 configuration. The thing I am missing is that the MH96 apparently used a feedback loop to vary the control gain, which I do not find in this FDM. What's more, the MH96 used a model of the aircraft in order to impose an artificial behavior (the aircraft remained at constant g at low speed without trim for instance). The original SAS was much simpler, the pilot choosing the gain according to the mission among 12 preset (discrete resistors !) values per axis I think I will have to resort to external forces for all rockets in the aircraft (including the main one). Rate of consumption for fuel and oxydizer needs to be adjusted according to which tank is tapped by which rocket (if you count Ballistic Control System, and the 2 stage igniter, there were something like 17 rockets on this aircraft). Some of the rockets use monopropellants (H2O2 for the ballistic controls) and even more gruesome, the APU is served by the same tanks as the reaction control rockets (BCS), and can be crossfed by the main engine turbopump supply. If anybody can give me help in the form of information and/or advice wish me luck ;) Consultez les dernires news dIndochine et coutez leur single Little Dollssur Musiline Voila! http://musiline.voila.fr/resume/235 --- --- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Git advice
On 7 Jan 2009, at 19:05, Tim Moore wrote: I like to fetch and then rebase my local work without merging; it makes it much easier to get the commits into CVS via git-cvsexportcommit. When we move to git and publish (sometimes) personal branches, I'll probably switch back to git-pull. Ah, that's interesting. I tried git-cvsexportcommit for the first time yesterday, and it worked okay (with me git-pulling to the local master and then rebasing my topic branches to it). But it makes sense (now) that I can fetch and rebase with no merging. Thanks, James -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Git advice
On 01/07/2009 01:19 PM, James Turner wrote: On 7 Jan 2009, at 19:05, Tim Moore wrote: I like to fetch and then rebase my local work without merging; it makes it much easier to get the commits into CVS via git-cvsexportcommit. When we move to git and publish (sometimes) personal branches, I'll probably switch back to git-pull. Ah, that's interesting. I tried git-cvsexportcommit for the first time yesterday, and it worked okay (with me git-pulling to the local master and then rebasing my topic branches to it). But it makes sense (now) that I can fetch and rebase with no merging. That's all fine and true when spoken from one committer to another. But for everybody else, the merge function exists for a reason. Suppose a committer gets two patches, one from Wilbur and one from Orville, and applies them both to the same file. They don't conflict, so all is well, and the committer can rebase without merging. However ... Wilbur will have to do a merge, and Orville will have to do a merge. This should be smooth and easy, since the patches don't conflict, but it is still a merge. The merge function exists for a reason. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] FG ocean water shader / water region issue.
Hello ! In past couple of weeks I wrote GLSL-based shader for fluid surfaces and now trying to deploy it into FlightGear. As far as I know - there's no diference between solid and liquid surfaces from FG/SG point of view. In other words - rivers, lakes, ocean are a part of TerraGear scenery (except OceanTiles for non existent BTG-s of course). To make shader work propertly - probally I have to embedd a fluids into separate graph of scene (or into a subgraph of terrain), and assign a StateSet, containing shader and all of it data to it. If anyone have any idea or suggestion - how water can be separated from terrain, please drop me a note, right now all idea I have is only to determine quality of a BTG object by it's material name. -- Vladimir Karmishin ASTRA Development Inc. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG ocean water shader / water region issue.
On mercredi 07 janvier 2009, Vladimir Karmisin wrote:
Hello !
In past couple of weeks I wrote GLSL-based shader for fluid surfaces and
now trying to deploy it into FlightGear.
As far as I know - there's no diference between solid and liquid surfaces
from FG/SG point of view. In other words
- rivers, lakes, ocean are a part of TerraGear scenery (except OceanTiles
for non existent BTG-s of course).
To make shader work propertly - probally I have to embedd a fluids into
separate graph of scene (or into a subgraph
of terrain), and assign a StateSet, containing shader and all of it data to
it.
If anyone have any idea or suggestion - how water can be separated from
terrain, please drop me a note, right
now all idea I have is only to determine quality of a BTG object by
it's material name.
Hello
I am not sure that could answer your question, however i do use the following
nasal script to know if there is water or solid under.
terrain_under = func {
var lat = getprop(/position/latitude-deg);
var lon = getprop(/position/longitude-deg);
var info = geodinfo(lat, lon);
if (info != nil) {
if (info[1] != nil)
setprop(/environment/terrain,info[1].solid);
#print(and it is , info[1].solid ? solid ground : covered by
water);
#debug.dump(geodinfo(lat, lon));
}else {
setprop(/environment/terrain,1);
}
settimer (terrain_under, 0.1);
}
so :)
Happy new year
--
Gérard
http://pagesperso-orange.fr/GRTux/
J'ai décidé d'être heureux parce que c'est bon pour la santé.
Voltaire
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [BUG] division by zero in YASim/Airplane.cpp (possibly caused by bad 787 model)
0x006a3b59 in yasim::Airplane::compileFuselage
(this=0xc066688, f=0x7f84f00bf930) at src/FDM/YASim/Airplane.cpp:512
512 float segWgt = len*wid/segs;
(gdb) p segs
$1 = 0
(gdb) p *f
$3 = {front = {-13.604, 0, 1.3998}, back = {-13.604, 0,
1.3998}, width = 5.901, taper = 0.10001,
mid = 0, _cx = 1, _cy = 1, _cz = 1, _idrag = 1}
Possible cause in Aircraft/787/787.xml:
fuselage ax=-13.6 ay=0 az=1.4 bx=-13.6 by=0.00 bz=1.4
width=5.9 taper=0.1 midpoint=0/
--
Csaba/Jester
--
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
75:: As of 1.9.0, in the c182, the altimeter is not self-consistent. There is an analog scale and a digital readout. It takes 10 clicks of the Kollsman setting knob to move the digital readout ten hundredths of an inch. It takes 14 or 15 clicks to rotate the analog scale the corresponding amount. Neither readout appears to produce entirely accurate altimetry, although the analog scale is clearly worse. This is highly unrealistic. There exist other altimeter models that are both prettier and more functional. 76:: Newton’s laws are still being violated by environment.cxx. The pressure profile (P versus h) is incorrect. This has many consequences. It greatly affects altimetery, but also affects engine performance, airfoil performance, et cetera. In particular it means the simulator fails to exhibit the HALT phenomenon (high altimeter because of low temperature). For quantitative details on this, see http://www.av8n.com/fly/fgfs/htm/bug-list.htm This bug has been known for years. The code to fix it was written years ago, but not incorporated. 77:: In the default c172p model, sitting on the runway at KSFO, at full power the engine consumes about 78 pph of fuel. So far, so good. Now stop the engine by pulling the mixture to cutoff. I observe that the fuel flow, as reported by the FDM via the property tree, settles above 8 pph. That’s more than a gallon per hour, with no mixture and no revs. That seems like rather a large leak. Similar phenomena have been observed in other aircraft models. 78:: As of 1.9.0, in the c182rg, I observe that the menu item reload panel doesn’t reload the panel. Shift-F3 doesn’t reload the panel either. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault of the day
79::As of 1.9.0, changing helvetica-bold to helvetica in e.g. Instruments/altimeter.xml causes the cockpit/panel loader to segfault. a) It would be nice if helvetica were supported. b) Failing that, if helvetica is called for it would be nice to print a warning and substitute some similar font. -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
On Wed, 2009-01-07 at 17:34 -0700, John Denker wrote: 77:: In the default c172p model, sitting on the runway at KSFO, at full power the engine consumes about 78 pph of fuel. So far, so good. Now stop the engine by pulling the mixture to cutoff. I observe that the fuel flow, as reported by the FDM via the property tree, settles above 8 pph. That’s more than a gallon per hour, with no mixture and no revs. That seems like rather a large leak. Similar phenomena have been observed in other aircraft models. In the code FuelFlow_gph is the canonical property, FuelFlow_pph is only calculated when we actually consume fuel. Slamming the mixture to 0 at a high fuel flow rate causes consumption to stop leaving the FuelFlow_pph value unable to update and stuck indicating a high value. If you'll notice, fuel is not actually flowing, its just an incorrect indication. Ron -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] a few more bugs
In the code FuelFlow_gph is the canonical property, FuelFlow_pph is only calculated when we actually consume fuel. Slamming the mixture to 0 at a high fuel flow rate causes consumption to stop leaving the FuelFlow_pph value unable to update and stuck indicating a high value. If you'll notice, fuel is not actually flowing, its just an incorrect indication. Ron Still, this sounds like a code bug. I'll take a look. Jon -- Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
