[Flightgear-devel] ATC Chatter live
Hi all, if you like some extra level of reality, tune your browser to http://www.liveatc.net/ where you get live atc from interesting places like KJFK, EHAM, LSZH, VHHH and many others. Enjoy - Torsten - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
On Monday 01 October 2007 22:20, Durk Talsma wrote: I will probably try running a valgrind session sometime this week (yohoo, 1 hour to just get past initialization, and 1 frame every 20 seconds. :-) ). And also try running vmstat FWIW, I did run a short valgrind session. Execution time wasn't nearly as bad as I feared it would be. Couldn't get the seneca engines to start while running under valgrind though. I did a few international teleports, and closed FlightGear after about one hours. Valgrind reported over 800 cases of memory loss. I will probably try and fix some. Probably in random order, driven by whatever seems doable at the time. I just committed a fix for a tiny leak in multiplayer. Nothing significant, in terms of memory leakage, but at least it's one off the list. :-) Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Glass cockpit and external gauges.
Those TC-10's look pretty interesting as free-standing display units. The displays on the Pilatus look like either Garmin G-1000 (with custom options) or Honeywell Primus EPIC displays, the G1000 displays are exactly 10 diagonal. You might have to fiddle a bit with the Line Select Keys along the edges. The enormous variety in current glass flight decks means we really need to think of a new way of defining glass cockpit layouts. Currently, most instrumentation is hard-coded and the binary only provides full displays (like in Project Magenta or OpenGC). You may be able to move the displays around, but not the individual elements (widgets) inside the displays. Why not make either an XML-based or a byte code based layout definition (like ARINC661) which allows more flexibility in the creation of GC displays, as the layout is defined in data, not program code, and can be changed run-time. Especially with modern aircraft this might end up being very useful. Phil Panelli schreef: Hi Bill, Not quite but .. http://store.earthlcd.com/TC-10-TC10?sc=7category=13 compared against http://www.pilatus-aircraft.com/applications/webgallery/webgallery/includes/images/800-600/Pilatus-PC-12-NG-26.jpg Let's say I have a few tc-10's left over from another project that is dead I really like that pilatus layout but I also like to fly other aircraft. There just seems to be an uncanny similarity between the look of the real thing and those units. If you consider the fact that some of the simulated steam gauges can be a much as half as one of these units. The dual scan is not so great but a little contrast adjustment, lights out , a few 22 lcd panels for the out the window view. It's got some possibilities... and Earth lcd had about 90,000 of them in inventory last time I checked. I would not wish to limit the development to just those units. I would put some time into this This time I think it should be a flightgear sub project . I'm just having a hard time getting my hands around the state of things Sorry for the rambling . Just thinking out loud . Phil - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [ANN] new Nasal function: airportinfo()
Today I added a function for retrieval of airport/runway information.
Usage:
var apt = airportinfo(KHAF); # get info about KHAF
var apt = airportinfo(lat, lon); # get info about apt closest to lat/lon
var apt = airportinfo(); # get info about apt closest to aircraft
The command debug.dump(airportinfo(KHAF)) outputs this:
{ lon : -122.4962626410256, lat : 37.51343502564102, has_metar : 0,
runways : { 12 : { stopway2 : 0, threshold1 : 232.5624,
lon : -122.501088999, lat : 37.513831, stopway1 : 0, width : 45.72,
threshold2 : 232.5624, heading : 138.11999, length : 1523.0856 } },
elevation : 20.421599, id : KHAF, name : Half Moon Bay }
That is: a hash with elements lat/lon/elev/id/name/has_metar for the
airport, and a hash with runways, each of which consists of lat/lon/
/length/width/heading/threshold[12]/stopway[12]. Only one side of each
runway is listed -- the other can easily be deduced.
Unfortunately, the C++ search functions don't differ yet between
airport and heliport, so you might not get the closest airport
that you expect. :-)
There are some runway values missing, such as lighting info, but
that's easy to add once we need it. Thanks to the hash structure
we don't have to fear compatibility problems.
The function should, of course, be used sparingly, but it's fast
enough to not cause stutter. ;-)
m.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Hi, It is in in OSG too - my first report was for OSG! Greetings HHS --- Olaf Flebbe [EMAIL PROTECTED] schrieb: Hi Durk, There are a few interesting observations to make in this respect. I do believe there is a memory leak in FlightGear. Probably a major one in the scenery tile loader. As reported previously, I routinely let FlightGear run for a few I did some investigations in the past about memory consumption and found some small holes, where fixes may be only commited into the OSG branch. The tile data are never released if I remember correctly. I discussed releasing these data structures with Mathias but he warned me about having subtile negative side effects... I don't remember the details. Let me ask a stupid question: Is the stuttering a plib-only effect for you? What about stuttering in OSG? Cheers Olaf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Machen Sie Yahoo! zu Ihrer Startseite. Los geht's: http://de.yahoo.com/set - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] tunnel for glide slope visualization
Here's a first stab at a glide slope tunnel visualization utility. It's a rather short Nasal script which uses the new airportinfo() function. It requires a *very* up-to-date FlightGear. To try it out just put it into ~/.fgfs/Nasal/ or $FG_ROOT/Nasal/. http://members.aon.at/mfranz/gstunnel.nas [2.4 kB] The script checks in 5 second intervals for the nearest airport, selects a decent runway and draws a glide slope tunnel for it consisting of red squares. There's much that can be improved. One could draw only the next three or four squares instead of the whole tunnel, remove the upper line (for better runway view), consider wind direction etc. Also, one might prefer to be able to select a particular airport, and have the tunnel drawn on the runway told by ATC, or one might want a circuit tunnel for tutorials, etc. All doable. :-) There are also problems: - as the airportinfo() function also returns heliports as nearest airports, the glide slope is often drawn much too late. It's therefore better to fly in not so crowded areas. (This needs to be fixed in simple.cxx.) - the tunnel isn't aligned at a few runways. This could be a bug in terragear, which could also be responsible for wrong ILS behavior (see, for example, KOAK/9R). m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tunnel for glide slope visualization
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Melchior FRANZ Sent: Tuesday, October 02, 2007 4:24 PM To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] tunnel for glide slope visualization Here's a first stab at a glide slope tunnel visualization utility. It's a rather short Nasal script which uses the new airportinfo() function. It requires a *very* up-to-date FlightGear. To try it out just put it into ~/.fgfs/Nasal/ or $FG_ROOT/Nasal/. http://members.aon.at/mfranz/gstunnel.nas [2.4 kB] The script checks in 5 second intervals for the nearest airport, selects a decent runway and draws a glide slope tunnel for it consisting of red squares. There's much that can be improved. One could draw only the next three or four squares instead of the whole tunnel, remove the upper line (for better runway view), consider wind direction etc. Also, one might prefer to be able to select a particular airport, and have the tunnel drawn on the runway told by ATC, or one might want a circuit tunnel for tutorials, etc. All doable. :-) There are also problems: - as the airportinfo() function also returns heliports as nearest airports, the glide slope is often drawn much too late. It's therefore better to fly in not so crowded areas. (This needs to be fixed in simple.cxx.) - the tunnel isn't aligned at a few runways. This could be a bug in terragear, which could also be responsible for wrong ILS behavior (see, for example, KOAK/9R). m. This sounds interesting. Can you send a screen shot or two? Bill - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tunnel for glide slope visualization
* Bill Galbraith -- Tuesday 02 October 2007: Can you send a screen shot or two? http://members.aon.at/mfranz/gstunnel.png [159.7 kB] Needed to use png, as jpg made the lines look really ugly. :-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tunnel for glide slope visualization
* Melchior FRANZ -- Tuesday 02 October 2007: http://members.aon.at/mfranz/gstunnel.png [159.7 kB] Made a better smaller one: [45 kB] The whole thing is quite simple and flexible. Most of what's needed is already there in one of the Nasal library scripts in $FG_ROOT/Nasal/ and available as built-in Nasal functions. The rest is just combining them and placing square (or other models) in the landscape. The power of fgfs Nasal. :-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tunnel for glide slope visualization
Bill Galbraith wrote: Okay, that looks really good. Now, let's make it more challenging. Let's see circles to get me back to the squares in a reasonable amount of time ;-} Bill Does the line geometry run through OSG? Might be a very good starting point of converting the HUD to an OSG-driven one. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Composite scenery models
I've been experimenting with adding the fire models to other scenery objects - like the flare stack: http://flightgear.stockill.org.uk/testing/flare.jpg The results are quite nice, but there does seem to be an issue with sub models and scenery objects. Using this to create the model: ?xml version=1.0? PropertyList pathgeneric_flare_01.ac/path animation typerange/type min-m0/min-m max-m25000/max-m /animation model pathfire.osg/path offsets x-m0/x-m y-m0/y-m z-m200/z-m /offsets /model /PropertyList with fire.osg in the same directory as generic_flare_01.ac results in a not found error for ./fire.osg specifying pathModels/fgfsdb/fire.osg/path still gives a not found error, but for ./Models/fgfsdb/fire.osg - the path is always relative to the current working directory rather than relative to the model, or relative to the data path. Either copying the file to the directory you're starting the sim from, or changing to the model directory before starting solves the problem, so the loaders all work, there's just a problem with the search path. Now I just need to learn more about the osg file format for particle systems, smoke and steam for chimneys and cooling towers aren't too far away. I'm using an nVidia 6500, and the impact on frame rate seems to be minimal. There are z buffer issues when fire is displayed in front of a cloud layer though - that could just need the particles adding to the correct part of the scene graph though. Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tunnel for glide slope visualization
On 10/2/07, Bill Galbraith [EMAIL PROTECTED] wrote: Okay, that looks really good. Now, let's make it more challenging. Let's see circles to get me back to the squares in a reasonable amount of time ;-} ... factoring in your aircraft performance parameters and weather conditions of course ... so you get an achievable path in an engine out situation. Curt. -- Curtis Olson - University of Minnesota - FlightGear Project http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/ http://www.flightgear.org Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tunnel for glide slope visualization
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Melchior FRANZ Sent: Tuesday, October 02, 2007 4:57 PM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] tunnel for glide slope visualization * Bill Galbraith -- Tuesday 02 October 2007: Can you send a screen shot or two? http://members.aon.at/mfranz/gstunnel.png [159.7 kB] Needed to use png, as jpg made the lines look really ugly. :-) m. Okay, that looks really good. Now, let's make it more challenging. Let's see circles to get me back to the squares in a reasonable amount of time ;-} Bill - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer liveries...
Hello all , Im putting forward the idea of transmitting a /sim/model/texture string property with the name of a texture for individual MP aircraft , with the idea that each MP aircraft can show its own livery without the need for multiple -set files, or a separate texture-path folder for each different livery One possible problem , if I understand correctly , might be the bandwidth limit ... I,ve tested the sim/model/variant INT with Melchior a bit , and no problems there except it seems /sim/model/variant must be initialized in the set file as type=int before it will transmit... Is there any interest in adding this funcionality from anyone else , besides myself? Cheers -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
