Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
Dave Martin wrote: On Tuesday 28 Dec 2004 23:38, Jon Stockill wrote: Would it not be easier to generate an image containing all the required characters in known positions so that they could be displayed in the correct position - otherwise you're creating a dependency on imagemagick, which is not a small package. Thats an interesting idea; Perhaps, all the characters could be generated and then used to texture a mesh in the location where the reg. is displayed. (The mesh would be specially placed just to accept reg letters). Is this what you were getting at? Yes. You've then removed the dependency, and the display of the registration could probably even be handled with the xml config, just by poking the registration into the correct place in the property tree. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tue, 28 Dec 2004 23:33:16 +, Dave wrote in message [EMAIL PROTECTED]: On Tuesday 28 Dec 2004 23:16, Arnt Karlsen wrote: On Tue, 28 Dec 2004 21:28:08 +, Dave wrote in message [EMAIL PROTECTED]: If it were to be done, it could be limited to aircraft that it would be compatible with. Say, if the aircraft were in a certain airline livery, you could be sure of the reg position. ..shouldn't the livery define the reg position? If you follow, I mean the livery of one a/c type of one airline. In the case of Airlines, they typically have a production run of one livery per type (sometimes with tail variations) but generally, all of the registrations will be marked in the same location. ..yup. I was thinking more about callsigns; if each AI aircraft is given a callsign, they could then take a registration from a pool (simple list) of correct registrations for their 'type' (ie: SqueezyJet 737) If a registration is taken by an AI traffic, the aircraft is given another from the same list. For airline fanatics, they could even help by providing 'flag-name' details for real-world registrations which would mean that: callsign: Speedbird 6 ..yeah, but airliners usually get their call signs from their routes, such as Finnair won too trrree going from say Tampere, SF to Helsinki (Is it?). Your Speedbird 6 idea should work nicely with one-off charter flights, and could be made a fallback when the plane isn't simming a scheduled flight. Recieves: Reg: G-CIVW and flag-name: City of Lichfield. Of course, this is both extreme and probably pointless when it comes to flag-names but it is the sort of thing that you could apply to textures using Imagemagick if the flag-names were pre-made. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Wednesday 29 December 2004 00:33, Dave Martin wrote:
I was thinking more about callsigns; if each AI aircraft is given a
callsign, they could then take a registration from a pool (simple list) of
correct registrations for their 'type' (ie: SqueezyJet 737) If a
registration is taken by an AI traffic, the aircraft is given another from
the same list.
For those op you interested: Some rudimentary support for this is already in
the traffic manager: Have a look at one of the traffic files in
${FG_ROOT}/data/Traffic for an idea. I'm not using most of these tags yet,
but they're there for future purposes.
For airline fanatics, they could even help by providing 'flag-name' details
for real-world registrations which would mean that:
callsign: Speedbird 6
Recieves: Reg: G-CIVW and flag-name: City of Lichfield.
:-).
The traffic manager actually organizes this the other way around:
aircraft
modelAircraft/MD11/Models/KLMmd11.xml/model
liveryKLM/livery
registrationPH-KCA/registration
heavytrue/heavy
!-- Day one: Amsterdam to San Fransisco, CA, USA --
flight
callsignKLM0605/callsign
fltrulesIFR/fltrules
departure
portEHAM/port
time0/09:45:00/time
/departure
cruise-alt330/cruise-alt
arrival
portKSFO/port
time0/20:55:00/time
/arrival
repeatWEEK/repeat
/flight
/aircraft
Of course, this is both extreme and probably pointless when it comes to
flag-names but it is the sort of thing that you could apply to textures
using Imagemagick if the flag-names were pre-made.
I did keep a flag name as a comment in my xml files.
However, while I hate to spoil the party: This approach would require several
copies of each aircraft type (each with a slightly modified registration
texture) to be loaded. I recently changed the system so that we use multiple
instances of the same copy of each aircraft model, because the original code
that loaded separate copies of each model was taking up way too much
resources. I don't think we want to go back to the original situation, just
to display a registration number on an AI craft, which we wouldn't be able to
read 99% of all times.
Cheers,
Durk
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Idea for AI Traffic / Multiplayer in future
I had a little idea (take cover now!) I had a play about with Imagemagick a while back to see if it could write text onto an RGBA image (which, of course, it can). So I made it write a text string in a freefont typeface onto an aircraft texture - Not that it was in the right place but that is only a question of knowing the right co-ordinates to start at. So... For AI traffic (or multiplay) where any given aircraft has its own callsign, when the texture for that callsign is loaded, Imagemagick can quickly and quietly write the callsign onto the fuselage so the aircraft becomes visually identifyable. That is that every aircraft in the environment would have to have its own texture tho. Still, the idea is there (but I haven't the knowledge to implement it). Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tuesday, 28 December 2004 22:24, Dave Martin wrote: So I made it write a text string in a freefont typeface onto an aircraft texture - Not that it was in the right place but that is only a question of knowing the right co-ordinates to start at. This will work if we know exactly how the aircraft are textured. However if someone decided to make an aircraft that has a registration number that spans across more than one texture we will have a problem. MS have been doing the registration painting in their sims for several years already. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tuesday 28 Dec 2004 20:54, Paul Surgeon wrote: On Tuesday, 28 December 2004 22:24, Dave Martin wrote: So I made it write a text string in a freefont typeface onto an aircraft texture - Not that it was in the right place but that is only a question of knowing the right co-ordinates to start at. This will work if we know exactly how the aircraft are textured. However if someone decided to make an aircraft that has a registration number that spans across more than one texture we will have a problem. If it were to be done, it could be limited to aircraft that it would be compatible with. Say, if the aircraft were in a certain airline livery, you could be sure of the reg position. If someone were to choose to use a non-compatible model for AI traffic, presumable that could just show its default reg. MS have been doing the registration painting in their sims for several years already. Just goes to show how much attention I pay to MS FS ;-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tue, 28 Dec 2004 17:56:24 -0500, Ampere K. Hardraade [EMAIL PROTECTED] wrote: What you want to print on the aircraft is its registration number, not the callsign. Right -- for private aircraft and commercial aircraft not flying for a proper organization, the callsign and registration number are usually identical, but even a private plane can sometimes have a different callsign (like Angel Flight XXX in the US, I think). All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tuesday 28 Dec 2004 22:56, Ampere K. Hardraade wrote: On December 28, 2004 03:24 pm, Dave Martin wrote: For AI traffic (or multiplay) where any given aircraft has its own callsign, when the texture for that callsign is loaded, Imagemagick can quickly and quietly write the callsign onto the fuselage so the aircraft becomes visually identifyable. That is that every aircraft in the environment would have to have its own texture tho. Still, the idea is there (but I haven't the knowledge to implement it). Dave Martin What you want to print on the aircraft is its registration number, not the callsign. This is a good idea. I was planning to add registration number(s) to a model of mine but realized Durk will need the registration to be changable. I have no idea how it will be achieved, so I ended up not adding any. It would undoubtedly look best if the textures were modified 'on the fly' to include the text rather that using polygon text (as in some older sims) but whether it will be doable is another matter. I did actually meant registration rather than callsign; in terms of the aviation I have done personally, our callsign was always our registration ;-) (light GA) Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tue, 28 Dec 2004 21:28:08 +, Dave wrote in message [EMAIL PROTECTED]: If it were to be done, it could be limited to aircraft that it would be compatible with. Say, if the aircraft were in a certain airline livery, you could be sure of the reg position. ..shouldn't the livery define the reg position? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tuesday 28 Dec 2004 23:16, Arnt Karlsen wrote: On Tue, 28 Dec 2004 21:28:08 +, Dave wrote in message [EMAIL PROTECTED]: If it were to be done, it could be limited to aircraft that it would be compatible with. Say, if the aircraft were in a certain airline livery, you could be sure of the reg position. ..shouldn't the livery define the reg position? If you follow, I mean the livery of one a/c type of one airline. In the case of Airlines, they typically have a production run of one livery per type (sometimes with tail variations) but generally, all of the registrations will be marked in the same location. I was thinking more about callsigns; if each AI aircraft is given a callsign, they could then take a registration from a pool (simple list) of correct registrations for their 'type' (ie: SqueezyJet 737) If a registration is taken by an AI traffic, the aircraft is given another from the same list. For airline fanatics, they could even help by providing 'flag-name' details for real-world registrations which would mean that: callsign: Speedbird 6 Recieves: Reg: G-CIVW and flag-name: City of Lichfield. Of course, this is both extreme and probably pointless when it comes to flag-names but it is the sort of thing that you could apply to textures using Imagemagick if the flag-names were pre-made. Dave Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
Dave Martin wrote: On Tuesday 28 Dec 2004 20:54, Paul Surgeon wrote: On Tuesday, 28 December 2004 22:24, Dave Martin wrote: So I made it write a text string in a freefont typeface onto an aircraft texture - Not that it was in the right place but that is only a question of knowing the right co-ordinates to start at. This will work if we know exactly how the aircraft are textured. However if someone decided to make an aircraft that has a registration number that spans across more than one texture we will have a problem. If it were to be done, it could be limited to aircraft that it would be compatible with. Say, if the aircraft were in a certain airline livery, you could be sure of the reg position. Would it not be easier to generate an image containing all the required characters in known positions so that they could be displayed in the correct position - otherwise you're creating a dependency on imagemagick, which is not a small package. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Idea for AI Traffic / Multiplayer in future
On Tuesday 28 Dec 2004 23:38, Jon Stockill wrote: Would it not be easier to generate an image containing all the required characters in known positions so that they could be displayed in the correct position - otherwise you're creating a dependency on imagemagick, which is not a small package. Thats an interesting idea; Perhaps, all the characters could be generated and then used to texture a mesh in the location where the reg. is displayed. (The mesh would be specially placed just to accept reg letters). Is this what you were getting at? Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] =Idea for a an Enhancement Hi ! I would like to have some feedback about an idea for a FlightGear based project that I recently came up with. As the idea is not that easy to describe with one or two
sentences, I was recommended to present the idea on a webpage and ask on the FlightGear mailing list for other opinions - and that's exactly what I am doing now. In short: I am thinking about the possibilites to create an interactive training/lesson addon for FlightGear to illustrate topics such as navigation concepts by using FlightGear as backend. You can find more details at http://flitetutor.sourceforge.net feedback for FlightGear based application concept required Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi ! I would like to have some feedback about an idea for a FlightGear based project that I recently came up with. As the idea is not that easy to describe with one or two sentences, I was recommended to present the idea on a webpage and ask for other opinions on the FlightGear mailing list - and that's exactly what I am doing now. In short: I am thinking about the possibilites to create an interactive training/lesson addon for FlightGear to provide on the one hand interactive help for FlightGear's most essential features but also -even more interesting: to interactively illustrate topics such as navigation concepts by using FlightGear as backend. This project should be based on two parts: a player (to be loaded/running within FlightGear) and also an authoring tool to enable easy creation of the training modules for the player. You can find more details at http://flitetutor.sourceforge.net I am currently mainly looking for answers to some of the following questions: - is there demand for an application like this ? - how many people would actually want to use it (if available) ? - how feasible would it be to implement such an application with FlightGear as backend ? and for the developers among you: - is there anything like a general API in order to interface with FlightGear (either externally or as a plugin) ? - has anybody experience with writing similar extensions for FlightGear ? - is there a way to directly access FlightGear's client area (e.g. via PSL) to display custom animations ? - and of course: would anybody like to join the attempt to turn that concept into something useful ? (it's gonna be a spare time project anyway) For simplicity reasons, and also in order not to disturb the mailing list that much, I did also set up a basic forum on the same webpage - just in case this should be more convenient for some of you (there is no need to register in order to post) Any feedback is appreciated - thanks in advance ! regards Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] =Idea for a an Enhancement
Boris Koenig wrote: I am currently mainly looking for answers to some of the following questions: - is there demand for an application like this ? I think there is. This could particularly be useful for the first couple of lessons for a PC-ATD. It also reminds people that flying isn't easy (which in turn might make it more fun for some of us ...) - how many people would actually want to use it (if available) ? - how feasible would it be to implement such an application with FlightGear as backend ? I think FlightGear (most than any other simulator) is perfectly capable for this stuff. The only problem might be that it requires more work to get it done (if new code needs to be added). But the end result will be precisely what you are aiming for, since everything is open and accessible. and for the developers among you: - is there anything like a general API in order to interface with FlightGear (either externally or as a plugin) ? There are multiple ways to interface with FlightGear. Using scripts (Nasal code) or using a socket connections (by a telnet like interface). - has anybody experience with writing similar extensions for FlightGear ? - is there a way to directly access FlightGear's client area (e.g. via PSL) to display custom animations ? PSL has been superseded by Nasal. Nasal can do a lot already, but animating is best done using XML configuration files (although animations can be triggered by setting/changing animation bound properties). - and of course: would anybody like to join the attempt to turn that concept into something useful ? (it's gonna be a spare time project anyway) If i understand it correctly the I think this doesn't require many C++ code changes. Most of this can be done using XML configuration files and Nasal scripting. For what it's worth, I kind of like the idea. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] idea
ARGH! I wrote this on the third, but never sent it... -- Date: Sun, 03 Nov 2002 21:27:05 -0600 From: Brandon Bergren [EMAIL PROTECTED] User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: [EMAIL PROTECTED] Subject: idea... X-Enigmail-Version: 0.65.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit How about making xml config files for different video cards, similar to the joystick config files. You could set paramaters in the xml file that correspond to the capabilities of the card (near,far clip planes come to mind.) Then, you don't have to look for the mythical magic number that works on all cards. Also, is there a command line switch to override the joystick detection, and tell fg to use the joystick put in the command line? -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
On Fri, 8 Mar 2002 13:42:33 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: John Wojnaroski writes: I also think that I know *too much* about the details of the aero and that pilots who don't have an in-depth understanding of aero engineering can oftentimes give better feedback than those who do. Careful there, are you saying pilots who don't have aero engineering backgrounds can give better feedback than pilots who have aero backgrounds?? Or pilots don't have a in-depth understanding of aero?? The only surviving manuscript of Beowulf was damaged in the Cotton library fire in 1731, and some parts of it are now unreadable or have actually crumbled away. Fortunately, before the fire there were two transcripts made. The first was made by a copyist who did not understand Old English at all and wasn't familiar with the Insular script: he made lots of stupid errors, but he also tended to preserve unusual words and spellings from the original. The second was made by someone familiar with Old English: he didn't make too many stupid, obvious mistakes, but he also tended unconsciously to replace rare words or spellings with more common ones. The same problem exists in any field -- when people know what to expect, they tend to find what they're expecting. ..another classic example of this, is the breakup of WG 236, a De Havilland 110 prototype on Saturday September 6'th 1952 at the Farnborough Airshow, UK. About 110 000 aviators etc watched it snap up in pieces at some 450 mph, debris killed 28, another 60 on the ground at Farnborough, was injured, plus of course the 2 man crew, who failed to eject. .._nobody_ saw what happened to cause the accident. ..a professional photographer filmed it from near the Cove Radio Station, and prepped and handed a wall-load of stills over to the investigators. It was'nt until he was asked to do this to the _entire_ movie, that helped confirm the initial Euler wing skin buckling. Details in Fred Jones Air crash, the clues in the wreckage, isbn 0-86379-094-1, an excellent introduction to analytical air accident investigation. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
This sounds ideal! I vote that you submit it! :-) What are the code dependencies? SimGear? Jon I have a stand-alone real-time and off-line plotting tool written in C/C++ (tested in Cygwin/WinNT/Win2K Linux) that is meant to be used as a flight test engineer's station. It has just been completed and it works, but I am yet to put it to serious use. The code is designed to run a separate PC and recieve data via network from the FDM and the plots are configurable via xml. Offline plots have zoom facility, scales (x/y ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Hi, I have a stand-alone real-time and off-line plotting tool written in C/C++ (tested in Cygwin/WinNT/Win2K Linux) that is meant to be used as a flight test engineer's station. [...] That does sound useful. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
OK. I will do so on Monday (11th March). Do you want me to integrate it into SimGear so that its offline plotting function could be used by people who work with one PC and the stand-alone executable could be used by those who have more than one PC.? Or Should I just send the stand-alone code to Curt?. As a first step I will just integrate it as is, test it with our FDM (for real-time) and our ascii format data file (for off-line) and send it to Curt. Once I recieve suggestions from you I could get it to work with other FDMs of FlightGear. Regards Ranga --- Jon Berndt [EMAIL PROTECTED] wrote: This sounds ideal! I vote that you submit it! :-) What are the code dependencies? SimGear? Jon I have a stand-alone real-time and off-line plotting tool written in C/C++ (tested in Cygwin/WinNT/Win2K Linux) that is meant to be used as a flight test engineer's station. It has just been completed and it works, but I am yet to put it to serious use. The code is designed to run a separate PC and recieve data via network from the FDM and the plots are configurable via xml. Offline plots have zoom facility, scales (x/y ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Fine. I will send it first thing on Monday to Curt alongwith a sample ascii format data file to help you see what it does. We have also put together a short 'instructions for use' and that may be of some help in understanding how it works. Regards Ranga --- Alex Perry [EMAIL PROTECTED] wrote: I suggest that you submit it mostly as-is and have Curt place it into CVS so we can all see how it's implemented ... that way we will have a basis to give you realistic answers to those questions (instead of guessing). OK. I will do so on Monday (11th March). Do you want me to integrate it into SimGear so that its offline plotting function could be used by people who work with one PC and the stand-alone executable could be used by those who have more than one PC.? Or Should I just send the stand-alone code to Curt?. As a first step I will just integrate it as is, test it with our FDM (for real-time) and our ascii format data file (for off-line) and send it to Curt. Once I recieve suggestions from you I could get it to work with other FDMs of FlightGear. Regards Ranga --- Jon Berndt [EMAIL PROTECTED] wrote: This sounds ideal! I vote that you submit it! :-) What are the code dependencies? SimGear? Jon I have a stand-alone real-time and off-line plotting tool written in C/C++ (tested in Cygwin/WinNT/Win2K Linux) that is meant to be used as a flight test engineer's station. It has just been completed and it works, but I am yet to put it to serious use. The code is designed to run a separate PC and recieve data via network from the FDM and the plots are configurable via xml. Offline plots have zoom facility, scales (x/y ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.08 00:43]: I know for the general case an external graphing tool would be most useful (and I think Jon B. has stuff to do this already.) But, I was just thinking today that it might be cool to have a built in grapher for simple / quick graphing needs. With the property system it would be trivial to pick an arbitrary property from the property tree and graph it over time -- superimposed on top of everything else. Things get a bit trickier if you want to control scaling, how much time history get's graphed, multiple values, etc., but even graphing a single value (or maybe just two values) over time could be of some use. I would think that setting this up around our networking scheme would be ideal. We could just export what we want and have an external program graph the data that comes across the socket. Then we wouldn't have to embed a grapher into FG. Anyway, my 2 cents... -- Cameron Moore [ How's my programming? Call 1-800-DEV-NULL ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] idea ... (?)
I wrote a little routine that allows flightgear to read in the csv data from a previous flight (or from a standalone JSBSim flight) and replay it as a flight. I can use the joystick to adjust the speed and I can play it forward or reverse. Would that be useful to anyone else? Mark -Original Message- From: Jon S Berndt [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 9:30 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] idea ... (?) On Fri, 8 Mar 2002 10:00:54 -0600 (CST) Curtis L. Olson [EMAIL PROTECTED] wrote: I know for the general case an external graphing tool would be most useful (and I think Jon B. has stuff to do this already.) Yes, it's a very useful command line tool that plots files of CSV format (comma delimited value format) data, where the first line contains descriptions of the data. It can plot interactively or it can plot a standard set of graphs (producing .png image files) that are linked to via descriptive links from a main html web page. It is very slick. Unfortunately it uses a closed source library - the library is freely available for most platforms, but some people here don't like anything that is not completely open source. So, a nice alternative (in my mind) would be for someone to write a post-processor for the CSV files to plot (either interactively or via .XML input directive file, as I have now for simplot) the data using pgplot, or some other open source plotting program. In the near term, one of the quickie projects I want to do is to write a small routine that will produce color postscript reports as directed by a directives file. I've written several post-processing tools over the years (including one that used SGI GL to render 3D views of the Space Shuttle Orbiter separating from the External Tank in an abort study for NASA). Fun stuff. Anyhow, postscript is nice and simple, and GhostScript has some nice utilities for viewing them. Might be able to also convert them quickly to PDF format with pstopdf. There are lots of possibilities, but for me the important thing is to keep it simple, automated, and quick. Another nice thing to have would be a stripchart data display that could be run on a remote machine. If I only had a few more hours a week ... But, I was just thinking today that it might be cool to have a built in grapher for simple / quick graphing needs. With the property system it would be trivial to pick an arbitrary property from the property tree and graph it over time -- superimposed on top of everything else. I wonder if a remote (or even local) stripchart display program would be better? Things get a bit trickier if you want to control scaling, how much time history get's graphed, multiple values, etc., but even graphing a single value (or maybe just two values) over time could be of some use. You might want to do this via autoscaling, but with initial values suggested in a directives file. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
On Fri, 8 Mar 2002 10:27:16 -0800 John Wojnaroski [EMAIL PROTECTED] wrote: There are pilots who have both solid engineering backgrounds and advanced degrees and experience. Such as test pilots. We could use a few on-staff! :-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Alex Perry writes: Yes, this would be no substitute for data logging and post processing, but if you know what you are looking for, I do think it could be useful. I've been playing with xoscope but it seems to be linux-only and limited. I've been thinking it might be worth porting its user interface to plib, to transparently address all FGFS targets, and give it a property input. Ok, sounds like a good enough excuse to me. :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
There are pilots who have both solid engineering backgrounds and advanced degrees and experience. Yeah, but they're the ones who're selective about interpreting their flying impressions in terms of how they think it is supposed to work. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Dear Friends, Are we getting to a war? Flying experience and skill are grossly acquired..that is why hugecountries are spending great dough on that. Let us keep the distinctions apart,..and the disciplines united. - Misra MD, RealiSim Technologies Retd Fighter Pilot, Qualified Flying Instructor, Experimental Test Pilot, Scientist 'F' Present Managing Director Regards - Original Message - From: Tony Peden [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: 09 March 2002 00:44 Subject: Re: [Flightgear-devel] idea ... (?) --- John Wojnaroski [EMAIL PROTECTED] wrote: Hi, I also think that I know *too much* about the details of the aero and that pilots who don't have an in-depth understanding of aero engineering can oftentimes give better feedback than those who do. Careful there, are you saying pilots who don't have aero engineering backgrounds can give better feedback than pilots who have aero backgrounds?? Or pilots don't have a in-depth understanding of aero?? Yes, that's exactly what I'm saying. There are pilots who have both solid engineering backgrounds and advanced degrees and experience. Yes, indeed. Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Sounds like it'd be useful for debugging aircraft and autopilot configs too. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: Tony Peden writes: In my day job, my own experience has been that real-time plotting is useful when you know exactly what you are looking for and you only need to see a limited number of parameters. The rest of the time, recording the data and plotting after the fact works out to be better. That said, it *would* be a very cool thing to be able to do. Yes, this would be no substitute for data logging and post processing, but if you know what you are looking for, I do think it could be useful. The immediate thing that comes to my mind is this: As a side project I'm working on integrating a 'commercial' fdm with FlightGear via a network interface. One of the things this code supports is control loading. The hardware guys are chomping on the bit wanting to know what range of values the software is going to kick out. Something like a quick and dirty embedded graphing program would be pretty nifty. cout probably works just as well, but it's not as pretty. :-) And once you had the basic graphing mechanism in place, it would be trivial to let the user specify which property(ies) to graph. Maybe we could even hook up the GUI prop-picker to specify which values we want rather than forcing the user to type them all in. FWIW, I think it's important for the FDM guys to frequenty fly their code in real time. In real time with visuals attached, various incorrect effects and behaviors can really jump out at you ... stuff that you'd never notice when looking through tabular data, or even a graph. Sometimes the trend is correct, but the scale or the sign is way off. I would think that being able to fly in real time, and see some key graphical data output would be an immensly useful debugging tool. For instance, nosing over the c310 causes it to go into an infinite acceleration cycle. Hmmm I wonder of that is drag related? Ok, pop up a live graph of thrust, nose over, watch the graph with everything else going on. Nope, drag looks good. I wonder if it's thrust related. Oooo, look at that thrust go off the chart ... ok now let's graph some individual propellor/engine parameters ... etc. etc. That's how my mind works anyway ... :-) Curt. -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Sure, you could use it to graph the value of any flight gear property over time ... not just FDM values. This could be useful for all sorts of stuff ... debugging panel actions, 3d model animations, environment modeling, etc. Curt. Jim Wilson writes: Sounds like it'd be useful for debugging aircraft and autopilot configs too. Best, Jim Curtis L. Olson [EMAIL PROTECTED] said: Tony Peden writes: In my day job, my own experience has been that real-time plotting is useful when you know exactly what you are looking for and you only need to see a limited number of parameters. The rest of the time, recording the data and plotting after the fact works out to be better. That said, it *would* be a very cool thing to be able to do. Yes, this would be no substitute for data logging and post processing, but if you know what you are looking for, I do think it could be useful. The immediate thing that comes to my mind is this: As a side project I'm working on integrating a 'commercial' fdm with FlightGear via a network interface. One of the things this code supports is control loading. The hardware guys are chomping on the bit wanting to know what range of values the software is going to kick out. Something like a quick and dirty embedded graphing program would be pretty nifty. cout probably works just as well, but it's not as pretty. :-) And once you had the basic graphing mechanism in place, it would be trivial to let the user specify which property(ies) to graph. Maybe we could even hook up the GUI prop-picker to specify which values we want rather than forcing the user to type them all in. FWIW, I think it's important for the FDM guys to frequenty fly their code in real time. In real time with visuals attached, various incorrect effects and behaviors can really jump out at you ... stuff that you'd never notice when looking through tabular data, or even a graph. Sometimes the trend is correct, but the scale or the sign is way off. I would think that being able to fly in real time, and see some key graphical data output would be an immensly useful debugging tool. For instance, nosing over the c310 causes it to go into an infinite acceleration cycle. Hmmm I wonder of that is drag related? Ok, pop up a live graph of thrust, nose over, watch the graph with everything else going on. Nope, drag looks good. I wonder if it's thrust related. Oooo, look at that thrust go off the chart ... ok now let's graph some individual propellor/engine parameters ... etc. etc. That's how my mind works anyway ... :-) Curt. -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
