[Flightgear-devel] FGData New Structure
Dear Everyone, I hope this is the last time we will have to discuss this topic, since over the last months it seemed that everyone agreed with that FGDATA - has to be split sometime - should be split a.s.a.p. We agreed that after the current release of 2.4 would be a good point to get the project on the way. As I offered and it still stands, I will take care of writing the bash script which splits the current FGDATA repository into multiple repositories and leaves an FGDATA repository which holds merely the bare essentials which supplement the core binary of fgfs. One could classify the contents of the new FGDATA by saying that it's data which provides the technical backbone - the common denominator everything is based upon. I'd like to cease this opportunity to give everyone the chance to utter their possible disagreement with the project or their respective opinions and discuss the very details of the split, which have not yet been determined. The general boundary conditions of the splitting process are the following: - FGDATA shall consist of everything which is essential for the binary to run and shall not hold any data which is specific to certain airports or airplanes. Those should be provided in separate repositories the structure of which is not of current interest and might possibly be chosen by the respective authors. - The change shall not require restructuring of the architecture, including the directory structure. Solely the repositories in which the data is contained shall change. Informatively, I'd like to supply a sensible suggestion for how a final structure might look and how, either as a developer or user might use it. Particularily, because some of you might wonder how we can strip FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a bad decision? Definitly not. One has to distinguish between a proper, dedicated development structure which is aligned to and substructred into independent development units and a way of deployment. As a developer, you will clone the base fgfs SC repository and you will clone the FGDATA repository. Then, depending on your field of interest you will clone the aircrafts, airports etc. you are planning to work on. You can do so with the git submodule, which will integrate the specific aircraft/airport/etc repository into the existing FGDATA repository, while keeping the commits separate. For deployment, you either manually or programatically git-submodule all data required for shipping into a branch for deployment. This includes, for instance, the KSFO tile and the c172p. It's apparent that one, among many advantages of that approach is, that the confusing redundancy between the default KSFO and the scenery KSFO, as it currently exists, will go. While the planes are the primary concern of the splitting and will bring a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and rectify a lot of redundancies and confusion, other things might also be considered, say, ./Traffic (just a lucky guess). Practically everything which is orthogonal to the core and without which FG (assuming a plane and a tile) can properly run, should migrate. regards, ManDay -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] An extension to --parkpos
Hi All, I just added some new code to src/Main/fg_init.cxx that allows FlightGear's airport dynamics functions to give you a valid parking position without having to bother about the details of whether the parking is of hte right type, whether it is large enough, etc etc. To achieve this, the --parkpos option recognizes the keyword AVAILABLE (in capitals). However, in order to get it to work, you need to set some properties: /sim/atc/radius: should be a nummeric estimate of the size of your aircraft. A small aircraft fits into a large parking, but a large aircraft does not fit into a small parking space. Because the AI part of radius is also used for slightly different purposes (prioritizing gate assignmments, the given valuem may deviate slightly from the real aircraft size. See http:/wiki.flightgear.org/Aircraft.radii for an overview of currently used values for the redius property. /sim/atc/flight-type can be any one of ga, cargo, gate, mil-fighter, mil-cargo, or vtol. See http://wiki.flightgear.org/Interactive_traffic#A_technical_perspective for more information. optionally, the property /sim/atc/airline can be set set to a three letter icao airline code. By way of illustration, I will commit a number of startup preset files setting these properties shortly. In order to simplify the procedure somewhat, I have just committed two small xml to the git fgdata repository, which you can include in your startup sequence. I deliberately keep the number of sample startup setting files small, because the system may still need some fine tuning and I don't want to end up changing hundreds of startup configuration files. To give a few examples on using the new option: Starting up a commercial 777 flight at KSFO: fgfs --aircraft=777-200ER --airport=KSFO --parkpos=AVAILABLE --config=/path/to/fgdata/Startup/777-commercial.xml Doing the same, but now explicitly requesting the startup location for a specific airline: fgfs --aircraft=777-200ER --airport=KSFO --parkpos=AVAILABLE --config=/path/to/fgdata/Startup/777-commercial.xml --prop:/sim/atc/airline=UAL This feature is highly experimental and I haven't had the chance yet to test it out on a great variety of airports (specifically not on ones without ground networks), so please use with care, but have fun. :-) Obviously, you do need to build from the latest source or get a recent snapshot dated Sept 17 or later for this to work. Cheers, Durk-- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Fwd: [Jsbsim-devel] Integrating the new JSBSim with FlightGear
Hi all,
Following the integration of the last version of JSBSim in Flight
Gear, some bugs have been reported to the JSBSim dev ML :
1. Resetting a JSBSim aircraft crashed Flight Gear
2. Aircrafts were incorrectly positioned on carriers
The attached patch seems to fix both of them. Could someone apply it
to the Flight Gear git repository ?
Thanks.
Bertrand.
-- Forwarded message --
From: grth_team grtht...@gmail.com
Date: 2011/9/17
Subject: Re: [Jsbsim-devel] Integrating the new JSBSim with FlightGear
To: Development issues jsbsim-de...@lists.sourceforge.net
Le samedi 17 septembre 2011 15:42:02, Bertrand Coconnier a écrit :
2011/9/17 grth_team grtht...@gmail.com:
Hi, Bertrand,
We have tried out the first patch, it does work.
Thus, the reset working, help to explain ( partly ) the wrong
position of Aircraft at start on Carrier.
At least with the case at heading 160 or 200 ( Nimitz ,Foch )
the Aircraft is sliding on the deck before grabbing
definitively the deck.
however, with other heading 285 , 315 ( Vinson, Clemenceau )
the Aircraft is out of the deck in water , we can't see it
sliding or falling.
The first case can be explained with the speed of the Carrier and
some delay within the groundcache processing ( which is not with
FG 24 ).
The second case is not carrier speed related , isn' it due to
the earth rotation ?
Thanks
Josh and the team
Hi Josh,
Attached is a patch that fix the issue you described (at least
according to my tests).
Could you please test it and tell if it works on your side as well
?
Cheers,
Bertrand.
Hi, Bertrand,
Your patch does it fully, carrier and reset
Thanks a lot.
David
--
GrthTeam
https://sites.google.com/site/grtuxhangar/home
diff --git a/src/FDM/JSBSim/JSBSim.cxx b/src/FDM/JSBSim/JSBSim.cxx
index eed3c68..77b006f 100644
--- a/src/FDM/JSBSim/JSBSim.cxx
+++ b/src/FDM/JSBSim/JSBSim.cxx
@@ -311,7 +311,6 @@ FGJSBsim::FGJSBsim( double dt )
temperature = fgGetNode(/environment/temperature-degc,true);
pressure = fgGetNode(/environment/pressure-inhg,true);
pressureSL = fgGetNode(/environment/pressure-sea-level-inhg,true);
-density = fgGetNode(/environment/density-slugft3,true);
ground_wind = fgGetNode(/environment/config/boundary/entry[0]/wind-speed-kt,true);
turbulence_gain = fgGetNode(/environment/turbulence/magnitude-norm,true);
turbulence_rate = fgGetNode(/environment/turbulence/rate-hz,true);
@@ -368,7 +367,6 @@ void FGJSBsim::init()
Winds-SetProbabilityOfExceedence(0.0);
}
-fgic-SetSeaLevelRadiusFtIC( get_Sea_level_radius() );
fgic-SetWindNEDFpsIC( -wind_from_north-getDoubleValue(),
-wind_from_east-getDoubleValue(),
-wind_from_down-getDoubleValue() );
@@ -376,9 +374,9 @@ void FGJSBsim::init()
//Atmosphere-SetExTemperature(get_Static_temperature());
//Atmosphere-SetExPressure(get_Static_pressure());
//Atmosphere-SetExDensity(get_Density());
-SG_LOG(SG_FLIGHT,SG_INFO,T,p,rho: fdmex-GetAtmosphere()-GetTemperature()
- , fdmex-GetAtmosphere()-GetPressure()
- , fdmex-GetAtmosphere()-GetDensity() );
+SG_LOG(SG_FLIGHT,SG_INFO,T,p,rho: Atmosphere-GetTemperature()
+ , Atmosphere-GetPressure()
+ , Atmosphere-GetDensity() );
// deprecate egt_degf for egt-degf to have consistent naming
// TODO: remove this for 2.6.0
@@ -394,7 +392,9 @@ void FGJSBsim::init()
FCS-SetDfPos( ofNorm, globals-get_controls()-get_flaps() );
+needTrim = startup_trim-getBoolValue();
common_init();
+fgic-SetSeaLevelRadiusFtIC( get_Sea_level_radius() );
copy_to_JSBsim();
fdmex-RunIC(); //loop JSBSim once w/o integrating
@@ -407,7 +407,7 @@ void FGJSBsim::init()
}
}
-if ( startup_trim-getBoolValue() ) {
+if ( needTrim ) {
FGLocation cart(fgic-GetLongitudeRadIC(), fgic-GetLatitudeRadIC(),
get_Sea_level_radius() + fgic-GetAltitudeASLFtIC());
double cart_pos[3], contact[3], d[3], vel[3], agl;
@@ -785,8 +785,8 @@ bool FGJSBsim::copy_from_JSBsim()
// Positions of Visual Reference Point
FGLocation l = Auxiliary-GetLocationVRP();
-_updateGeocentricPosition( l.GetLatitude(), l.GetLongitude(),
- l.GetRadius() - get_Sea_level_radius() );
+_updatePosition(SGGeoc::fromRadFt( l.GetLongitude(), l.GetLatitude(),
+ l.GetRadius() ));
_set_Altitude_AGL( Propagate-GetDistanceAGL() );
{
@@ -1006,26 +1006,26 @@ bool FGJSBsim::ToggleDataLogging(bool state)
void FGJSBsim::set_Latitude(double lat)
{
static SGConstPropertyNode_ptr altitude = fgGetNode(/position/altitude-ft);
- double alt;
+ double alt = altitude-getDoubleValue();
double sea_level_radius_meters, lat_geoc;
- if ( altitude-getDoubleValue() -9990 )
-alt = altitude-getDoubleValue();
- else
-alt = 0.0;
+
Re: [Flightgear-devel] ZKV1000 buildmaps.pl on Windows 7
I seem to have found the culprit. There are two Atlas distributions. I was using the one from http://atlas.sourceforge.net/index.php?page=download. There is a modified one in CVS and from http://www.geoffmclane.com/fg/atlas-07.htm The second works with buildmap.pl. The first one has the vertical band faults that I described. I am using the prebuilt Alas from the second site, as the Atlas build process seems broken (for me at least) at the moment. Alan -Original Message- From: Sébastien MARQUE Sent: Friday, September 16, 2011 6:16 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] ZKV1000 buildmaps.pl on Windows 7 Hi Allan, I think I got the clue for the confused images, can you give ./buildmaps.pl a new try? https://gitorious.org/zakharov/zkv1000/blobs/master/Systems/buildmaps.pl the mismatching tiles effect was due to already existing tiles. Thanks for your report. Regards seb Le 13/09/2011 20:38, Alan Teeder a ecrit : I am trying to integrate a moving map display into my TSR2 project cockpit and decided that a stripped down version of the ZKV1000 code would be a starting point. ZK1000 derives its maps from the Atlas maps using the above perl script. After a fight I got it to run using the command line perl buildmaps.pl c:\flightgear\atlasmaps. snip 3. The program then ran, but the images are confused. An example is at http://v-twin.dynip.sapo.pt/alan/VickersAircaft/TSR2/maps/e000n51.png showing London and the Thames estuary. The image is split into 3 vertical bands. 4. No documentation, so reverse engineering was needed to do everything. That seems to be the norm on FG ;-( , so I can´t complain about that. I am using Windows7, 64 bits, and recent versions of Active Perl and ImageMagick. Finally a question, where is the origin point of each Atlas and ZKV1000 tile image? Alan -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Le 12/09/2011 21:31, Stuart Buchanan a écrit : 2011/9/12 Mathias Fröhlich : On Sunday, September 11, 2011 21:29:28 Durk Talsma wrote: My error was in SimGear, and your fix was for FlightGear, it I'm correct. So, I'm not sure if that would fix it. Hmm, then probably not... ... but I have done the same change in the identical file in simgear now. I did not know that there ist also the same one :-/ For me, cmake works fine for SimGear, but I get the following error when attempting to cmake FlightGear: stuart@needle:~/FlightGear/flightgear$ cmake -DCMAKE_BUILD_TYPE=Release . -- Git revision is e47b05e9b459ed564193d6395cfb425148eca26c -- Could NOT find FLTK (missing: FLTK_LIBRARIES FLTK_FLUID_EXECUTABLE) -- libsvn found, enabling in terrasync -- /usr/include -- adding runtime JS dependencies -- /usr/local/include -- looking for version: 2.5.0 -- Include Dir: /usr/local/include CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:218 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:163 (find_package) /usr/local/include/simgear/version.h exists and contains the following: #define SIMGEAR_VERSION 2.5.0 so everything looks OK. I'm sure I'm doing something silly, but can't work out what, and the wiki isn't enlightening. Can anyone tell me what I'm getting wrong? -Stuart Hi, Unfortunately I'm stuck at the same point with no idea on how to solve this one. Here the error with my own paths: alexis@duck:~/fgfs/install/build-flightgear$ cmake -D CMAKE_INSTALL_PREFIX:PATH=/home/alexis/fgfs/install/fgfs -D CMAKE_BUILD_TYPE=Release -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/OpenSceneGraph -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/plib/ -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/simgear /home/alexis/fgfs/flightgear -- Git revision is f2f78e364666fcd11221a7f271de584708c025b7 -- libsvn found, enabling in terrasync -- /home/alexis/fgfs/install/plib/include -- adding runtime JS dependencies -- /home/alexis/fgfs/install/simgear/include -- looking for version: 2.5.0 CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:163 (find_package) -- Configuring incomplete, errors occurred! Thanks for helping on this one. Alexis -- 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 -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGData New Structure
Cedric wrote I hope this is the last time we will have to discuss this topic, since over the last months it seemed that everyone agreed with that FGDATA - has to be split sometime - should be split a.s.a.p. We agreed that after the current release of 2.4 would be a good point to get the project on the way. As I offered and it still stands, I will take care of writing the bash script which splits the current FGDATA repository into multiple repositories and leaves an FGDATA repository which holds merely the bare essentials which supplement the core binary of fgfs. One could classify the contents of the new FGDATA by saying that it's data which provides the technical backbone - the common denominator everything is based upon. I'd like to cease this opportunity to give everyone the chance to utter their possible disagreement with the project or their respective opinions and discuss the very details of the split, which have not yet been determined. The general boundary conditions of the splitting process are the following: - FGDATA shall consist of everything which is essential for the binary to run and shall not hold any data which is specific to certain airports or airplanes. Those should be provided in separate repositories the structure of which is not of current interest and might possibly be chosen by the respective authors. - The change shall not require restructuring of the architecture, including the directory structure. Solely the repositories in which the data is contained shall change. Informatively, I'd like to supply a sensible suggestion for how a final structure might look and how, either as a developer or user might use it. Particularily, because some of you might wonder how we can strip FGDATA of KSFO and the 172p, leaving nothing to fly with - isn't that a bad decision? Definitly not. One has to distinguish between a proper, dedicated development structure which is aligned to and substructred into independent development units and a way of deployment. As a developer, you will clone the base fgfs SC repository and you will clone the FGDATA repository. Then, depending on your field of interest you will clone the aircrafts, airports etc. you are planning to work on. You can do so with the git submodule, which will integrate the specific aircraft/airport/etc repository into the existing FGDATA repository, while keeping the commits separate. For deployment, you either manually or programatically git-submodule all data required for shipping into a branch for deployment. This includes, for instance, the KSFO tile and the c172p. It's apparent that one, among many advantages of that approach is, that the confusing redundancy between the default KSFO and the scenery KSFO, as it currently exists, will go. While the planes are the primary concern of the splitting and will bring a relief of a tremendous 4.5 Gigabytes to every user of FGDATA and rectify a lot of redundancies and confusion, other things might also be considered, say, ./Traffic (just a lucky guess). Practically everything which is orthogonal to the core and without which FG (assuming a plane and a tile) can properly run, should migrate. I think this is an offer we can't refuse. I think these proposals are as good as any, and are in line with what Tim Moore was doing. Perhaps we should go for a phased approach. In the fist phase, we could split out the aircraft, then further restructuring could form subsequent phases. Cedric might like to start work on his script as soon as possible. Vivian -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Former AI Plans - revived?
Hello, I'm ManDay (It has been critizised that I did not choose my nickname as a listname, so I wanted to tell you who I am, in case you didn't know). Just today, I received a PM from Hooray on the forums, mentioning my draft proposal for a strategy to implement AI ATC in Flightgear. Sadly, the thread received little feedback back then. Durk, to my knowledge, was still somewhere on the move, too. Meanwhile, so I've heard, he has made some efforts to implement basic ATC with takeoff permission, so I've understood. Nevertheless I'm still convinced of the proposal I've made and I was hoping that you might revisit and reconsider it - possibly giving feedback on how eligible you deem it. http://flightgear.org/forums/viewtopic.php?p=115173 regards, ManDay -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
On Sat, Sep 17, 2011 at 6:29 PM, Citronnier - Alexis Bory wrote: Hi, Unfortunately I'm stuck at the same point with no idea on how to solve this one. Here the error with my own paths: snip CMake Error at /usr/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:70 (MESSAGE): Could NOT find SimGear (missing: SIMGEAR_VERSION_OK) Call Stack (most recent call first): CMakeModules/FindSimGear.cmake:217 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) CMakeLists.txt:163 (find_package) -- Configuring incomplete, errors occurred! Thanks for helping on this one. For me, this problem seemed to magically go away a couple of evenings ago after a git pull of simgear, and fresh cmake . / make / make install of simgear. Unfortunately I've no idea what caused or fixed it. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake
Hi, I am a bit away from that stuff currently. Currently checking mail in vacation ... But: On Saturday, September 17, 2011 19:29:14 Citronnier - Alexis Bory wrote: alexis@duck:~/fgfs/install/build-flightgear$ cmake -D CMAKE_INSTALL_PREFIX:PATH=/home/alexis/fgfs/install/fgfs -D CMAKE_BUILD_TYPE=Release -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/OpenSceneGraph -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/plib/ -D CMAKE_PREFIX_PATH=/home/alexis/fgfs/install/simgear /home/alexis/fgfs/flightgear I never use CMAKE_PREFIX_PATH, so I might be wrong, but I assume that setting this value multiple times does not work like expected. Could you try -D CMAKE_PREFIX_PATH=/path/to/osg;/path/to/simgear;... instead of giving this option multiple times? The quotes are probably needed since the ; usually terminates the shell comand. Note that this ; is the list seperator of cmake. Just to better understand this attempt to solve this problem. Greetings Mathias -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An extension to --parkpos
On Sat, Sep 17, 2011 at 4:37 PM, Durk Talsma wrote: Hi All, I just added some new code to src/Main/fg_init.cxx that allows FlightGear's airport dynamics functions to give you a valid parking position without having to bother about the details of whether the parking is of hte right type, whether it is large enough, etc etc. To achieve this, the --parkpos option recognizes the keyword AVAILABLE (in capitals). However, in order to get it to work, you need to set some properties: Hi Durk, This looks like a really nice feature. Thanks! However, I think that the properties you've defined have a use beyond just ATC, so hiding them under /sim/atc and only loading them as additional config feels like a bit of a wasted opportunity to me. /sim/atc/radius: Surely this is simply a set property of an aircraft, and should be set in the aircraft-set.xml file itself, rather than in some additional Startup XML fragment? I'd say it doesn't really belong under /sim/atc as it's a general physical property of the aircraft. /sim/dimensions/radius-m perhaps? (I'm thinking that there are other physical attributes of the aircraft that might be of interest in the future - wing-span, length, door location for animated jetways/stairs, nosewheel location for towing). Similarly, /sim/atc/flight-type seems like it should be a more generic aircraft class property and should also be in the -set.xml file. It could be used by launchers and web pages to filter the various types of aircraft, as well as by ATC code. How about /sim/aircraft-class ? It might be worth having this multi-valued, so classes such as WWII fighter can be identified bit as mil-combat, and WWII. I'm think of this from the perspective of an idea I had a long time ago to allow users to filter the visible aircraft. So, for example someone might want to take part in a WWII fly-in and only see WWII era aircraft by default. Equally, being able to filter the aircraft in FGRun or the website so you only see the civilian airliners would seem to be a good idea. I'd hope that neither of these of these changes would make much difference from the AI/ATC perspective, but they open up some interesting new features. -Stuart -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Former AI Plans - revived?
Hi, On 17 Sep 2011, at 21:04, Cedric Sodhi wrote: Just today, I received a PM from Hooray on the forums, mentioning my draft proposal for a strategy to implement AI ATC in Flightgear. Sadly, the thread received little feedback back then. Durk, to my knowledge, was still somewhere on the move, too. Meanwhile, so I've heard, he has made some efforts to implement basic ATC with takeoff permission, so I've understood. Yeah that's right. Life\s been pretty busy in the beginning of the year. I do recall receiving an email from you almost a year ago. But, back then, I was at a conference, and with a very busy teaching program taking up most of my time after I came back, I had to put much of my flightgear activities on the back-burner. I just had a quick look at your pdf. While there are some parts that I immediately agree with, there are also a few other parts that I need to think a little more about. I hope to have a look at you pdf in more detail in the next few weeks and give you some more comments as I go through. My first impression after glancing through your pdf is that you'd probably be surprised how much of what you propose is either already implement (at least in terms of hooks and building blocks) or on the drawing board. But, there is still plenty of stuff left to do. More comments will follow as I think about it a little more. Cheers, Durk -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] An extension to --parkpos
Hi Stuart, On 17 Sep 2011, at 21:45, Stuart Buchanan wrote: However, I think that the properties you've defined have a use beyond just ATC, so hiding them under /sim/atc and only loading them as additional config feels like a bit of a wasted opportunity to me. Thanks for your comments. Just to expand a little on my previous mail: Your quote is exactly the reason why I wrote in my commit log that I'm only providing two sample preset files. I expect things to change considerably, but just provided these two presets as a test case. I also think that radius should get into the aircraft file, because it essentially is a physical property. For the other two, things are a little more complicated. Because they are not as strictly tied to the aircraft itself, but more to its use. Although there usually is a strong correlation between the aircraft type and it's use, there are some subtle differences. For instance, a DC10 would normally be used as an airliner (albeit one that it rapidly dissappearing from the skies), but it could also be used as a military transport. or tanker (the latter two would probably both match the mil-transport flight-type). My gut feeling is that 99.99% of all of these cases could be dealt with by the livery select mechanism; If we set the livery to be a commercial airliner, the airline, and flight-type properties should change to reflect this, and when we want it to be a ga plane, choosing the new livery should change these properties accordingly. Just wondering whether the current livery select dialog is capable of changing other properties as well. I once played with it, but that was a long time ago. With respect to changing the property names, that should be easy. They're currently used only in one single isolated section fo fg_main.cxx, so it changing names, etc. etc. is really easy. Cheers, Durk-- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] issue with replaying nmea data
Hi all, I have been experimenting with replaying nmea using the following command fgfs --fdm=external --nmea=file,in,60,atlas.save the problem i have found is that if i record a flight track at ksfo all is good and it replays as expected. if however I record at ydpo (tasmainia,australia) and then replay back to flightgear the screen is stuck on loading scenery. if i then use the following command then both terrasync and atlas keep up with the position recorded in the nmea data fgfs --nmea=file,in,60,atlas.save --log-level=bulk --atlas=socket,out,1,localhost,5500,udp --atlas=socket,out,1,localhost,5501,udp --fdm=external at the same time the logs show the following Running Main Loop === Updating time Current Unix calendar time = 1316298010 warp = 0 Current GMT = 9/17/2011 22:20:10 Current Unix calendar time = 1316298010 warp = 0 Current GMT = 9/17/2011 22:20:10 Current Julian Date = 2.45582e+06 COURSE: GMT = 8/17/111 22:20:10 March 21 noon (GMT) = 1300708800 Time since 3/21/111 GMT = 180.431 days = 180 hours = 22.3361 lon = 0 lst = 22.3361 COURSE: GMT = 8/17/111 22:20:10 March 21 noon (GMT) = 1300708800 Time since 3/21/111 GMT = 180.431 days = 180 hours = 22.3361 lon = -146.829 lst = 32.1247 Current lon=0.00 Sidereal Time = 22.1027 gst = 310.103 Current LOCAL Sidereal Time = 31.8913 (7.89133) (diff = -0.233437) parse nmea message entire message = $GPGGA,221351,4106.631,S,14649.763,E,1,,,-,F*27 input line = $GPGGA,221351,4106.631,S,14649.763,E,1,,,-,F*27 start = $ sentence = GPGGA utc = 221351 lat = -41.1105 lon = 146.829 junk = 1 junk = junk = altitude = - parse nmea message entire message = $PATLA,115.80,280.0,116.80,29.0,379*6B input line = $PATLA,115.80,280.0,116.80,29.0,379*6B start = $ sentence = PATLA GPRMC,222010,A,4106.631,S,14649.762,E,000.0,225.0,1709111,0.000,E GPGGA,222010,4106.631,S,14649.762,E,1,,,-,F PATLA,115.80,280.0,116.80,29.0,379 GPRMC,222010,A,4106.631,S,14649.762,E,000.0,225.0,1709111,0.000,E GPGGA,222010,4106.631,S,14649.762,E,1,,,-,F PATLA,115.80,280.0,116.80,29.0,379 AICarrier: Inside Operating Box AICarrier: Inside Operating Box AI Manager: AI model return list size 2 Scheduling Flights for : Aircraft/757/757-UnitedAirlines.xml N816UA KORD Flight UNITED657: KJFK: Sat Sep 17 20:59:00 2011: KLAX: Sun Sep 18 03:00:00 2011: Flight UNITED4215: KLAX: Sun Sep 18 16:17:00 2011: KJFK: Sun Sep 18 21:45:00 2011: Flight UNITED771: KJFK: Mon Sep 19 01:29:00 2011: KLAX: Mon Sep 19 07:30:00 2011: Flight UNITED416: KLAX: Mon Sep 19 19:53:00 2011: KJFK: Tue Sep 20 01:25:00 2011: Flight UNITED4196: KJFK: Tue Sep 20 11:50:00 2011: KLAX: Tue Sep 20 17:48:00 2011: Flight UNITED416: KLAX: Wed Sep 21 19:33:00 2011: KJFK: Thu Sep 22 01:05:00 2011: Flight UNITED771: KJFK: Thu Sep 22 01:29:00 2011: KLAX: Thu Sep 22 07:30:00 2011: Flight UNITED4215: KLAX: Thu Sep 22 16:17:00 2011: KJFK: Thu Sep 22 21:45:00 2011: Flight UNITED771: KJFK: Fri Sep 23 01:29:00 2011: KLAX: Fri Sep 23 07:30:00 2011: Flight UNITED416: KLAX: Fri Sep 23 19:53:00 2011: KJFK: Sat Sep 24 01:25:00 2011: Flight UNITED255: KJFK: Sat Sep 24 01:29:00 2011: KLAX: Sat Sep 24 07:30:00 2011: Done Traffic Manager: Flight is in progress, %=0.224838 Traffic manager: N816UA is scheduled for a flight from KJFK to KLAX. Current distance to user: 6498.48 Updating adjusted fog parameters. Updating light parameters. Sun angle = 67.1352 ambient = 0.598634 diffuse = 0.982157 specular = 0.291869 sky = 0.991292 Updating Sun position Gst = 22.1027 t-cur_time = 1316298010 Sun Geocentric lat = 0.036879 Geodcentric lat = 0.036879 sun angle relative to current location = 1.17168 FGTileMgr::update() State == Running Splash screen progress loading scenery any thoughts on how to solve this thanks jason cox -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] various databases +- ground truth ; was: Openstreetmap ...
On 09/16/2011 04:47 AM, HB-GRAL wrote: I provide a ESRI Shapefile on my server of the airports of ourairports.com database http://maptest.fgx.ch/data/ourairports.zip There is a column type, and some airports have value closed. All this data is in public domain, if someone wants to play around with it or want to check something. Thanks, that's interesting. For some purposes, the ESRI files may or not be the most useful or transparent representation; for some purposes it may be more useful to look at http://www.ourairports.com/data/airports.csv http://www.ourairports.com/data/runways.csv http://www.ourairports.com/data/airport-frequencies.csv and other files as described at http://www.ourairports.com/data/ The data from ourairports is in some ways more sophisticated than from apt.dat. For example, it gives the elevation of *each end* of each runway, rather than simply field elevation. In some parts of the world this is valuable information for pilots. AFAICT the ourairports data could be used to provide useful information for airports that are missing from apt.dat ... maybe not ideal but way better than nothing. Somebody could write a script to do the translation ... or we could just read the ourairports files directly. OTOH apt.dat has taxiway information for some airports, whereas I don't know of any such information at ourairports.com. If I have overlooked something, please let me know. FWIW I have a prog that reads apt.dat and writes kml, which can then be imported into your favorite GIS such as GRASS or google-earth. The idea is to make it easy to compare apt.dat to the ground truth. I haven't taught it how to read ourairports databases, but that wouldn't be hard. Here is another way in which the ourairports database can be put to very good use: It provides ISO region codes -- which apt.dat does not. These codes provide the basis for a very good way of predicting which runway numbers will have a leading zero. Compared to guessing always leading zero or never leading zero this reduces the error rate by at least two orders of magnitude. Doing a join on the two databases is easy. As for the reliability, comparing ourairports to apt.dat on fields that they both provide, it appears we have a Venn diagram with all five possibilities: -- Airports where they are both correct. -- Airports where apt.dat is right and ourairports is wrong. -- Vice versa. -- Airports where they are both wrong in different ways. -- Last but not best, airports where they are both wrong in the same way, so we don't learn anything by cross-checking. For example, there are some airports that were wiped out and replaced with condos many years ago, but still show up in both databases. FWIW here are the fields in some of the ourairports files: Airports: id,ident,type,name,latitude_deg,longitude_deg,elevation_ft,continent,iso_country,iso_region,municipality,scheduled_service,gps_code,iata_code,local_code,home_link,wikipedia_link,keywords Runways: id,airport_ref,airport_ident,length_ft,width_ft,surface,lighted,closed,le_ident,le_latitude_deg,le_longitude_deg,le_elevation_ft,le_head ing_degT,le_displaced_threshold_ft,he_ident,he_latitude_deg,he_longitude_deg,he_elevation_ft,he_heading_degT,he_displaced_threshold_ft, Frequencies: id,airport_ref,airport_ident,type,description,frequency_mhz -- BlackBerryreg; DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
