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=48897511&iu=/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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Nice work! Will it be possible in the future to use different sound devices for fgcom and the simulator to get only the fgcom voice via the soundcard with the headset connected? For example using the main soundcard for fg and a usb headset for the communications. - -- gpg-id: D31AAEEA http://www.setho.org/people -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) iQEcBAEBAgAGBQJSFPFRAAoJEMMw//HTGq7q9p4IAJC5Cs9NA1Kk8X8xLC+mG26l J3i5DGXfj0ZvYLF12+qvmRJyJ+WO7r5VpeoaSpabywyaDbPgRpm8U2NOOL2MO9GM 17LuYQbc3IBwI1rlMGVB0KZWheP0zDz5iKNt4gMTz5MVx6c2OqkxedbuGinBbcao 0/W9QXCTgv5F4OIGRD3lVjTrlBtNxAC4iVWRgdLbC5qCRFsfaCCkiyfLHD2yFg2U ux4m4LennF2f3YJTLyliTXnlyLYtB0hRGG2LssLw8Wb+jeFqj+yu826Vg/pj83lv zeMcBMJroFKkf9aBw3KfMv3qp7TyvTnfjHrrj3X7zTxNnujeXWbYxUUYZXyLjXI= =PVZr -END PGP SIGNATURE- -- 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=48897511&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
Hi James,
On Wed, 2013-08-21 at 16:08 +0100, James Turner wrote:
>
> I've put some cash down to buy a cheap PC box
> for running Windows+Linux so I can debug these
> issues (and a few other Windows ones which are
> bugging me).
>
This is really WONDERFUL news ;=))
MSVC has a very powerful source view level debugging,
but at present this fails in some auto-generated ctor/dtor
code before it reaches 'main()' so can not be used ;=((.
In the Debug build 'new' is replaced with a 'new_dbg'
which deliberately fills the allocation with 0xcc...
so if a person does NOT initialize ALL variables simple
dtor code like 'if (buf) delete buf;' crashes.
Further it allocate more than the memory request size
and sets up a filled-with-pattern header and tail, and
returns an off-set pointer, to completely check for
buffer under and over-run on delete.
Debug config adds a rather large prologue, and epilogue to
each function, that also fills the stack variables with
a pattern, so it can warn of things like -
void foo() {
int i;
if (i) do something
will warn 'i' has not been initialized... and does
a stack pointer check in the epilogue...
And LOTS more...
Of course all this add a heavy load, and the Debug
build only ever runs at about 1/10 speed, but is
excellent for debugging, provided you can get through
all the auto-c++ code and trap at main()...
And even if you get to main(), I have NEVER had a
clean Debug exit... there are many case of heap
corruption which it seems unix/linux/mac can
overlook, like they ARE also 'overlooked' in the
windows Release build!
But I am sure fgfs will run much better if we can get
rid of some of these 'hidden-from-unix' BUGS ;=))
Let me know if I can help in any way to get you
setup with a Windows box for testing, debugging ;=))
Regards,
Geoff.
--
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=48897511&iu=/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
Hi all, Registration can be really usefull if some of our user are considering there is too many "children" on the frequency. Ebery body has the possibility to setup its own FGCom server disabling the "guest:guest" account and only accept registered pilot on their server. In this case server admin can choose who can use his server or not. He just need to add an account for each user he is accepting to use his server. If you need to restart FGCom, just un-check then re-check the "Enable" checkbox in FGCom dialog, that's done ! :) I'm not convinced adding a string is relevant, in real life you haven't a message you tell you if you are correctly connected to X frequency. The only way to check is to look at your radio, in FG it's the same. 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. As resume: - If you upgrade your server OpenRadar/FGCom standalone will be unsable until positions.txt is upgraded - If we upgrade positions.txt, your server will be unusable for OpenRadar/FGCom standalone - Until positions.txt is not upgraded OpenRadar/FGCom cannot use fgcom.flightgear.org As example, today if you use FGCom integrated and you are connected to fgcom.flightgear.org you need to set 118.175MHz (which is correct in real life) in order to be connected to Carpentras LFNH Twr. If you are connected to delta384.server4you.de you need to set 118.170MHz (which is wrong in real life) in order to be connected to Carpentras LFNH Twr. As you can see it looks like a headache... I think we are forced to break the old compatibility for a time (once every client are up to date everything will works as expected). But this new feature has revelated others projects. If we choose to develop another communication system we will break the system again... A solution could be to release a new FGCom standalone (used by OpenRadar) compatible with fgcom.flightgear.org with FG 3.0.0. Once FG (and so FGCom) 3.0.0 are released you can upgrade your server. 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 I see we share the same worries about the bandwidth, I agree we need to have a solution for sharing FGCom bandwidth. It seems IAX trunk is the solution but I don't know how to setup this for now. @Adrian: feel you free to inform me about your works for radio propagation <-> fgcom. We will see what we can do and if the server side can manage it. Regards, Clément -- 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=48897511&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
Hi, > Stuart wrote: > Now all we need is someone with enough Windows knowledge to fix the build. the Win32 builds work fine now, only FGRun for Win64 is failing. It builds fine on my machine, but on Jenkins it cannot find two Boost files. ..\..\fgrun\src\wizard_funcs.cxx(38): fatal error C1083: Cannot open include file: 'boost/algorithm/string/predicate.hpp': No such file or directory ..\..\fgrun\src\AirportTable.cxx(27): fatal error C1083: Cannot open include file: 'boost/algorithm/string/case_conv.hpp': No such file or directory These have been added by me a while ago. As said, it works fine on my machine and also for the win32 build on Jenkins. So I believe something's wrong with/missing from the Win64 setup of Jenkins that triggers the error. I cannot see what though. The file does exist: http://flightgear.simpits.org:8080/job/Boost-Win64/lastSuccessfulBuild/artifact/Boost/boost/algorithm/string/ Cheers, Gijs -- 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=48897511&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated 707
On Tue, Aug 20, 2013 at 8:34 AM, James Turner wrote: > Given that Innis has given the all-clear, what is the next step? I'm happy > to simply checkout a particular branch from the repo above and commit the > files to fgdata, but there are other options. Not sure what the other options are, but a simple checkout and commit to fgdata would be straightforward :). However, Marc wasn't sure whether some of his audio files were GPL compatible, so I think we need to wait for him to remove them before proceeding. Marc - Is that OK ? -Stuart -- 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=48897511&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 21 Aug 2013, at 16:03, Stuart Buchanan wrote: > Now all we need is someone with enough Windows knowledge to fix the > build. I've put some cash down to buy a cheap PC box for running Windows+Linux so I can debug these issues (and a few other Windows ones which are bugging me). Probably won't have everything up and running in the 2.12 timeframe, however. > >> [1] 'where there's smoke there's fire', this is old terminology from the >> Netscape/Mozilla TinderBox engine. > > I'm pretty sure the "smoke test" predates Tinderbox. I came across it > when working for Xilinx in reference to hardware testing where the first > test is to attach a power feed and check that nothing started giving off > smoke :) Haha, brilliant. James-- 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=48897511&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On Wed, Aug 21, 2013 at 3:51 PM, James Turner wrote: > On a related note, once the build problem is resolved, could we > generate a full installation RC package for testing? It would make it > easier for testers not familiar with Git to use it, and would be quite > handy for people like myself who do their development on Linux, but > have Windows systems available for testing but without the git > infrastructure or the time to download the entire git fgdata > repository. > > > Once the build is fixed, Jenkins should do exactly that - that's part of the > automation work I did for 2.10 - Jenkins will produce the complete install > EXE, someone just has to grab it from Jenkins and upload / mirror / seed it > as they see fit. That's great work, Now all we need is someone with enough Windows knowledge to fix the build. > [1] 'where there's smoke there's fire', this is old terminology from the > Netscape/Mozilla TinderBox engine. I'm pretty sure the "smoke test" predates Tinderbox. I came across it when working for Xilinx in reference to hardware testing where the first test is to attach a power feed and check that nothing started giving off smoke :) -Stuart -- 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=48897511&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On 21 Aug 2013, at 15:28, Stuart Buchanan wrote: > On a related note, once the build problem is resolved, could we > generate a full installation RC package for testing? It would make it > easier for testers not familiar with Git to use it, and would be quite > handy for people like myself who do their development on Linux, but > have Windows systems available for testing but without the git > infrastructure or the time to download the entire git fgdata > repository. Once the build is fixed, Jenkins should do exactly that - that's part of the automation work I did for 2.10 - Jenkins will produce the complete install EXE, someone just has to grab it from Jenkins and upload / mirror / seed it as they see fit. Of course, Jenkins only does what it's told by the scripts (mostly in fgmeta besides the CMake files) - so we're still at the mercy of missing files in the installer description and so on - I didn't yet automate a 'smoke test'[1] on Jenkins, since that would mean keeping a clean environment to run test installs, and involve several expensive operations since we'd be launching the sim. That's all doable but requires VMs and more energy than I have. In general I've been hoping to get enough people using the nightly builds that an automated smoke-test would be unnecessary but that's probably optimistic :) James [1] 'where there's smoke there's fire', this is old terminology from the Netscape/Mozilla TinderBox engine. -- 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=48897511&iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.12 is branched
On Thu, Aug 15, 2013 at 11:54 AM, Gijs de Rooy wrote: > Don't have much time today for further troubleshooting unfortunately; should > have some after my last exam tomorrow ;-) Hi Gijs, Have you had the chance to look at this at all, and did Geoff's suggestion help? Do we have any active Win developers around who can help fix this? On a related note, once the build problem is resolved, could we generate a full installation RC package for testing? It would make it easier for testers not familiar with Git to use it, and would be quite handy for people like myself who do their development on Linux, but have Windows systems available for testing but without the git infrastructure or the time to download the entire git fgdata repository. Thanks, -Stuart -- 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=48897511&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
