Re: [Flightgear-devel] Radar Coverage and Text Display
Geoff On Tue, 2008-10-07 at 21:28 +0200, As a very concerned military simulationist (is there such a word?) I am deeply worried about military radars, indeed the whole radar thing. Every radar has it's own unique qualities - PRR, PRF, discrimination, anti-clutter, etc. From a simulation point of view radar range and target size are extremely important. An AWG-9 is not like an APS-124 nor like a SPS-10 or SPS-40, much less a Headnet C. So what I am getting at is a radar system is not inherent to a platform - but only to itself. And it's ability to find a target is unique. So, please do not lump radars into a all-in-one category. Actually - there are at least three categories: Fire control: SPG-53/AWG-9, etc. Usually they are very narrow beam, high power and provide continuous tracking Track While Scan (TWS): Medium power. Provide targeting and search. Targeting is availble by their high rotation rate (usually one second or less). (SPS-55) Search Radars: Medium Power, slow rotation rate, very long range. In aircraft typically 60 degree coverage - ships usually 360 degree. Range is usually quite long but depends on PRR and PRF. And a fourth might be the new generation of phased array - though granted they are not yet on aircraft (that I know of). Note PRR = Pulse Repetition Rate PRF= Pulse Repetition Frequency Quite frankly, I would like to see radars put into a table so they can be easily modified in/when their data become available. Janes usually offers quite accurate and unclassified data for radar systems. Best wishes for continuing development! I've done some work on this already. I've added a Terrain Warning mode and an Air to Ground mode to the weather radar. These are modelled on the Blue Parrot radar fitted to the Buccaneer, but all the major parameters are configurable in xml. I also extended it to provide a Radar Altimeter. Hidden away in it all is a simplified version of the radar equation. The most significant simplification is that radar waves travel in a straight line. The work has stopped for now. It uses some OSG code which is very heavy in terms of frame rate, and tends to make fg stagger a bit. In addition there isn't enough ground loaded into fg to make the longer ranges meaningful. Further, random objects, such as ships, and bridges etc. are not detectable (which is what I was trying to do in the first place). That said, Terrain Warning is up and running, and can be seen in the Buccaneer in CVS right now. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Braking chutes
Hi all (aircraft developers in particular), As you might have noticed from the commits list, there was a wrapper function added to controls.nas last night for braking chutes. As things stand, it is practically impossible to asssign braking chute functions to a joystick or other controller because every aircraft model handles the chute in a different way (since the Lightning was the first one in FG to model a braking chute I take no blame for this - though perhaps if I'd done it in a sane way others would have copied it :-) ) PLEASE modify your aircraft to use the controls.chuteDeploy function - override it to your heart's content in your own model. All you need to ensure is that controls.chuteDeploy(1) deploys the chute and controls.chuteDeploy(-1) jettisons the chute (if appropriate). It only took a few minutes to convert the Lightning to use the wrapper (and the Lightning's chute control stuff is a real mess - well designed models will be even easier ;-) but it should make life a lot easier for people writing controller configs and avoid the need for clumsy aircraft-specific commands in controller config files. Cheers, AJ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Braking chutes
On Wednesday 08 October 2008 10:16:28 gerard robin wrote: Hello AJ Thanks What about SpeedBrake, which could be used instead of it with some particular Aircraft (BlackBird) won't it be better to have a wrapper too ? Hi Gerard, Yes, definitely; actually I had a simple one in my own controls.nas a while ago but never got round to getting it committed. Airbrakes are an ideal candidate, because they work in quite different ways on different aircraft. Some have simple two position fully in/out selectors, others have momentary switches or sliders that allow partial deployment. The controls.nas wrapper function doesn't have to care about that though - if you want a different action from the simple default, you create your own aircraft-specific controls.airbrakeOut or whatever to override it (as we already do with flaps etc). Cheers, AJ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Braking chutes
On Wednesday 08 October 2008 10:06:38 James Turner wrote: What about multiplayer (claim one of the network shared properties?), and re-setting the chute for the next take off? Does chuteDeploy(0) specify a reset? I deliberately didn't include a reset in the spec, because AFAIK that's not something you can do from the cockpit of any aircraft. You can still add your own reset functions of course, accessible from a dialogue box or menu (as the Lightning has). Multiplayer is another thing altogether I'm afraid... making chutes display correctly (or even display at all) would require standardisation on several properties for chutes, and would be a lot more work on each model. I'd like to see it happen of course and I hope it will, but don't have the time to make that happen just now :-\ The controls wrapper by contrast is easy and quick to add to your model. I'd suggest making a small page on the Wiki (in the aircraft development section) so this information doesn't get lost in the list archives. At the moment, I think all our models with braking chutes are by people who follow this list and there aren't too many of them. The general principle of controls wrappers and how to override them is definitely worthy of an article though... Cheers, AJ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Braking chutes
On mercredi 08 octobre 2008, AJ MacLeod wrote: Hi all (aircraft developers in particular), As you might have noticed from the commits list, there was a wrapper function added to controls.nas last night for braking chutes. As things stand, it is practically impossible to asssign braking chute functions to a joystick or other controller because every aircraft model handles the chute in a different way (since the Lightning was the first one in FG to model a braking chute I take no blame for this - though perhaps if I'd done it in a sane way others would have copied it :-) ) PLEASE modify your aircraft to use the controls.chuteDeploy function - override it to your heart's content in your own model. All you need to ensure is that controls.chuteDeploy(1) deploys the chute and controls.chuteDeploy(-1) jettisons the chute (if appropriate). It only took a few minutes to convert the Lightning to use the wrapper (and the Lightning's chute control stuff is a real mess - well designed models will be even easier ;-) but it should make life a lot easier for people writing controller configs and avoid the need for clumsy aircraft-specific commands in controller config files. Cheers, AJ Hello AJ Thanks What about SpeedBrake, which could be used instead of it with some particular Aircraft (BlackBird) won't it be better to have a wrapper too ? Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Braking chutes
On mercredi 08 octobre 2008, gerard robin wrote: On mercredi 08 octobre 2008, AJ MacLeod wrote: Hi all (aircraft developers in particular), As you might have noticed from the commits list, there was a wrapper function added to controls.nas last night for braking chutes. As things stand, it is practically impossible to asssign braking chute functions to a joystick or other controller because every aircraft model handles the chute in a different way (since the Lightning was the first one in FG to model a braking chute I take no blame for this - though perhaps if I'd done it in a sane way others would have copied it :-) ) PLEASE modify your aircraft to use the controls.chuteDeploy function - override it to your heart's content in your own model. All you need to ensure is that controls.chuteDeploy(1) deploys the chute and controls.chuteDeploy(-1) jettisons the chute (if appropriate). It only took a few minutes to convert the Lightning to use the wrapper (and the Lightning's chute control stuff is a real mess - well designed models will be even easier ;-) but it should make life a lot easier for people writing controller configs and avoid the need for clumsy aircraft-specific commands in controller config files. Cheers, AJ Hello AJ Thanks What about SpeedBrake, which could be used instead of it with some particular Aircraft (BlackBird) won't it be better to have a wrapper too ? Cheers AND i forgot to say, if there will be any wrapper with Air SpeedBrake, F-8E wants it with variable positions , like we have with Flaps. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Braking chutes
On mercredi 08 octobre 2008, AJ MacLeod wrote: On Wednesday 08 October 2008 10:16:28 gerard robin wrote: Hello AJ Thanks What about SpeedBrake, which could be used instead of it with some particular Aircraft (BlackBird) won't it be better to have a wrapper too ? Hi Gerard, Yes, definitely; actually I had a simple one in my own controls.nas a while ago but never got round to getting it committed. Airbrakes are an ideal candidate, because they work in quite different ways on different aircraft. Some have simple two position fully in/out selectors, others have momentary switches or sliders that allow partial deployment. The controls.nas wrapper function doesn't have to care about that though - if you want a different action from the simple default, you create your own aircraft-specific controls.airbrakeOut or whatever to override it (as we already do with flaps etc). Cheers, AJ Yes, i understand , my previous mail about F-8E is an example of it. Since, i understood wrapper, a tool which open the free choice of any keyboard and any key feature with a Joystick or with some specific home made Cockpit, i thought that it would be very useful to have a wrapper in that case. But , i was wrong in my understanding of it . Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Braking chutes
On 8 Oct 2008, at 09:50, AJ MacLeod wrote: PLEASE modify your aircraft to use the controls.chuteDeploy function - override it to your heart's content in your own model. All you need to ensure is that controls.chuteDeploy(1) deploys the chute and controls.chuteDeploy(-1) jettisons the chute (if appropriate). Really good to see this kind of thing getting standardises as the number of aircraft using a feature increases - it's always hard to find a balance between adding new, aircraft-specific features and cleaning up old ones. What about multiplayer (claim one of the network shared properties?), and re-setting the chute for the next take off? Does chuteDeploy(0) specify a reset? I'd suggest making a small page on the Wiki (in the aircraft development section) so this information doesn't get lost in the list archives. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bad weather
hello, I couldn't resist, Today the real weather is very bad, which is an exception here on the Mediterranean sea, not far from to Toulon. I have memorized that event, with the OSG rain effect. http://pagesperso-orange.fr/GRTux/Ready-to-Jump.jpg http://pagesperso-orange.fr/GRTux/Launched.jpg Anyhow i ever like better that nice weather , don't you ? http://pagesperso-orange.fr/GRTux/Oversea.jpg -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Tacan frequencies for CLEM and CDG
Hello, This is mainly a question to Vivian. I would like to add into the carrier_nav.dat.gz file two new carrier Tacan freq one for Clemeceau the other for the coming Charles de Gaulle 12 999999 100 10900 0.000 CLM FNS Clemenceau TACAN 12 999999 100 10905 0.000 CDG FNS Charles_de_Gaulle TACAN May I do it ? Regards -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Radar Coverage and Text Display
On Wed, 2008-10-08 at 01:46 +0200, Alexis Bory - xiii wrote: Good news, I'm quite lost in the radar technical world. Hi Alexis - and everyone else who responded. It does not look to me like you are lost in the radar world. The input sent to me seems well thought out. I am glad to see that the Microsoft radars are irrelevant philosophy is not in FG. Having the radars and then having the radars in platforms is what I am most concerned with. Having it built in means less work for what I want to do with my sim which is controlling the interaction between platforms - something that FG per se- should not be doing - as it is more of a server function than an individual flight simulator function. Actually we work on a very basic level, but the aim is having a radar behavior being as near from reality as possible, I mean from a pilot's point of view. Yes, I would agree. This table exists, it is yet based by aircraft type but already includes radar name, range, and other data (originaly by Glazmax/Jettoo and updated by me). Radar types are not yet in the table but could be added easily. The idea of indexing the table upon radar name is also feasible and seems to be a very good idea :-) Yes, I see the table and I will go through it in more detail to see what is there. One of the next application would be the RWR tone which on some systems change with the frequency of the scan or goes continuous when having a steady lock. Yes, the RWR tone is very important - as in the case of attack aircraft they don't have the sophisticated receivers and displays that ships or - for example the AWACS aircraft have. The RWR tells the pilot vital information about fire control radars locking on. In recent writings it has been proposed within the simulation world to give any radar 100% detection ability out to it's maximum range. The only conflict comes into play when the radar is looking down on ground and sea clutter, where reflective returns used to show up on radar scopes. Today's processors are pretty efficient at reducing such clutter. In my own sim, I have not yet removed the probability of detection, though I probably (pun intended) will soon. Vivian Meazza wrote: Hidden away in it all is a simplified version of the radar equation. The most significant simplification is that radar waves travel in a straight line. In my world they do too. The amount of bending is very minimal given the relatively short ranges of these radars. Weather (ie cloud and atmospherics) can cause RF energy to bounce and skip sometimes great distances. But for simulation purposes I ignore these as well. In addition there isn't enough ground loaded into fg to make the longer ranges meaningful. Further, random objects, such as ships, and bridges etc. are not detectable (which is what I was trying to do in the first place). That would supposition that every object had a radar cross section/reflectivity assigned to it. Actually, that might not be hard to implement - but it would add another data field to objects. Thanks folks! -- Geoff McLean McLean Research Associates To be good is not enough when you dream of being great. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tacan frequencies for CLEM and CDG
gerard Hello, This is mainly a question to Vivian. I would like to add into the carrier_nav.dat.gz file two new carrier Tacan freq one for Clemeceau the other for the coming Charles de Gaulle 12 999999 100 10900 0.000 CLM FNS Clemenceau TACAN 12 999999 100 10905 0.000 CDG FNS Charles_de_Gaulle TACAN May I do it ? Regards Yes, go ahead, and let us know which channels you have assigned Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] wiki vandalism
A few days ago I noticed that someone had modified my AO tutorial page on the wiki. I had all images centered, and suddenly they were all left aligned. This looked horrible! I had to roll back. Just a few minutes ago I found that my Nasal page was modified as well: all blank lines before section and subsection headings were removed, only one was left before and after headings. I had put the blank lines in because I *want* them there! This makes the contents easier to edit. I'm now fed up! If someone has too much time on his hands, then he is invited to write his own stuff. Vandalizing *my* pages is not an option. I have no problem with someone fixing typos, grammar or other mistakes, of course, but this is absurd. One more such stupid edits, and I'll stop contributing to the wiki. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal OOP (wiki)
I've just added a chapter about Nasal's concept of OOP (object oriented programming). Some developers still shy away from classes, and I hope that this now changes. :-) http://wiki.flightgear.org/index.php/Nasal_scripting_language I'll review and improve that over the next days, and maybe add a few subsections and examples. m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] wiki vandalism
Just to make that clear: I don't say: don't touch 'my' pages. If you find typos, bad grammar (lots of that to be found), wrong content or other mistakes, just fix them. And if you want to add a section or two, just do it. But don't come along and fix my style, because (1) mine is better, and (2) mine is *mine*. And if I spent hours to write content, then I think I deserve that my style is respected. Or that I'm otherwise contacted and told in which way my style sucks. (Of course, I'll slap you for that, but that's a different story. ;-) m. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tacan frequencies for CLEM and CDG
On mercredi 08 octobre 2008, Vivian Meazza wrote: gerard Hello, This is mainly a question to Vivian. I would like to add into the carrier_nav.dat.gz file two new carrier Tacan freq one for Clemeceau the other for the coming Charles de Gaulle 12 999999 100 10900 0.000 CLM FNS Clemenceau TACAN 12 999999 100 10905 0.000 CDG FNS Charles_de_Gaulle TACAN May I do it ? Regards Yes, go ahead, and let us know which channels you have assigned Vivian Thanks, Because we have the existing 12 999999 100 10890 0.000 FCH FNS Foch TACAN with channel 026X I did the following 12 999999 100 10895 0.000 CLM FNS Clemenceau which is channel 026Y 12 999999 100 10900 0.000 CDG FNS Charles_de_Gaulle which is channel 027X Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
