Re: [Flightgear-devel] FlightGear voice communication
On Aug 21, Clement de l'Hamaide wrote: Hello FGCom standalone is not yet ready for the new FGCom server because he use an old positions.txt file. If you upgrade your server now every OpenRadar/FGCom standalone user won't be able to connect to most of frequencies and here is my main problem... FGCom has been created with some bugs and now it's time to solve them but it require to loose the compatibility with old FGCom. That's something really hard to deal. https://gitorious.org/~bxn/fg/bxns-fgcom contains a modified fgcom (the standalone client) which has the same changes as the one embedded in the FlightGear git (range of communication as a function of aircraft altitu- de limited between 20 and 100 nm, support for 25 kHz steps frequencies, up to date source for positions of airports and frequencies e.g. apt.dat version 1000 revision 20131327). OpenRadar can use this modified fgcom and only needs the new phonebook, which is also in the repository above. Tests and feedback are welcome. The new positions file contained in the repository cannot be used with a previous version of fgcom. For information I've create a script which do all the work for you, you just need to setup a debian system, then execute the script, take a long coffee, then come back and you have a working FGCom server. The script is available at: http://clemaez.dyndns.org/build_fgcom_server.sh You should probably add this script to your fgcom repo clone and request a merge. -- bug -- Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear voice communication
On Aug 15, Dirk Dittmann wrote: Hello - Dialbook get Nummer : the search should not return the first frequency, the nearest in Range is more suitable. True, it currently returns the first in alphabetical order. As Clement answered, adding ranges, even simple one, should narrow the choice of returned. - Thinking about center controller: the dialbook could summarize all frequencies of the control area and dials one number on the server. So we have one desk for the center. Especially for OpenRadar it will be an interesting feature. What is 'center controler'? Do you mean Air Control Center i.e. En Route long distance or other FIR frequencies? - As main problem i see in the ranges of the frequencies: the apt.dat provides no info about ranges. And there are a lot of intersections between frequencies. apt.dat provides a type for each frequency (the 5x code on the line of each freq). I thought about defining a range for each type (say 20 nm for TWR freq = type 54, 10 nm for GND freq = type 53), but if it is acceptable for ground frequencies (which rarely go over a few nm) it is not for towers or approaches which can have very different ranges (at least in real life). For the overlap in the frequencies, yes there are a lot currently. It should be better with the range depending on altitude (I have a patch against fgcom to add that to the standalone fgcom as Clement already did it for the embeeded fgcom), but may not be enough. So on the long term adding ranges to frequencies based on their type is probably needed too. Approaching EDDP from east is no fun for the controller. The pilot dials to all other airports in the near until it intercepts the ils. Must be very nice if there are some ground frequencies he reaches when approaching :) IMO we should maintain a own dialbook. May bee based on apt.dat (or more realistic infos ???) + manual correction of used(atced) airports. And for this airports we need a working solution to increase the fun for atc pilot. You can find the VFR frequencies at the ICAO website. Integrating that to apt.dat would be a big work, but I would help if apt.dat was maintained and distributed in a more collaborative manner (a git repo for example). fgcom's (the standalone one) data comes from apt.dat, so the source is apt.dat. This is the point where realism meets fg reality, we have hopefully one atc at the airport and he needs a 100nm range frequency at the tower. It is the case, except when the tower frequency overlaps with another station nearby because of one having a too long range. We can fix that :) All frequencies could have the real range and each airport gets a special frequency all in one (100nm). So we can play real and real. As said, this means addind the ranges to each freq. Either with a brutal rule (such as any GND freq, never talks over 10 nm range) or using range numbers from a source (apt.dat). BTW, flightgear uses a very old apt.dat currently, this also does not help (Clement, this might even reintroduce some wrong data which is fixed in fgcom's positions.txt :)) -- bug -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with 2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Current git broken
On May 12, Thomas Geymayer wrote: Am 2013-05-12 17:59, schrieb Guy Brand: Hello Current git revision (simgear + flightgear + fgdata) of flightgear does not compile and raises an error: [ 38%] Building CXX object src/Main/CMakeFiles/fgfs.dir/__/Canvas/gui_mgr.cxx.o /home/flightgear/src/Canvas/gui_mgr.cxx: In member function ‘bool GUIMgr::handleMouse(const osgGA::GUIEventAdapter)’: /home/flightgear/src/Canvas/gui_mgr.cxx:297:48: error: no matching function for call to ‘simgear::canvas::MouseEvent::MouseEvent(const osgGA::GUIEventAdapter)’ sc::MouseEventPtr event(new sc::MouseEvent(ea)); Seems like your simgear is not up-to-date. Either you have not checked out the latest version or you have not installed it/use the correct version with flightgear. Sorry for the noise, a git pull failure on simgear bit me. -- bug -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Current git broken
Hello Current git revision (simgear + flightgear + fgdata) of flightgear does not compile and raises an error: [ 38%] Building CXX object src/Main/CMakeFiles/fgfs.dir/__/Canvas/gui_mgr.cxx.o /home/flightgear/src/Canvas/gui_mgr.cxx: In member function ‘bool GUIMgr::handleMouse(const osgGA::GUIEventAdapter)’: /home/flightgear/src/Canvas/gui_mgr.cxx:297:48: error: no matching function for call to ‘simgear::canvas::MouseEvent::MouseEvent(const osgGA::GUIEventAdapter)’ sc::MouseEventPtr event(new sc::MouseEvent(ea)); ^ /home/flightgear/src/Canvas/gui_mgr.cxx:297:48: note: candidates are: In file included from /home/flightgear/src/Canvas/window.hxx:23:0, from /home/flightgear/src/Canvas/gui_mgr.cxx:20: /usr/include/simgear/canvas/MouseEvent.hxx:34:7: note: simgear::canvas::MouseEvent::MouseEvent() MouseEvent(): ^ /usr/include/simgear/canvas/MouseEvent.hxx:34:7: note: candidate expects 0 arguments, 1 provided /usr/include/simgear/canvas/MouseEvent.hxx:30:9: note: simgear::canvas::MouseEvent::MouseEvent(const simgear::canvas::MouseEvent) class MouseEvent: ^ /usr/include/simgear/canvas/MouseEvent.hxx:30:9: note: no known conversion for argument 1 from ‘const osgGA::GUIEventAdapter’ to ‘const simgear::canvas::MouseEvent’ make[2]: *** [src/Main/CMakeFiles/fgfs.dir/__/Canvas/gui_mgr.cxx.o] Error 1 make[1]: *** [src/Main/CMakeFiles/fgfs.dir/all] Error 2 make: *** [all] Error 2 Reverting commit d9881ae[1] fixes the problem. -- bug -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. This 200-page book is written by three acclaimed leaders in the field. The early access version is available now. Download your free book today! http://p.sf.net/sfu/neotech_d2d_may ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Has ground network display vanished?
Hello AFAIR Durk committed some changes at the end of 2012 which allowed one to display the ground network through a Toggle ground network visibility item in the menu. I can't find that item any more. Has it been disabled since the last release? I'm using the git (compiled last week) version of FG. -- bug -- Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Two strange issues
On Aug 16, thorsten.i.r...@jyu.fi wrote: Hello 2) I have the Corse custom scenery http://helijah.free.fr/flightgear/scenes.html#Corse installed under my FG 2.0.0 FGData. With my GIT version, I don't actually have any scenery under FGData but instead use the commandline option --fg-scenery=/usr/share/FlightGear-2.0.0/Scenery/ That works fine everywhere else I can see, *except* for Corse (LFKJ for instance) where I see none of the objects which should be there (works fine with 2.0.0). First obvious thing - the scenery requires models installed under /Models/Region-Corse/ - so I copied that folder into my GIT FGData (and it is readable). Still no objects. What am I missing? From the extracted tarball of Corse scenery (under a Corse/ directory on my box), I had to mv Corse/Scenery/* Corse/. to be able to use them. After that adding a path to fg-scenery works as expected (I have just tried LFKJ and LFKB a few minutes ago): fgfs --fg-scenery=/home/Corse/:$FG_ROOT/Scenery/:/home/terrasync using OSG/3.0.1 and git from yesterday (simgear/flightgear/fgdata). -- bug -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Segfault in AIFlightPlanCreate
On Jul 26, Torsten Dreyer wrote: Just noticed: happens at EHAM, too. c172p, no parkpos, no live weather (Fair Weather), a few seconds after takeoff from rwy 18R. ATC Services in range button from the radio panel (F12) also does no longer show any airport frequencies (testing from EHAM with c172p too). -- bug -- Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] No liveries
On Mar 06, Arnt Karlsen wrote: ..that means you have /home/plib, /home/OpenSceneGraph, /home/simgear, /home/fgfs, /home/flightgear, /home/fgdata etc? .._dead_ wrong, you have users plib, simgear et al fight turf wars over things you should have in your own /home/guy/FG tree. Arch etc Linux are multi-user OS'es, you have set up multiple users to build FG, which is your strategic blunder. You know, on a single user box having all FG pieces installed in /home/ instead of /home/guy/ doesn't really mind. ... ..scripting your builds, is easier with Debian or Ubuntu: http://www.gitorious.org/fg/fgmeta/blobs/raw/master/download_and_compile.sh I know that script. Most of it is probably usable on ArchLinux too once the apt-*/debian stuff is stripped out. I may go that way if I don't find why Liveries/Models could be missing in such a trivial install as mine (./configure with a --prefix=/usr). Thanks for your answer -- bug -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] No liveries
Hi all,
I have a long standing issue with my installation of FlightGear. Here is
how it's set up:
* git cloned sources under /home (i.e. /home/{simgear,flightgear,fgdata})
* compilation of simgear and flightgear from the sources
cd /home/{simgear,flightgear}
git pull
./autogen.sh
./configure --prefix=/usr
make install
* data refreshed from git and terrasync
cd /home/fgdata
git pull
terrasync -v -S -d /home/terrasync
The box is running ArchLinux. Now when I start fgfs
FG_ROOT=/home/fgdata/ fgfs --fg-scenery=$FG_ROOT/Scenery/:/home/terrasync
and select the Select Livery item from the menu, the list is always
empty, no livery is available, whatever plane I choose. I've tried
softlinking /home/fgdata to /usr/share/FlightGear/data, avoiding FG_ROOT
variable, moving fgdata to /home/fgdata/data, nothing helps.
Probably related side effect: if I choose the ufo aircraft, the Select
Model panel opened by hitting the space key, only shows two items
(marker.ac and sign.ac) from the UFO model, nothing else is listed.
Is my installation wrong? Any idea where the problem could come from?
Thanks in advance
--
bug
--
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
On Nov 15, Guy Brand wrote: So I ran the metar command from the CLI to see what it told. That gives the same result for this particular airport. I was using git revision 0917a5e0. Upgrading to the current git revision 5bb247d4 also shows the same result. I haven't found another airport for which the METAR information is wrong/outdated (LFPO, KSFO, KJFK, EHAM showed correct METAR and date). Sorry, maybe I wasn't clear enough. FlightGear displays outdated METAR for LFST, ok (this can happend, and I understand the reason why a METAR data could be obsolete). FlightGear comes with a line command client called metar which also retrieves the obsolete METAR data for LFST. If I check the METAR data for LFST using another program (AeroWeather on the iPhone for example or the metar utility for debian from the http://packages.debian.org/unstable/utils/metar package), I receive correct METAR data for LFST. So METAR fetching in FlightGear is wrong. -- bug -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] METAR wrong, at least on one airport
On Nov 16, Torsten Dreyer wrote: FlightGear uses NOAA as a data source for METAR. The url to fetch the data is http://weather.noaa.gov/pub/data/observations/metar/stations/.txt where xxx is the ICAO 4-Letter code of the airport in uppercase. We simply rely on the NOAA data - if the return outdated METAR to our request, we are lost. Currently I receive up-to-date METAR for LFST, so I assume a hickup on the noaa server. Thank you for your answer. -- bug -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today http://p.sf.net/sfu/msIE9-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] METAR wrong, at least on one airport
Hello Today I noticed this on the terminal: NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG NoaaMetarRealWxController::fetchMetar(): dropping outdated METAR 2010/11/12 16:00 LFST 121600Z 19009KT 170V230 BKN030 13/09 Q1004 NOSIG So I ran the metar command from the CLI to see what it told. That gives the same result for this particular airport. I was using git revision 0917a5e0. Upgrading to the current git revision 5bb247d4 also shows the same result. I haven't found another airport for which the METAR information is wrong/outdated (LFPO, KSFO, KJFK, EHAM showed correct METAR and date). If there is anything more I can do to investigate the issue, let me know. -- bug -- Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
