Re: [Flightgear-devel] Musings on FG on Linux/Windows
On Tuesday 27 November 2012 07:56:02 Renk Thorsten wrote: Binary releases on Linux are /possible/ but a pain - working with each distro's packaging system is definitely the way to go, in my opinion. That basically seems to require that everyone who wants most recent FG needs to update to most recent Linux. No it doesn't. There's nothing preventing us from providing packages for older distribution versions. On the openSUSE Build Service it's usually just selecting the versions and packages will get built automatically. Stefan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on FG on Linux/Windows
On 27 Nov 2012, at 08:01, Stefan Seifert n...@detonation.org wrote: That basically seems to require that everyone who wants most recent FG needs to update to most recent Linux. No it doesn't. There's nothing preventing us from providing packages for older distribution versions. On the openSUSE Build Service it's usually just selecting the versions and packages will get built automatically. Right - you can supply packages for Ubuntu 9.04 if you like - (and we probably should, for the current Ubuntu LTS release) - and the same for Fedora. As I said, I think the *only* thing missing is motivated Fedora and Ubuntu users with sufficient knowledge of SRPMs/debs/scripting - keeping in mind we already have official packages for those distros, created by people 'outside' FG, *and* various developers here have worked hard to ensure the code builds cleanly - that was the reason for support a shared-library mode in SimGear. And I will gladly assist/review *any* code change that helps / simplifies / reduces patches to make the above work - I really do want to see it happen - I'm just clueless about Linux packaging! James -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on FG on Linux/Windows
No it doesn't. There's nothing preventing us from providing packages for older distribution versions. This sounds very neat, and if this works in practice, then I take my comment back - being able to get an rpm for any major Linux distribution would be equivalent to the Windows installer in terms of usability. * Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
Update: I've added new signal calculation for DME stations too. As explained detailed in the wiki, DME uses a very high frequency range, thus it is possible sometimes in reality to receive the VOR signal but not the DME signal. Screenshots provided in the wiki article. Also, TACAN reception is modelled now like the DME, since it uses basically the same frequency range. Unlike DME, I have not tested this yet, but should also work for AI/multiplayer tankers. All this disabled by default, of course. I have not updated the merge request with these features yet, waiting for the new radio to make it into 'next' since it's enough code there already. I have also added a Request for info chapter in the wiki page, asking anybody with deep knowledge of air navigation systems to contribute info on the discussion page. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On 27 Nov 2012, at 12:44, Adrian Musceac kanto...@gmail.com wrote: I have not updated the merge request with these features yet, waiting for the new radio to make it into 'next' since it's enough code there already. I have also added a Request for info chapter in the wiki page, asking anybody with deep knowledge of air navigation systems to contribute info on the discussion page. Gitorious was down this morning, or I would have already given some review comments. However I see quite a few new versions of the patch, it would be good to know it's 'ready' from your perspective, before reviewing. I too would prefer to merge smaller patches - I didn't yet see how big the current one is, since Gitorious is still being silly. James -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids radio propagation code almost production ready
On Tuesday, November 27, 2012 14:53:07 James Turner wrote: Gitorious was down this morning, or I would have already given some review comments. However I see quite a few new versions of the patch, it would be good to know it's 'ready' from your perspective, before reviewing. I too would prefer to merge smaller patches - I didn't yet see how big the current one is, since Gitorious is still being silly. James Hi James, Thanks for reviewing the code. Gitorious is back for me now. The code is production ready and tested, I've just added some little fixes and improvements in the new versions, which don't affect stability on my system. I think it would be best to review and merge as disabled by default, and then allow users to test and find bugs. I can't do that properly alone. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Implementing realistic radar inside the Flightgear engine
Hi, I've seen a couple of external radar clients for Flightgear being developed right now. I think that these days, with the advent of Canvas and other improvements, it should be possible and desirable to have a realistic radar station inside Flightgear. At the moment, I'm only concerned about radar ranges and interference of terrain obstructions, weather, ground clutter. For this purpose, I propose a template implementation of radar transceivers and transponders: It is not possible to provide a detailed terrain picture on every antenna rotation. Sampling all terrrain 360 degrees around the station would cripple performance. Thus, I would just take all positions of aircraft inside the nominal range and perform radio calculations on them, using larger sampling distances and simpler routines for aircraft above a treshhold flightlevel. If terrain around the antenna is obstructing the signal, or weather affects it, we can simulate that correctly. Transponder responses are also a candidate for the new radio code. Like in reality, it is possible to have radar contact but lose transponder id because of radio issues. Awaiting comments, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine
On Tue, Nov 27, 2012 at 1:03 PM, Adrian Musceac wrote: Hi, I've seen a couple of external radar clients for Flightgear being developed right now. I think that these days, with the advent of Canvas and other improvements, it should be possible and desirable to have a realistic radar station inside Flightgear. I recently implemented a vertical terrain clearance radar for the Douglas A4F Skyhawkd (a4f) using a combination of Canvas and Nasal terrain lookups. The code is checked into git if you are interested. My main concern when writing it was minimizing the number of terrain lookups per radar sweep. For the vertical mode this is quite straightforward as I've simplified the sampling to getting the elevation of points every 1nm ahead. I've still to look at the horizontal modes, but I suspect it would need a Nasal enhancement to perform terrain intersection tests based on a lat/lon/heading/pitch combination. I haven't looked into how much effort it would be to add that yet, though I suspect it should be fairly straightforward given that we already have similar function handling mouse-clicks for the ufo. -Stuart -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine
On Tuesday, November 27, 2012 15:23:13 Stuart Buchanan wrote: I recently implemented a vertical terrain clearance radar for the Douglas A4F Skyhawkd (a4f) using a combination of Canvas and Nasal terrain lookups. The code is checked into git if you are interested. My main concern when writing it was minimizing the number of terrain lookups per radar sweep. For the vertical mode this is quite straightforward as I've simplified the sampling to getting the elevation of points every 1nm ahead. I've still to look at the horizontal modes, but I suspect it would need a Nasal enhancement to perform terrain intersection tests based on a lat/lon/heading/pitch combination. I haven't looked into how much effort it would be to add that yet, though I suspect it should be fairly straightforward given that we already have similar function handling mouse-clicks for the ufo. -Stuart Hi Stuart, I'm fairly aware of how AG radar modes work, from f16 detailed documentation, but know next to nothing about terrain clearance radar. I will check this out and provide feedback if I can. I have no idea though about Nasal terrain sampling performance. I need to read more about this. I know the advanced weather system uses a C++ random area terrain sampler written by Torsten Dreyer. However, I should have made it clear in my previous message that I was referring to ground-to-air radar, hardcoded as a subsystem, with only the visual interface written with Canvas/Nasal. Cheers, Adrian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Musings on FG on Linux/Windows
On Tue, 27 Nov 2012 09:39:42 +, Renk wrote in message e495a106ff5f31448739e79d34138c191e169...@mbs1.ad.jyu.fi: No it doesn't. There's nothing preventing us from providing packages for older distribution versions. This sounds very neat, and if this works in practice, then I take my comment back - being able to get an rpm for any major Linux distribution would be equivalent to the Windows installer in terms of usability. ..the best way to get there, is build upon scripts like: http://wiki.flightgear.org/Scripted_Compilation_on_Linux_Debian/Ubuntu and http://geoffair.net/fg/ ... ...like http://wiki.flightgear.org/CentOS does, and build deb, rpm etc distro packages, rather than just build binaries out of the sources. ..in the Debian, Ubuntu etc world, .deb packages can be built like: http://www.linuxjournal.com/content/using-checkinstall-build-packages-source or http://www.debian.org/doc/manuals/maint-guide/build.en.html from http://www.debian.org/doc/manuals/maint-guide/index.en.html ..for rpm, I recommend reading the output of 'man rpmbuild'. .._sometimes_, deb, rpm etc packages can be converted to other distro packaging formats with /usr/bin/alien, details in 'man alien', this approach may fail on e.g. Ubuntu developers disagreeing with Debian .deb packaging policy, or a rpm database not seeing conflicts coming with a .deb binary, checkinstall may help you solve those conflicts. ..some guys are just plain lucky, e.g. http://wiki.flightgear.org/Building_Flightgear_-_Gentoo ..these build scripts can also be packaged as e.g. deb, rpm etc meta-packages that can be used to e.g. set up a build server. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine
Stuart, The Buccaneer in fgdata has had a terrain clearance radar for many years now, using just the technique you describe. It's written in C++. It has a horizontal mode - but I never got it to work satisfactorily at a frame rate I liked. Vivian From: Stuart Buchanan [mailto:stuar...@gmail.com] Sent: 27 November 2012 13:23 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine On Tue, Nov 27, 2012 at 1:03 PM, Adrian Musceac wrote: Hi, I've seen a couple of external radar clients for Flightgear being developed right now. I think that these days, with the advent of Canvas and other improvements, it should be possible and desirable to have a realistic radar station inside Flightgear. I recently implemented a vertical terrain clearance radar for the Douglas A4F Skyhawkd (a4f) using a combination of Canvas and Nasal terrain lookups. The code is checked into git if you are interested. My main concern when writing it was minimizing the number of terrain lookups per radar sweep. For the vertical mode this is quite straightforward as I've simplified the sampling to getting the elevation of points every 1nm ahead. I've still to look at the horizontal modes, but I suspect it would need a Nasal enhancement to perform terrain intersection tests based on a lat/lon/heading/pitch combination. I haven't looked into how much effort it would be to add that yet, though I suspect it should be fairly straightforward given that we already have similar function handling mouse-clicks for the ufo. -Stuart -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)
On Mon, Nov 19, 2012 at 10:04 AM, Stuart Buchanan wrote: On Sun, Nov 18, 2012 at 9:48 AM, Thorsten Renk wrote:- rain bug - that still persists, rain is broken in Advanced Weather since currently setting the rain norm doesn't necessarily generate rain as the underlying system tries to be smart and parses the cloud layer altitude of Basic Weather - which is zero in Advanced Weather. Can anyone help here? I think this can be fixed before the release. I'll take a look at this - it's been on my TODO list for a while. This is now done. You can now set /environment/params/use-external-precipitation-level=true to disable the previous behaviour of only showing rain under the heaviest cloud layer, and set /environment/params/external-precipitation-level-m to set the maximum altitude at which precipitation will occur. 0 means it will occur at all levels. -Stuart -- Keep yourself connected to Go Parallel: DESIGN Expert tips on starting your parallel project right. http://goparallel.sourceforge.net___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] JSBsim latest release
Hi - I'd like to use the latest JSBsim release with FG. I've already downloaded the latest JSBsim, what needs to be set in order to run FG with it ? kunai090 -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Implementing realistic radar inside the Flightgear engine
I have no idea though about Nasal terrain sampling performance. Pretty good these days - whenever a convective weather system is set up, we use about O(1000-2000) terrain elevation sampling points to generate the cloud-terrain interaction, they're done at a rate of 20 per frame. On my old computer, this is visible in the framerate indicator as a temporary reduction, on my new computer it doesn't even show. If you evaluate 1-5 rays per frame, you're certainy not causing massive performance drain. I know the advanced weather system uses a C++ random area terrain sampler written by Torsten Dreyer. Yes - but the way this is currently set up it wouldn't help you - it just samples various averages and variances of the elevation, it can't be used to give you a profile of the terrain. * Thorsten -- Keep yourself connected to Go Parallel: INSIGHTS What's next for parallel hardware, programming and related areas? Interviews and blogs by thought leaders keep you ahead of the curve. http://goparallel.sourceforge.net ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
