Re: [Flightgear-devel] fgadmin missing files (was: Re: Aircraft Download/Install App)
On Saturday 26 November 2005 16:20, Melchior FRANZ wrote: * AJ MacLeod -- Saturday 26 November 2005 15:50: This hypothetical application sounds very much to me like an extension to the existing fgrun... ... and we could call it ... *pause* ... fgadmin! Speaking of which: Inspired by your message, I tried building fgadmin from within utils/fgadmin: utils/fgadmin ./autogen.sh Host info: Linux i686 automake: 1.9.5 (19) Running aclocal /usr/share/aclocal/smpeg.m4:13: warning: underquoted definition of AM_PATH_SMPEG run info '(automake)Extending aclocal' or see http://sources.redhat.com/automake/automake.html#Extending-aclocal /usr/share/aclocal/pstoedit.m4:7: warning: underquoted definition of AM_PATH_PSTOEDIT Running autoheader Running automake --add-missing Makefile.am: required file `./NEWS' not found Makefile.am: required file `./README' not found Makefile.am: required file `./AUTHORS' not found Makefile.am: required file `./ChangeLog' not found Running autoconf After creating these missing files everything build just fine. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] thesis?
On Wednesday 23 November 2005 05:16, Szabolcs Berecz wrote: Sounds more interesting :) I suppose ATC is functional in FlighGear. The ATC in FlightGear is an area that is currently still under active development. Feel free to browse through the source code subdirectories that make up the most significant bits and pieces (src/ATC src/AIModel src/Traffic, and to some degree src/Airports (look for the files simple.cxx and simple.hxx). If you feel like working in this area, you're more than welcome, but please send us a brief outline of your ideas so we can check how well it fits with our ongoing plans. One potential code improvement that might really come in handy in future AI traffic is is a set of algorithms that run across multiple frames. Right now, there is still a limited set of potentially CPU/IO intensive more or less AI related functions that run within one frame, and might disrupt the flow of the simulator. Two examples that come to mind are: 1) The FGGroundNetwork::trace() algorithm (see Airports/simple.cxx) 2) The SimGear model loaders. Having versions of these functions that distribute the calculations across multiple frames might be very handy in the long run. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
On Tuesday 22 November 2005 18:02, Curtis L. Olson wrote: Vassilii Khachaturov wrote: Like in the dawn screenshot where I tried to show that off; http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg [snip] I forget who posted this original 'dark' screen shot, but here's the issue, due to gamma differences, this image comes out completely black on my screen. From that standpoint, it's not a useful screen shot. Many people that download it are going to say, huh! This isn't an easy problem to circumvent because there is a wide swath of gamma configurations and monitors out there. But in this case, we simply need something with more light to make it widely useable. My old crt screen on my linux box had a pretty bad gamma curve, but it went down with a bang the day before yesterday. I just got back online with a brand new 19 TFT screen and now this screenshot looks really good. FWIW, isn't it possible to run the image through one of the ImageMagick tools to improve the gamma curves. Obviously, I'm biased because I like screenshots featuring the moon :-) Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 0.9.9 repost
Hey Guys, I just got back from Canada yesterday, so I didn't have the time to respond any sooner. On Saturday 12 November 2005 03:52, Curtis L. Olson wrote: Dave Culp wrote: Due to underwhelming response to my previous post concerning a test run of 0.9.9-pre2, I'll repost now. Here is the console output while running the F-16: Dent: .Dent: ..Dent: EHAMopening The offending code prereads directories in data/Airports/AI. I've seen this message for ages, and forgot about it, predominantly because that piece of code wasn't written by me. In addition, I'd gotten so used to seeing it, but I now realize it musn't have shown up in CVS versions, because until recently we didn't have any entries in Airports/AI I can get rid of the Dent ... debugging output in Airport/simple.cxx which someone has changed into a big convoluted monster with all kinds of extraneous crap ... not happy about that ... no time to dig through and fix though ... :-( Well, while I'm not exactly thrilled by the formulation used here (as this was all done by me), I agree that we need to move the stuff added here into a better organized airport structure, presumably a kind of higher order airport class, covering the AI part of each airport. I have some ideas how this could be done, and tentatively scheduled this for the end of the year to look into. The one thing I'm still struggling with is how these AI bits can be loaded and unloaded as the situation demands. Finally, do add some words in defense to my own decision: When I started out adding AI stuff for airport ground handling, we didn't have anything but FGAirport, so it did seem a very logical point to start... Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Tuesday 08 November 2005 16:27, Harald JOHNSEN wrote: It's a quick hack, I try to find plausible surface/gear position depending on the ai aircraft attitude. From the aircraft_demo ai, you can see the 733 gears animation just after take-off : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-130.jpg From a scenario posted on the user list not long ago, a cessna taking off (ailerons and one flaps) : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-135.jpg and a bit later on final with 3 flaps : http://sites.estvideo.net/tipunch/flightgear/images/fgfs-screen-134.jpg Looks cool. There is some rudimentary support for this type of animation in the AI scenario files, but I don't think it is fully implemented yet. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS make error (Cygwin)
On Monday 07 November 2005 16:28, George Patterson wrote: On Mon, 2005-11-07 at 15:02 +, Kevin Jones wrote: Hi, CVS FG source at 2:30pm (UK time) Monday 7th November fails to make on Cygwin with the following error: make[2]: Entering directory blah/source/src/MultiPlayer make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. Can anyone help? Kevin. Kevin, You need to do a make clean and re-./configure before building... The file tiny_xdr.cpp has been renamed tiny_xdr.cxx. You can also just delete the .deps directory under src/MultiPlayer and rerun ./configure ; make. Saves you the long rebuild time. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Passing values through the property tree
On Monday 07 November 2005 00:22, Vassilii Khachaturov wrote:
What I've tried to do is the following (AIModels/AIBase.cxx: about line
166)
Why don't you send us the cvs diff -u of that file?
Sending the file by itself isn't much use. My question isn't really related to
the syntax in this particular piece of code, but more related to the
overarching property tree design. In the mean time, I did find out that the
texture-path property does get set in the tree, but that the model loading
mechanism isn't picking it up, due to the organization of the AI model I'm
trying to load.
model = manager-getModel(path, tpath);
if (!(model))
{
if (tpath != )
I sincerely hope that this comparison works as expected. If e.g. tpath is
a char* it surely is not doing what you mean :))
Yes, this is verified and correct. I'm tpath is a C++ string object.
Cheers,
Durk
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Monday 07 November 2005 14:20, Josh Babcock wrote:
Durk Talsma wrote:
On Friday 04 November 2005 23:40, Christian Mayer wrote:
Durk Talsma schrieb:
To get AI traffic going in the forseeable future, we could use quite
a few low-polygon count aircraft models in various paint schemes. So,
Wouldn't it be better to add those models to the existing (and yet to
come) high-poly models as a different LOD?
Would be possible, but aircraft loading and unloading time is going to be
an issue.
Good point, but I still like Christian's idea. Maybe we should settle on
a standard name for low poly models. I already like to include lots of
LOD in my models, and it is no problem to simply pull out the low poly
versions and save them under a different xml file. If we could come up
with a standard that included the following, it wouldn't be that hard to
follow through:
I've been playing a lot with the organization of some FS98 MDL files I
downloaded over the weekend, and came to the conclusion that this might
indeed be a good idea. One thing I thinking about aiming for is to create an
{aircraft}-set.xml like file for the AI aircraft, that acts as both a wapper
for the animations, models, textures, and also contains the traffic pattern
associated with these aircraft. More specifically, what I'm thinking of is
one xml file, that associates a model with a particular texture directory
(a.k.a. paint scheme, a.k.a. skin, a.k.a. livery :-), which also contains the
routing table for all aircraft of this type/livery.
I'm trying to work out this idea a bit further and then we can see how it
combines with the animations code. The most important animation is probably
gear up/down, because that's quite visible. Flap extension/retration would
probaly also be quite visible.
Cheers,
Durk
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Out of Town next week
Hey Guys, With signs of a new release coming up, and a few interesting discussions I'm involved in, I thought I'd drop a note to let you know that I'm going to be out of town next week. Tomorrow, I'm flying out to Canada (Toronto and Kingstone) for a work related meeting followed by a conference. I'm back by next tuesday. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Monday 07 November 2005 18:53, Harald JOHNSEN wrote: Durk Talsma wrote: I'm trying to work out this idea a bit further and then we can see how it combines with the animations code. The most important animation is probably gear up/down, because that's quite visible. Flap extension/retration would probaly also be quite visible. Cheers, Durk I was about to commit a few lines of code for those animations (AIAircraft class only). Hi Harald, Sounds interesting. Could you give us clue what your code does? Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Passing values through the property tree
Hey Guys,
I have a question: I've been working on adding multiple livery support for AI
traffic. What I would like to do is pass the texture directory by means of a
property to sgLoad3DModel().
What I've tried to do is the following (AIModels/AIBase.cxx: about line 166)
model = manager-getModel(path, tpath);
if (!(model))
{
if (tpath != )
{
string texPath = Texture/ + tpath;
prop_root-setStringValue(texture-path, texPath.c_str());
}
model = sgLoad3DModel(fg_root,
path,
prop_root,
sim_time_sec);
manager-setModel(path, tpath, model);
}
what I'm trying to do is set a string value and pass that to the sgLoad3DModel
functions. I've been staring at it almost all day, and no matter what I'm
trying, it just doesn't work. Any idea how I can do this?
Cheers,
Durk
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Friday 04 November 2005 23:40, Christian Mayer wrote: Durk Talsma schrieb: To get AI traffic going in the forseeable future, we could use quite a few low-polygon count aircraft models in various paint schemes. So, I'd be interested to know if anybody with reasonable 3d modeling skills would be interested in contributing in this field. Although the traffic system shouldn't be limited to commercial airliners, this is probably the area I'd be working on mostly initially. So, for starters, I would like to explore some models of the more popular airliners series, i,e., the Boeing 7[0-8]7, Airbus A3[0-8]0, and any [McDonnel] Douglas aircraft (and Fokkers of course :-)). Wouldn't it be better to add those models to the existing (and yet to come) high-poly models as a different LOD? Would be possible, but aircraft loading and unloading time is going to be an issue. Unless we can move the aircraft loader into a separate thread, or come up with a very sophisticated multiframe aircraft loader, I would prefer to start with using something that is simple from the start. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Saturday 05 November 2005 00:26, Innis Cunningham wrote: Hi Durk From: Durk Talsmawrites interested to know if anybody with reasonable 3d modeling skills would be interested in contributing in this field. Although the traffic system shouldn't be limited to commercial airliners, this is probably the area I'd be working on mostly initially. So, for starters, I would like to explore some models of the more popular airliners series, i,e., the Boeing 7[0-8]7, Airbus A3[0-8]0, and any [McDonnel] Douglas aircraft (and Fokkers of course :-)). I'd build them myself If I had shown any signs of talent in the field of 3D modeling :-(. Camil Valiquette has given permission for his aircraft to be used in FG.I would think any of his FS98 aircraft might be usefull. That's interesting. I started browsing www.flightsim.com this morning and came up with a fairly complete set of Boeings (727 through 777), and airbuses (A300, A330, A340, and A380) made by Camil Valiquette. Tomorrow, I'll try and see if I can get those to load into TrafficGear. Thanks, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Saturday 05 November 2005 01:42, Paul Surgeon wrote: It's a pity we can't use something like the Project AI aircraft packages. It's a lot of work modeling dozens of aircraft types and liveries. I agree. I've been trying to contact the folks at project AI at least five times to see if we could set up some kind of collaboration, and every time I'm getting an error saying that the contact address doesn't exist. That's a pity, because I'm a great fan of their traffic packages and AI aircraft for MSFS. Speaking strictly personal, I'm not so enthousiastic about their organizational structure and legalities though. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
On Sunday 06 November 2005 02:46, Curtis L. Olson wrote: I was scanning through the cvs logs trying to refresh my memory on what has been changed, added, and fixed since the release of v0.9.8 (last January). Here's what I came up with, although after staring at cvs logs for 2 hours I started having minor hallucinations. So I'm posting this here in hopes that people can add to it, or correct my mistakes. If you contributed something that is missing, or poorly described here, please send me something better. That's an impressive list of changes. I'm missing Dynamic taxiway following at airports equipped with a logical ground network from the list though :-) Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Major slowdown since yesterday
On Wednesday 02 November 2005 14:19, Martin Spott wrote: Martin Spott wrote: I experience a significant slowdown in the frame rate since my last build yesterday. As the only significant change in CVS is the AI traffic on EHAM I assume the slowdown is related to that. I'm very sorry for that confusion. The simple reason was that I accidentially enabled shadows for this setup and I didn't notice, Martin. Hi Martin, Thanks for clarifying. :-) Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Major slowdown since yesterday
On Wednesday 19 October 2005 14:54, Martin Spott wrote: Hello, I experience a significant slowdown in the frame rate since my last build yesterday. As the only significant change in CVS is the AI traffic on EHAM I assume the slowdown is related to that. Do I have the ability to disable this feature by command line ? I already apply --prop:/sim/ai-traffic/enabled=false and --disable-ai-models but this does not appear to affect the recent changes. Not that I dislike the new feature, it's quite an interesting add-on. It's just that the PeeCee I run test on is incapable to keep up with the work load. Hi Martin, Have you checked whether in preferences.xml you have the following traffic-manager enabled type=booltrue/enabled /traffic-manager ai enabled type=booltrue/enabled !-- scenarionimitz_demo/scenario -- !-- scenarioaircraft_demo/scenario -- /ai if so, you should set traffic-manager/enabled to false. Next, you could also check using the property browser if any aircraft are listed in /ai/models. However, I do have to add that, while I cannot rule out a performance decrease from the new traffic features, I would consider it unlikely, for a number of reasons, that this is what's troubling you. First, and formost, the new taxiway follow code only works at EHAM, but there is no traffic yet for this airport (unless the KLM schedules are uncommented data/Traffic/fgtraffic.xml, (you might want to check). Secondly, even when you are flying within a relatively small distance of EHAM, currently set at 150 km. Thirdly, the traffic manager is still disabled by default, so the new code shouldn't run, unless you specifically activate it. Fourth and final, the new code doesn't run on a frame to frame basis, but mainly only when a new taxiroute is requested. So while I can imagine that this would result in an occasional pause on slower machines, it should not result in a continuous performance decrease. Unless all three conditions above are satisfied, the new code doesn't run. It does seem that there was another update yesterday, related to a fix in ssg. (See the email conversation between Matthias Frolich and Melchior Franz, yesterday evening). While I have not tested this, it might be possible that this is causing some slowdown, because this patch seems to run on a frame to frame basis. Please let me know if the traffic-manager is enabled, and then I hope I can give you some more assistance in getting your system up to speed again. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
On Monday 17 October 2005 06:50, Ampere K. Hardraade wrote: Regarding Robin's DB: having accurate taxiways is not the only concern. Some other items that we should take notice of include: These are valid concerns. Quite a few of these features are already available, albeit sometimes in a rough outline, or at the proof-of-principle stage. - buildings placement This can be done through a combination of .stg and xml files, but this has to be done either by hand editing, or by using a dedicated scenery editor. I'm not sure if fgsd would be able to do this. This would be the only interactive application that would allow this. See KSFO for an example. I haven't tried doing this myself, so I can't comment on whether it's easy to do or not. - gates' position Current versions of taxidraw already support startup locations. Over the summer I have written a rather crude extension to taxidraw that allows me to add more sophistication to the gates (such the types of aircraft that can park there, which airlines are allowed, whether its a gate or a parking, airline, general aviation, military, or cargo, etc, etc, etc. The editing capabilities are still not finished, but I'll try and transpose my prototype code over to taxidraw CVS in the next few weeks. So, hopefully this will become available soon. - tower/ILS frequencies -Tower frequencies are saved in the standard x-plane/taxidraw format, IIRC. We do have support for ILS too, but the data are stored in a different files. - runway/taxiway signs These are currently indeed unsupported. It would be a nice feature, but personally I wouldn't prioritize this too much though. - airport animations Just wondering what type of animations you were thinking of. We have support for moving aircraft now, but no ground vehicles yet, although this could be done using animation scripts. - runway/taxiway conditions due to weather I have implemented preferential runway use last spring. The code is controlled by one xml file per airport, and has the capability to assign different runways for landing and take-off, depending on wind, time-of-day, noise regulations, and traffic type (i.e. on some airports, general aviation will use other runways than commercial traffic, which in turn will use other runways than military aircraft). The code has been mimicking Schiphol (EHAM)'s runway use fairly well, although I still need to iron out a few rough edges. I have not yet done any work on taxiway conditions, but this needs to be done most certainly, because some two-way taxiways should only be used in one direction at the time. I have some rough ideas on how to handle that, but no chance yet to work on this. Hopefully these features will become available in FlightGear some time next year. - ground pathways for AI traffics Yes. As I mentioned above, I have made some extensions to taxidraw that will allow this, and I'm in the process of moving these over to CVS. To me, this is what has currently my highest priority. Time might as well be spent on thinking of how we are going to convince Robin to use our new format instead of thinking of a way to expand Robin's database. David Luff, Ralf Gerlich, and I have been discussing some of these issues off-list. Like Curt mentioned Robin Peel is a dedicated database manager, and I have the highest appreciation for his work. The database he maintains is mainly aimed at supporting x-plane, and I believe we have a strong win-win situation by being able to use his database. The problem is that at this point the requirement for FlightGear and x-plane start to deviate and I don't think we can expect an x-plane datamanager expect to switch to use a more sophisticated database format, just to support that *other* flight sim that happens to be using his database too. It's a difficult situation... Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Some new AI traffic screen shots
Hi Folks, A few days ago I promised to put some AI traffic screenshot on my website. The site's up and running again, so here they are. http://durktalsma.xs4all.nl/FlightGear/web/index.html The new screenshots start here: http://durktalsma.xs4all.nl/FlightGear/web/19.html I still need to tighten up the explanatory text some more, but I hope that these screenshots will give some insights into the new features that will hopefully be in CVS soon. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Some new AI traffic screen shots
On Wednesday 12 October 2005 19:47, Ralf Gerlich wrote: Hi, Durk Talsma schrieb: Hi Folks, A few days ago I promised to put some AI traffic screenshot on my website. The site's up and running again, so here they are. This looks absolutely great. When do you think we will be able to see first versions of this in the CVS or via a patch? I'm planning on wrapping up the code this weekend or so. I made some more changes over last weekend, and had FlightGear test running a full three-and-a-half day marathon session. All I need to do is sync my development copy with CVS, and then I'm planning to send it to Erik. Because I created the parking and ground network file for EHAM myself, I'm also planning on submitting that together with the code. Depending on Erik's schedule and/or unforseen coding/portability issues, it might be up to a few additional days after sending it in before everything is in CVS. Notice though that I won't be able to release the file containing the traffic patterns I used for testing. I created those by converting a set of traffic files made by project ai (http://www.projectai.com) for MSFS, and which are released under a 'freeware' licence that is incompatible with GPL. I'm considering writing an interactive tool to generate traffic files, but I haven't really decided yet what my next step will be. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Does FlightGear model eclipse?
On Monday 03 October 2005 11:25, Erik Hofman wrote: Steve Hosgood wrote: On Mon, 2005-10-03 at 09:01, Erik Hofman wrote: Speaking of which, is anybody still working on replacing the non-GPL sun/moon azimuth calculations to properly model the color of them? I've done some of it. Not sure about the 'color' bit, I'm just working No worries, the color will follow once the azimuth is set correct. Are you referring to the sun/moon's color here? on taking out the xearth astronomy routines (which are largely inappropriate anyway) and replacing with straight boring math from the likes of Peter Duffett-Smith's book. I've just been overworked for the last month and haven't made any recent headway, that's all. Ok, no problem. I just wanted to know the status. Thanks. Sounds good. I understood that Steve was looking into that and that's when I decided not to look into it any further. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: FlightGear 0.9.9
On Monday 03 October 2005 13:35, Melchior FRANZ wrote: (A) will a new official plib release be required? Personally, I don't have an opinion on this one. (B) which bugs need to be fixed (and by whom :-)? Okay, here are some off the top of my head that I found recently: - Setting a wrong path for --fg-scenery results in an abort - Trying to load unexisting AI aircraft (using the AIManager/TrafficManager) and/or other suspicious setup problems lead to an error in the tile loader[*] - There seems to be a problem with the --time-offset= option that I could probably fix. (C) which features need to be completed? I had a breakthrough yesterday in adding taxiway following for AI traffic, so obviously, I'd like to see that getting into the release. I'll put some new screenshots on my website once I get my server running again. In addition, I would also like to ask how people would think about enabling ai and traffic-manager by default? Maybe not yet in the release version, but at least in CVS, so it gets some more developer exposure? (D) which a/c should be included? The 737, because it is used by the Traffic Manager. (E) for when could/should the release be planned (i.e. how much time is left to fix bugs etc.)? I'd say early to mid December? That is about 2 to 2.5 months from now? That would allow one month of feature adding and another month for a feature freeze. But again, this is probably up to Curt to decide. Cheers, Durk [*] Note: I'm deliberately vague here, because I just discovered this during a system wide upgrade. To time yet to figure out exactly what's happening ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
On Monday 03 October 2005 19:57, Melchior FRANZ wrote: * Melchior FRANZ -- Monday 03 October 2005 19:47: * Durk Talsma -- Monday 03 October 2005 18:08: (B) which bugs need to be fixed (and by whom :-)? - Setting a wrong path for --fg-scenery results in an abort I'll look into this. It behaves exactly as it is supposed to: If no paths are given, the default is used. If paths are given, fgfs uses all that do actually contain scenery. (It doesn't complain about paths that don't!) But if a user specifies one or more paths but *none* contains valid scenery, it aborts with this error message: Fatal error: No valid scenery path defined! Hmm, I think there's more to it than meets the eye: I had FlightGear die right after I had upgraded my Linux box, but before I discovered I had not yet moved the scenery tree over from my backup drive. I have specified: --fg-scenery=/home/durk/FlightGear-Scenery-0.9.7/ When this path exists everything works fine, but if I move FlightGear scenery to some other path, I get Could not find VVNS Could not find VVNT Aborted [EMAIL PROTECTED]:~/src/FlightGear-0.9/source-devel (With the two Could not find Messages coming from the Traffic manager) Problem is not that FlightGear refuses to run without scenery( which makes sense), but that the error message I'm seeing in this case isn't particularly insightful. I think the problem here is not that FlightGear scans directories that don't contain scenery, but that FlightGear is trying to open a directory that doesn't exist. HTH, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: FlightGear 0.9.9
On Monday 03 October 2005 20:31, Melchior FRANZ wrote: * Durk Talsma -- Monday 03 October 2005 20:18: Could not find VVNS Could not find VVNT Aborted [EMAIL PROTECTED]:~/src/FlightGear-0.9/source-devel You have compiled with glut? And not used the -fexceptions flag? That's possible. I'm using freeglut, but didn't compile this one myself. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Does FlightGear model eclipse?
On Monday 03 October 2005 06:37, George Patterson wrote: On Sun, 2005-10-02 at 19:49 -0400, Ampere K. Hardraade wrote: There will be an eclipse tomorrow, and I was just wonder whether FlightGear has this modelled. http://news.bbc.co.uk/2/hi/science/nature/4299074.stm Ampere It should do as FlightGear models the path of both the sun and the moon across the sky. But as for the darkening of the sky and the like, I'm not sure. That's indeed about it. Sun and moon come pretty close together in the sky. Years back, we discussed once whether it would be possible to actually model the darkening/occlusion effects, but in the end decided it was just too much work and too far off topic to really pursue. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.3.2 released
On Tuesday 16 August 2005 14:49, David Luff wrote: TaxiDraw-0.3.2 has been released. This release is primarily to track changes in the X-Plane data format. TaxiDraw has also moved to SourceForge, and can now be found at http://taxidraw.sf.net. As a result, the latest code can now be obtained from CVS, hopefully making it easier for others to collaborate in further development. It also has an autotools-type configure/make system now instead of the buggy, hand-written makefile, so those compiling from source will need to use ./configure; make (or ./autogen.sh; ./configure; make if using CVS). That's really great news! I just started working again on the AI ground network code, and was wondering what the status was with respect to the move to sourceforge/CVS. I started working version 0.3.0 and was wondering how we should go about merging this with the current release. With cvs, I guess it's going to be fairly easy to incrementally add my changes to the repository. FWIW, we probably need to think a bit about the changes to the fileformat required to support the AI networking code. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sun Azimuth [Was: licensing problems in SUSE Linux]
On Sunday 07 August 2005 15:54, Erik Hofman wrote: Erik Hofman wrote: Is this correct or am I missing something? I just realized that you also need to adjust for day-of-year to compensate for the out-of-center rotation that causes long days (and nights) for both polar areas. Erik Hi Erik, Just looking through your mails quickly, it looks like you also need to compensate for the fact the the earth's rotation axis is tilted by about 23 degrees, relative to it's orbital path around the sun. The latter causes daylight periods to grow and shorten with the seasons, increasingly so when you get further north or south. In reality, it is even more complex, because the earth's orbit around the sun is not a perfect sphere, but an ellipse. This causes some parts of the orbit (i.e. the northern hemisphere winter) to be completed faster then others. The main effect of this is that the position of the sun relative to a 24-hour clock, can shift considerably throughout the day. Cheers, Durk P.S., I'm sorry I didn't have a chance to further look into the sunpos/moonpos files. Things have been extremely hectic at work, but the good side of that is that I've gotten a new Job offer from a neighbouring department, which I accepted. :-) D. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tuesday 26 July 2005 11:30, Steve Hosgood wrote: So we're just down to the problem that the sun position code is possibly not GPL-able. I've dug out my own code that I'm quite happy to donate. Only part of 'src/Time/sunpos.cxx' seems to be derived from Kirk Johnson's 'xearth' anyway, and even he attributes it all to the legendary Practical Astronomy with your Pocket Calculator book by Peter Duffett-Smith. I think the interface routines to FlightGear (all starting with 'fg') are not Johnson's anyway, but I'm not totally sure. Durk Talsma may know better - his name is on some of the comments in those 'fg' routines. Just looking through the sunpos.cxx file, I'm actually wondering how much code is part of the original Kirk Johnson code and how much was changed to adapt the code to our needs. I really think I would have to look at the original file to find out. As far as I remember though, the functions starting with the fg prefix were adaptations from the original Johnson code, but specifically adapted to our needs. Erik, having a look at your patch is next on my list. I'll how much I can find out. Cheers, Durk If it's just a case of changing ecliptic_to_equatorial(), julian_date(), and GST() then I'm up for it. Can someone confirm that doing this will fix the issue, or is there more? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Friday 22 July 2005 16:22, Erik Hofman wrote: Andy Ross wrote: We should probably fix this, I guess. Maybe the easiest way to do it would be to contact the author; is XEarth or descendents still an active project? Actually, I've tracked this down to just one function to calculate sun_angle_deg. We do already calculate that in SimGear/simgear/ephemeris/celestialBody.cxx so in theory it would be easy to change src/Time/sunsolver.cxx accordingly and get rid of all those files. It's just that I haven't figured it out completely yet. I was hoping Durk could take a look at it. Erik Maybe this is a good opportunity to go back to this and fix this more properly. I remember never having been entirely satisfied with the exsisting situation. It's been ages though since I last looked at the astronomy code. I'm in favor of fixing this. It would be a shame to let flightgear slip from the SuSe distribution, just because of small set of files that might be mostly redundant. By what time frame would the people at Suse require this to be fixed? Things are pretty hectic at work right now, so my time is really limited. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Friday 22 July 2005 19:09, Erik Hofman wrote: Durk Talsma wrote: Things are pretty hectic at work right now, so my time is really limited. Here is what I have right now. I must be missing something obvious since the lighting isn't updated based on the sun angle: http://www.a1.nl/~ehofman/fgfs/download/sun_angle.diff Okay, I'll see if I can find some time over the weekend. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 747 Project
On Tuesday 28 June 2005 18:36, John Wojnaroski wrote: Still running with a modified version of Durk's code we used at Scale3x. we've been invited back for Scale4x and might just go to the AVSIM meeting in San Diego during September. See www.flightgear.org/Project/747-JW Great to hear that you actually managed to use the code. Hopefully by the time of the next show, I have the taxiway following code in place. I have now added some basic AI network editing capability to taxidraw. Getting this to use by flightgear shouldn't be too hard to code anymore (provided I have time). What's the date of the next meeting? Cheers, Durk P.S., It's very likely I'm in San Fransisco around mid April next year, visiting the society for Cognitive Neuroscience meeting. Any shows scheduled around that time? D. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Following up on my own message: With a very minor modification, the patch works. Considering the exceptionally bright weather we have right now, I won't be spending much time behind a computer today. Hopefully I can wrap up a new patch tonight after sunset though... Cheers, Durk On Saturday 28 May 2005 06:45, Durk Talsma wrote: I just did a quick test and it looks like the parking and rwyuse files are not yet picked up by the patch. I'm likely to have a chance to look into this tomorrow. I'm out of town for the rest of the day. Cheers, Durk On Thursday 26 May 2005 22:48, Andy Ross wrote: Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
I just did a quick test and it looks like the parking and rwyuse files are not yet picked up by the patch. I'm likely to have a chance to look into this tomorrow. I'm out of town for the rest of the day. Cheers, Durk On Thursday 26 May 2005 22:48, Andy Ross wrote: Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Hi Andy, Thanks for looking into this. I had started working on a patch, but didn't have a chance to finish it. (See AI weirdness thread earlier this month). I do have a limited number parking and rwyuse files, so I'll test it tonight. As for the parking/runway files: I've started adding some ground network node editing support to Taxidraw, so once that works, people should be able to start decorating their favorite airport Real Soon Now (TM). Cheers, Durk On Thursday 26 May 2005 22:48, Andy Ross wrote: Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
On Tuesday 24 May 2005 16:09, Harald JOHNSEN wrote: Edit apt.dat and runways.dat, just leave KSFO for example. Normaly you should leave a few others used in ai or atc (I don't remember) or disable this functionalities if you don't want an abort of FG. The latest version of the Traffic manager derived AI is done such that it discards any route that tries to fly to/from an unknown airport. Unfortunately this has to be done at startup, adding to the initialization time. The run-time consequence if you only keep one airport is that you won't see any airliner traffic... Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On Tuesday 24 May 2005 13:45, Melchior FRANZ wrote: (1) loading airport and navigation data; very rough guess: ~ 45% (2) initializing subsystems (atc, weather, ai, ...) ~ 30% (3) creating MipMaps (no perceived delay, because it's done in another thread) Maybe this is a good time time to formulate a though I've had for some time now: With rumours of a possible 1.0.0 version sometime in 2005, I don't think it's a good time to start digging into the basic architecture of FlightGear. However, once version 1.0 is out, wouldn't that be an excellent opportunity to carefully scrutinize the core architecture of FlightGear and redesign it with the goal of ruducing interdependencies, memory requirements, and improving startup time? Any thoughts/comments? Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: finite
On Friday 06 May 2005 16:12, Martin Spott wrote: Durk Talsma wrote: I would like to keep this check around a little longer, until I'm more convinced I got everything nailed down. If there are portability issues though, I don't see any strong reasons for keeping it. It's your decision. If you want to keep it, then let's add the Solaris workaround as well, Martin. I don't have a strong preference either way. Since it looks like your patch is pretty small, I'd say keep the finite check for now, until we have ironed out the bugs completely. (To give you a bit of a background: The original AI code was designed under the assumption that speeds would always be positive, which seems a reasonable assumption for aircraft :-). I added some cases with negative speed, to allow for on-ground push backs. I some cases, this could lead speeds to get down to zero, with some of the math (turn-radius, etc, etc), blowing up. The finite check is one that I added to see if things were still going as planned, because a non-zero check didn't always work. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: finite
On Friday 06 May 2005 14:00, Martin Spott wrote: Martin Spott wrote: foehn: 13:47:11 ~ man finite NAME isnan, isnand, isnanf, finite, fpclass, unordered - deter- mine type of floating-point number SYNOPSIS #include ieeefp.h If there's no suitable replacement for 'finite' then I'd suggest the following patch: Hi Martin, The finite check was added by me, while I was tracking down the possible cause(s) of a division by zero error in the AIAircraft code. I think I have nailed the problem in the latest release, but I opted to leave the finite check in there, just in case there were additional problems, assuming that this would be a portable function. I would like to keep this check around a little longer, until I'm more convinced I got everything nailed down. If there are portability issues though, I don't see any strong reasons for keeping it. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI related
Right now there are two instances where AI objects are created on-the-fly. One is in the submodels manager (see /source/src/AIModel/submodels.cxx). These are ballistic AI objects the emanate from the user airplane. Currently this is used for contrails, smoke, flares, tracers, etc. The other instance is Durk's Traffic Manager, which creates AI aircraft based on a schedule, and creates flightplans for them. This provides ongoing airline traffic. You might want to have a look at Traffic/Schedule.cxx, around line 353, where I'm creating new AIAircraft objects. These models have their own FDM, however, which take care of moving them around. If you want to move the ojects around yourself, you probably have to write your own movement code, possibly by deriving your own class from AIBase. HTH, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI weirdness
On Monday 02 May 2005 20:41, Melchior FRANZ wrote: $ strace -fF -eopen fgfs -D --aircraft=ufo 21|grep -c /Airports/AI/ 49194 Is there really no better way than to check for the existance of 49194(!) files during startup? Two for every ICAO id? [pid 377] open(/usr/local/share/FlightGear/Airports/AI//EGKH/parking.xml, O_RDONLY) = -1 ENOENT (No such file or directory) [pid 377] open(/usr/local/share/FlightGear/Airports/AI//EGKH/rwyuse.xml, O_RDONLY) = -1 ENOENT (No such file or directory) ... repeated 24596 times ... What about asking for all existing files in $FG_ROOT/Airports/AI? Let's see: $ ls -l $FG_ROOT/Airports/AI /bin/ls: /usr/local/share/FlightGear/Airports/AI: No such file or directory Whoops ... Well, the idea is to make the files in question (rwyuse.xml and parking.xml) completely plugable. If the file exists for an airport, it will be read and used, if not, some generic fallback mechanism will be used. But mind you, this is still very much a development version and if there are alternative approaches, I'm interested. I don't know what point you're trying to make: either that there is such a big discrepancy between the number of files that are checked for their precence, and the fact that there are currently none in CVS, or do you suggest an alternative approach? If the former: I do have a few parking and rwyuse files at my local copy, which I can't release yet, for licencing reasons. I've been taking a break from AI development over the last couple of weeks and only very slowly getting back to it. As such, I haven't had a chance to get back to the parking/rwyuse file issue. If the latter: please elaborate. As I said above, if there's an alternative approach, with obvious advantages, I'm interested. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: AI weirdness
On Monday 02 May 2005 21:23, Melchior FRANZ wrote: * Durk Talsma -- Monday 02 May 2005 21:16: I don't know what point you're trying to make: either that there is such a big discrepancy between the number of files that are checked for their precence, and the fact that there are currently none in CVS, Well, checking for 5 files when we can probably only expect a few hundreds in the next ten years seems like a waste of performance. No big problem on Linux with normal file systems (apart from the needless noise in debugging runs). But I wouldn't be surprised if this is a problem on other operating systems, like Win95. (Or NFS?) I thought the alternative approach would be obvious. Instead of checking for the existence of 5 possible files just ask the system for actual files? Okay, thanks for clarifying. I see what you mean. I'll put this on my TODO list. Might take a few weeks though before I'm fully back to working on this. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: AI weirdness
On Monday 02 May 2005 21:43, Frederic Bouvier wrote: Let me rephrase Melchior's suggestion : iterate on directories with plib's ulOpenDir and ulReadDir functions, possibly being recursive in the tree, and check if the name of the reported files are an existing ICAO code against the database already loaded in memory. Examples of directory scan are in fgadmin and in fgrun. -Fred Okay, that would be fairly easy to do. I'll have a look. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Scenery Object Database
On Wednesday 23 February 2005 09:48, Erik Hofman wrote: Martin Spott wrote: Cheers, Martin. P.S.: Who created the static B737 and B747 models that are sitting at KSFO ? I think Innis did the 737, but the 747 I wouldn't know. It could be a good time to remove both static planes since the Traffic manager gets quite powerful already. :-) Yes, technically we're up to the point now, where the static aircraft could be replaced by dynamic aircraft models. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Scenery Object Database
On Wednesday 23 February 2005 14:19, Innis Cunningham wrote: Erik Hofman writes I think Innis did the 737, but the 747 I wouldn't know. It could be a good time to remove both static planes since the Traffic manager gets quite powerful already. No I did the 747 David M did the 737 and yes the statics I would think can be consigned to history.Actually the 747 has now been recruited into the AI fleet so you have not seen the last of it just yet.:-) Cheers Innis Sounds cool. Innis, I assume you refer to the traffic files you sent me earlier? I'm afraid I still haven't had a chance to look at them, although its still on my todo list. In the mean time, I started doing some prepatory work on taxiway following. I'm slowing my pace a little bit though, coming out of an extremely busy period at work. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AI traffic heads-up
Hi Everybody, I thought I'd give you guys a quick heads up concerning my AI traffic development. I am almost ready to release my latest changes. Just need to do some more testing, sync my development source branch with CVS, and make sure everything runs with the currently existing data. Anyways, here's brief list of improvements: - Realistic aircraft parking location support: create a parking.xml file for your favorite airport, and AIAircraft wil park where you want them to. The file format specs will follow later. - Preferential runway use. Again Specify a list of wind time conditions in an xml file, and FlightGear's AI system will choose a group of runways for takeoff and landing, that satisfy these criteria. - Incremental Flightplan creation. This change is somewhat less visible than the previous two, but it's an important step forward, because it provides the basic framework for selecting airport specific departures/approaches, and also for autogenerating airport specific taxiroutes. - Improved AI aircraft ground handling. Specifically ground steering is improved, and I spend a lot of time making sure aircraft didn't get stuck circling around unreachable waypoints. -Push back support. Aircraft can now taxi backward by setting target speed to negative. Concerning the first two items: Parking, and preferential runway use: I really would like to make these two features a little more visible by creating parking and runway use xml files for KSFO. I could probably do this quite easily do this for the runway preferences, if somebody could tell me how the runways are typically used here. As for the parking file, I could make a simple skeleton file with a couple of parkings, but to make a realistic one would require either that I have access to some good published data or that somebody with good knowlegde of the airport helped in building one. I'll try and post a few more screenshots on my website later week/weekend and expect to submit the code sometime next week. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI traffic heads-up
On Wednesday 02 February 2005 19:40, John Wojnaroski wrote: I'll try and post a few more screenshots on my website later week/weekend and expect to submit the code sometime next week. Just wondering what updates were included in the 0.9.8 release. We'll have a FlightGear booth at SCALE3x next week and would be nice to demo some of your excellent work. If you have the time and could crank out a short XML file that would be terrific. Hi John, Thanks for the compliment. I lot of the credits also go to Dave Culp, for laying out his excellent AIModels code, David Luff for his AI/ATC work, and whoever else who contributed to these subsystems. The AI code is in rudimentary form present in FlightGear 0.9.8 release, but that doesn't include Parking, and pref runway use. If you feel adventurous: At David Luff's request I've put a code snapshot up on my webstie. http://durktalsma.xs4all.nl/FlightGear/FlightGear-0.9.8-durk-ai-prerelease.tar.gz I'll try and make rudimentary parking.xml and rwyuse.xml files for KSFO later this week. I'll try and send you some documentation later today (and please send me a reminder in case I forget). Be mindful though, that none of these versions support realistic taxi behavior yet, so all aircraft taxi straight from the airport ref point to the runway, taxiing through buildings or other aircraft if necessary. This will be next on my todo list. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain elevation question
On Monday 24 January 2005 23:56, David Luff wrote: On 24/01/2005 at 21:17 Durk Talsma wrote: What I am really looking for is a hint where I can find the code in FlightGear Hi Durk, I obtain ground elevation for taxiing AI traffic in AILocalTraffic.cxx, lines 1569 - 1602 (or thereabouts). Note that this is not a cheap operation, and you should only do it for traffic in a location which already has a tile loaded - otherwise it triggers tile loading, resets the scenery cache to the wrong location, and probably has other undesirable side effects as well. Hi Dave, Thanks, That's exactly what I was looking for. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain elevation question
Hi Folks, Since I haven't seen any response to my question I guess it's either so hard that nobody knows the answer, or it just slipped by while everybody was fighting each other last week. :-) Anyways, I'm still interested in potential solutions. Cheers, Durk On Saturday 22 January 2005 18:01, Durk Talsma wrote: Hi, I would like to experiment a little bit with adding current terrain elevation detection for AI models. Is there a function to do this, i.e. double fgGetElevation(double lat, double lon); I found that the current user location is read from /environment/ground-elevation-m but that's the elevation at the user location and not at the position of the AI plane. The reason I'm looking into this is that even at EHAM, which is quite flat there are already some very visible artifacts due to variations in ground elevation. So we'd need to address this sooner or later. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain elevation question
On Monday 24 January 2005 20:57, Curtis L. Olson wrote: Hi Durk, The terrain elevation system could stand to be looked at a bit. I think there is still a lurking bug where the wrong elevation can be returned under some circumstances immediately after a tile boundary is crossed. There are some optimizations in the current system that assume you are reading ground elevation from the same tile or same position stream as before. Be aware that looking up terrain elevation from a TIN is an expensive operation so we don't want to do very many of these lookups per frame. Perhaps your AI system could do one lookup per frame and rotate through the model list so the entire list is updated ever n frames ... or prioritize models that are on/near the ground over models that are high above the ground where it really doesn't matter so much. Does that answer your question? Curt, What I am really looking for is a hint where I can find the code in FlightGear that actually does these calculations. I tried tracing back through the functions that eventually set the value of the /environment/ground-elevation-m property, but couldn't really figure it out. Thanks for your explanation of the costs and pitfalls, I'll certainly take it into account. For a start, I would only do this for models that are on -or near- the ground, and use the general airport elevation for any other situation. Secondly, it would only be required to do this for traffic that is within a reasonable distance of the user. Thanks, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Terrain elevation question
Hi, I would like to experiment a little bit with adding current terrain elevation detection for AI models. Is there a function to do this, i.e. double fgGetElevation(double lat, double lon); I found that the current user location is read from /environment/ground-elevation-m but that's the elevation at the user location and not at the position of the AI plane. The reason I'm looking into this is that even at EHAM, which is quite flat there are already some very visible artifacts due to variations in ground elevation. So we'd need to address this sooner or later. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI piper load fix - v0.9.8a needed?
On Friday 21 January 2005 20:32, David Luff wrote: On 21/01/2005 at 20:04 Durk Talsma wrote: So time permitting I wouldn't mind having a stab at porting (some of) your code to interact with the AIModel system, it that is okay with you. As I mentioned yesterday, the taxiway code comes to mind. This approach might actually be mutually benificial, if this would free up some time for you to work on taxidraw. Eventually, we need data for the AI system, such as, taxiways and parkings/gates and taxidraw would be an ideal tool for that. Let me know what you think. Yes, in principle that's fine by me. I'd like to keep the ATC system itself in it's own directory, but I'm happy for a significant portion, or possibly all of, the AI code to move over, and for you to 'take ownership' of it. I'm not sure how far you want to go in moving it over - some of the Me neither actually. As I am moving forward, I'm trying to gather some ideas. I'm currently mainly working on splitting up the dynamic flightplan generation code, so that I can generate pushback, taxi, takeoff, climb, cruise, decend, landing, taxi, and park, sections one at the time. This code is now works, albeit at a very rough an primitive level. It's now part of FGAIFlightplan, but could logically also be part of ATC. I'm currently leaning toward having the basic route generation part of the code be part of the AIModels codebase, and traffic monitoring be part of ATC (including some code that sends instructions to the AI planes to divert from their planned routes. But, its a fine line to draw. AIAircraft are currently pretty senseless (literally: They just follow routes and don't interact very well with their environment). I'm thinking about adding a series of invisible paths sections of taxiways, and sequence each aircraft based on their position along these paths. then it would be relatively easy for each individual aircraft to determine it's distance to it's predecessor and adjust speed accordingly. stuff is very AI/ATC interaction specific, such as the logic to fly circuits, respond to ATC instructions, and alter the circuit pattern in response to the user position (in theory anyway - one of the little blighters on downwind the other day was instructed by ATC to follow me in whilst I was about 2 mile final on straight-in. At about 1 mile final he cut in front of me, and caused me to get told to go around after taking a shade too long to clear the runway!). I'll have a mull over it this w/e and have a think about where a good cut-off point might be, and what API the AIModel code will need to expose to allow the 'intelligent AI' to continue to do what it does if left in the AI/ATC branch. Certainly, taxiing and 3D model creation and management would be good candidates for moving over to AIModels initially, leaving the heuristic GA Yep. Model management is already implimentent, and taxiing would seem logical to me. generator and the circuit-flying/tower control interaction portions in the AI/ATC for now. The AIModel code would need to expose an API for the heuristic generator to call to generate appropriate traffic, and another API for the 'intelligent-flying' code to have sufficient control of the plane. Both would be possible relatively easily. There is already code to set target heading, speed, and altitude, IIRC. The only thing that would be required is some code to override FlightPlan control, but that shouldn't be too hard either. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI piper load fix - v0.9.8a needed?
On Friday 21 January 2005 16:51, David Luff wrote: Hi all, I've commited a fix for the program crash when the piper model is not present, and apologise for that. Would a v0.9.8a release be in order? The current package almost certainly crashes for everyone who doesn't have an existing base package or extra aircraft installed, and Frederic's fix of the surplus radio towers in downtown SFO is pretty important too. I too would welcome a bug-fix release shortly: I just got a bug report from Innis Cunningham that the traffic manager still crashes on windows machines. I had hoped I'd fixed this, but being a Linux developer myself, I don't have a real good opportunity to test any changes I'm making for windows versions. I'd like to overhaul my loading of GA aircraft models properly - instead of pulling them out of the installed aircraft, I think some dedicated AI models should be available to help avoid this kind of problem. Dave Martin - do I remember you saying that you had done / intended to do low-poly count versions of the pa28 and c172 at some point? If so, they would be very useful. David, earlier, I seemed to remember that you were leaning toward integrating your AI/ATC code with Dave Culp's AIModel code. In the light of this, wouldn't it be a more feasable approach to start thinking about ways to do this and eventually phase out your model animation code? I'm not suggesting you should do this, but in the light of your earlier mail, it would seem a logical step. Any thoughts? Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI piper load fix - v0.9.8a needed?
On Friday 21 January 2005 18:44, David Luff wrote: On 21/01/2005 at 18:38 Durk Talsma wrote: Any thoughts? Yes, I'm still inclined to go this way (integration), but haven't had the chance to dig into the AIModel code yet. The comments above were intended to be somewhat generic, to be implemented in whatever method/branch I wind up using. I guess I can comment more inteligently on this without the risk of suggesting stuff that already exists once I've had a good dig into the AIModel code, so I'll go and take a look... Cheers - Dave I understand, it usually takes quite a bit of time to understand somebody else's code. I'm actually fairly fluent in understanding the most relevant parts of Dave's code (i.e. FGAIAircraft and FGAIFlightPlan classes). So time permitting I wouldn't mind having a stab at porting (some of) your code to interact with the AIModel system, it that is okay with you. As I mentioned yesterday, the taxiway code comes to mind. This approach might actually be mutually benificial, if this would free up some time for you to work on taxidraw. Eventually, we need data for the AI system, such as, taxiways and parkings/gates and taxidraw would be an ideal tool for that. Let me know what you think. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] v1.0 musings (was: Aircraft included in basepackage)
3) ATC/AI This may just be my group of friends :P, but many of them find it much more fun and interesting if there are other aircraft in the world, and if they can communicate with ATC. Durk's work in this area is making this easier, but ATC itself can still feel quite primitive. Coupled with this, people expect to start on the apron if it's there, and then to taxi out to the runway of their choice. As Curt wrote earlier, the 1.0 release will probably mark the start of a new phase in FlightGear development. I tend to share this view, as more and more development efforts will shift from writing c/c++ code to designing 3D models and writing configuration scripts in, for example, nasal or .xml. AI traffic and ATC is probably one of the major exception to the rule (the other being glass cockpit support??), because development started relatively late and there is still quite a bit of C++ code that needs to be written. I hope to have some more of the basic functionality of the AI subsystem working, before the famous 1.0 release. But, similar to the other fields of development, the AI system will ultimately only come to life when people start contributing traffic patterns and low res aircraft models (c.f. www.projectai.com). Cheers, Durk P.S., I just sortof finished a first stab at implimenting preferential runway use. I've been testing this at EHAM, where traffic has been taking off from runway 24 and landing on 27, just like it did today in real life. :-) I'm considering incorporating David Luff's taxiway code before submitting my new code, but I'm not sure how much time I will have in the next weeks. D. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday 18 January 2005 08:21, Paul Surgeon wrote: On Tuesday, 18 January 2005 04:40, Ampere K. Hardraade wrote: On January 17, 2005 02:25 pm, Paul Surgeon wrote: We already have too many empty 3D models in FG without working FMCs, FMSs, ECAMs, NDs, etc. Paul It will be nice if you can implement these systems, perferablely by Nasal so that they can be flexible. Running Nasal code in the rendering loop to do tons of work would not be a very good idea in my opinion. I've looked through an A320 FCOM manual and it would take many thousands of lines of C++ to accomplish a half functional aircraft. ...[snap]... Unfortunately this is going to sit on the backburner for a long time as it's tons of work to implement, I'm already too busy with other projects and I doubt anybody else would be willing to tackle it in the near future. So, are you suggesting we should do it ourselves and shift priorities? Work on glass cockpits Instead of creating 3D models, and FDMs? Doesn't sound like its gonna work. There are currently some really talented people working on 3D models, but these people are not necessarily great programmers. And the opposite is true as well. Good programmers might be lousy 3D modellers. So, shifting priorities wouldn't work here. I don't see why the 3D modelling people shouldn't continue to work on new models. My experience with FlightGear over the years has alway been that if there is something you can do *now*, that will benefit the program in the long run that do it[1]. Cheers, Durk [1]. As an example: In the early days, around 1997, Curt asked me if I could write some code that would return the latitude and longitude of the sun's current positin, for daylight computation purposes. Having written it, adding a visual representation of the sun, moon, and the planets at their exact position turned out to be pretty trivial to impliment, and the overhead to run the code neligable, so I went ahead and did it. I remember lots of complaints from people claiming that we were focusing on the wrong things, etc etc. However, there wasn't really an alternative for me to work on at the time, so shifting priorities wasn't really an option either. And see what we have now. I don't think it hurt when we sometimes impliment things in seemingly weird orders. :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday 18 January 2005 11:53, Ampere K. Hardraade wrote: The roll out is on, LIVE! http://www.tv-radio.com/station/public_senat/public_senat-150k.asx For German user, they can tune to N-TV. Right now, it is 6:00 here. I woke up at 4:30 just to watch this! The aircraft has yet been revealed. Ampere Also BBC-World, and German ZDF (the advantage of living the the Netherlands :-). Good coincedence I was at home today. D. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Tuesday 18 January 2005 19:28, Paul Surgeon wrote: On Tuesday, 18 January 2005 13:04, Durk Talsma wrote: So, are you suggesting we should do it ourselves and shift priorities? Work on glass cockpits Instead of creating 3D models, and FDMs? Doesn't sound like its gonna work. There are currently some really talented people working on 3D models, but these people are not necessarily great programmers. And the opposite is true as well. Good programmers might be lousy 3D modellers. So, shifting priorities wouldn't work here. I don't see why the 3D modelling people shouldn't continue to work on new models. My experience with FlightGear over the years has alway been that if there is something you can do *now*, that will benefit the program in the long run that do it[1]. Point taken - model away! :) :-) I just find it frustrating when I start up a nice aircraft to find out that there no way to navigate the thing across open oceans. I don't think real world pilots use a magnetic compass to navigate where VOR's and NDB's don't live. I can imagine that. My gut feeling is though that as soon as there is a breakthough in the design of glass cockpits these changes can be traversed back to the existing models relatively quickly. I'm glad to see some discussion in this area. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A380
On Wednesday 19 January 2005 00:58, Ampere K. Hardraade wrote: On January 17, 2005 01:51 pm, Christian Mayer wrote: When do we have a flyable A380? It can't be that Airbus was faster than we are: http://slashdot.org/articles/05/01/17/0437202.shtml?tid=126 CU, Christian ;) Of course not. Check out: http://flightgear.org/Gallery/ Cool. Is this what you were working on with Innis? Looks good... Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Aircraft downloads
On Tuesday 18 January 2005 22:05, Christian Mayer wrote: Hi, the web page is comming along nicely! There's one thing that could be added: when you click on the thumbnail a normal sized picture should open. It also would be great if there'd be a thumbnail of the cockpit for that plane as well. Another thought: There are some other hangar pages out there like the ones made by David Culp and Wolfram Kuss. Would it be an idea to add a link to these pages at the bottom of the aircraft download page? Presumably we can't merge these pages due to licence incompatibilities... Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] splash screen
On Monday 17 January 2005 12:51, Manuel Massing wrote: Hi, I've been holding off my code changes already since Christmas. ;-) why not tag the planned releases as branches. This way development can continue in HEAD while the releases can be tested and bugfixed in- dependently. This is fairly standard procedure for open source projects (e.g. KDE, gcc, freebsd). Well, I guess every open source project has it's own way of doing things. Curt's announcement of a new planned release flagged the start of a feature freeze period, but it also coincided with a rare opportunity for me to do some development work. So I decided not to submit any of my work until after the release. I see some merit in branching, but I guess it would increase the workload of the project maintainers, who now need to make sure that bugfixes for the release branch make it into the development tree and vice verca. Just my two cents, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] splash screen
On Monday 17 January 2005 14:41, Innis Cunningham wrote: Hi Durk Durk Talsma writes Well, I guess every open source project has it's own way of doing things. Curt's announcement of a new planned release flagged the start of a feature freeze period, but it also coincided with a rare opportunity for me to do some development work. So I decided not to submit any of my work until after the release. Does this mean we are not going to get the fixed AI in this release?. Hi Innis, No worries mate (as I picked up while I was down under last year) :-) I did submit the bugfix, just not the new features. Btw, could some of the windows people let us know if the traffic manager now works? to activate you need to set traffic manager/enabled and (iirc) ai/enabled to true in preferences. (But you can ignore my commented out scenarios). ai-traffic enabled type=booltrue/enabled level type=int1/level /ai-traffic traffic-manager enabled type=booltrue/enabled /traffic-manager ai enabled type=booltrue/enabled !-- scenarionimitz_demo/scenario -- !-- scenarioaircraft_demo/scenario -- /ai ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 0.9.8 Scenery path bug
Hi, I just ran into the following issue: In my .fgfsrc I have specified --fg-scenery=/home/durk/FlightGear-Scenery-0.9.5/ Which is a directory I had just deleted a few minutes earlier, because of an upgrade to Scenery-0.9.[78]. As a result, FlightGear quit with a segmentaton fault. In conclusion, when --fg-scenery points to a non-existing directory, FlightGear seg faults. Because this is likely to affect users, it would be a good thing to fix before the next release. Any ideas what the best way to handle this would be? Well, finally, I found a bug. As somebody mentioned a few days earlier: They're harder to find by the day! :-) Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: 0.9.8 Scenery path bug
On Monday 17 January 2005 22:12, Melchior FRANZ wrote:
* Curtis L. Olson -- Monday 17 January 2005 21:59:
Any chance you can get us a gdb backtrace?
I can reproduce the crash, though. I'll look into it ...
m.
Thanks Melchior. Anyways, here's my backtrace: Just out of curiosity: Would it
be the case that the loader fails because it doesn't have a path to read data
from? This is a bit of a wild guess, because I didn't have time to look into
the code at all.
Cheers,
Durk
Starting program: /home/durk/src/FlightGear-0.9/source-clean/src/Main/fgfs
[New Thread 16384 (LWP 1634)]
Failed to find runway 28R at airport EHAM
[New Thread 32769 (LWP 1635)]
[New Thread 16386 (LWP 1636)]
Object PanelInstruments not found
Object ControlsGroup not found
[New Thread 32771 (LWP 1637)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16386 (LWP 1636)]
sgGenTile(std::string const, SGBucket, Point3D*, double*, SGMaterialLib*,
ssgBranch*) ([EMAIL PROTECTED], b=
{cx = 2.1290598554044618e-313, cy = 54.183372497527387, lon = 4, lat =
52, x = 3, y = 2}, center=0x4b71bbfc, bounding_radius=0x0, matlib=0x967ce20,
geometry=0xd8eaf30) at basic_string.h:249
249 { return _M_dataplus._M_p; }
(gdb)
(gdb) bt
#0 sgGenTile(std::string const, SGBucket, Point3D*, double*, SGMaterialLib*,
ssgBranch*) ([EMAIL PROTECTED], b=
{cx = 2.1290598554044618e-313, cy = 54.183372497527387, lon = 4, lat =
52, x = 3, y = 2}, center=0x4b71bbfc, bounding_radius=0x0, matlib=0x967ce20,
geometry=0xd8cecb0) at basic_string.h:249
#1 0x08305168 in FGTileEntry::load(std::vectorstd::string,
std::allocatorstd::string const, bool) (this=0xda3db68,
[EMAIL PROTECTED])
at globals.hxx:269
#2 0x082f9dd3 in FGTileLoader::LoaderThread::run() (this=0x8f0d198)
at FGTileLoader.cxx:172
#3 0x0840888f in start_handler (arg=0x0) at SGThread.cxx:23
#4 0x40039f60 in pthread_start_thread () from /lib/i686/libpthread.so.0
#5 0x4003a0fe in pthread_start_thread_event () from /lib/i686/libpthread.so.0
#6 0x4059d327 in clone () from /lib/i686/libc.so.6
(gdb)
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] splash screen
On Sunday 16 January 2005 21:54, D Luff wrote: On Sun, 16 Jan 2005 20:27:10 - Agreed. I had a look at some of it recently with a view to automatically starting on the into the wind runway with real-weather. At the moment it can't be done, since real-weather is dependent on position, and I'm trying to introduce the counter-dependency as well. What I think needs to happen is to init approx location first, then init the environment, then init exact location. David, as I mailed to you off-list (but probably not yet to FlightGear-devel), I'm working on extending the airport code. Part of the new code is going to be a function that returns the active runway for a specific airport. So, I guess, initialization could be something like (in pseudo code): 1) get airport 2) airport-get weather 3) airport/weather-getActiveRunway 4) user-init at active runway Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] splash screen
On Sunday 16 January 2005 23:07, Curtis L. Olson wrote: Let's please hold off on touching any of this and restructuring the init order until *after* the upcoming release. Curt. Curt, I've been holding off my code changes already since Christmas. ;-) Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange FG crash.
On Monday 10 January 2005 21:29, David Megginson wrote: On Mon, 10 Jan 2005 14:20:45 -0600, Curtis L. Olson [EMAIL PROTECTED] wrote: I was just flying in the SFO area with the DHC2-F and flightgear crashed with the following message: Unknown exception in the main loop. Aborting... Possible cause: Success Anyone have any ideas? This is the first time I've seen anything like that. I did a find/grep through all of the FlightGear, SimGear, and plib source code as well as the base package, and I couldn't find anything that looked like a reasonable candidate for an exception returning the message Success. Hmm, the exceptions that I know of that are still not handled very well are related to unsuccesful loading of AIModels. But usually that's not followed by any message. Just checking: Did you use any AIModels or traffic manager subsystems? Second guess: Could it be related to loading static models?? Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Terrasync
Hi Folks, I just tried out the latest prerelease of FlightGear for a stretch test, by taking the 747 on a trip halfway around the world, from EHAM to WSSS. I deleted all the scenery and ran the accompanying version of terrasync to fetch the latest scenery. I appears that a large chunk of the scenery enroute couldn't be retrieved, as I was getting the error message like the one below. Note that since I was lazy, I maintained my original 0.9.5 directory, but the new scenery should really be 0.9.8. (if I understand the terrasync operations correctly. I found scenery missing between N50, E30, and approx N30,E75, and south of N20. Is it possible that these files are not on scenery.flightgear.org, or was terrasync unable to download the scenery because of a user limit? Just curious, Durk lat_dir = 1 lon_dir = 0 mkdir -p FlightGear-Scenery-0.9.5/Terrain//e100n00 rsync --verbose --archive --delete --perms --owner --group scenery.flightgear.org::Scenery/e100n00/e103n02/ FlightGear-Scenery-0.9.5/Terrain//e100n00/e103n02 receiving file list ... rsync: link_stat e100n00/e103n02/. (in Scenery) failed: No such file or directory (2) done client: nothing to do: perhaps you need to specify some filenames or the --recursive option? rsync error: some files could not be transferred (code 23) at main.c(653) mkdir -p FlightGear-Scenery-0.9.5/Terrain//e100n00 rsync --verbose --archive --delete --perms --owner --group scenery.flightgear.org::Scenery/e100n00/e103n03/ FlightGear-Scenery-0.9.5/Terrain//e100n00/e103n03 receiving file list ... rsync: link_stat e100n00/e103n03/. (in Scenery) failed: No such file or directory (2) done client: nothing to do: perhaps you need to specify some filenames or the --recursive option? rsync error: some files could not be transferred (code 23) at main.c(653) mkdir -p FlightGear-Scenery-0.9.5/Terrain//e100n00 rsync --verbose --archive --delete --perms --owner --group scenery.flightgear.org::Scenery/e100n00/e102n03/ FlightGear-Scenery-0.9.5/Terrain//e100n00/e102n03 receiving file list ... rsync: link_stat e100n00/e102n03/. (in Scenery) failed: No such file or directory (2) done client: nothing to do: perhaps you need to specify some filenames or the --recursive option? rsync error: some files could not be transferred (code 23) at main.c(653) mkdir -p FlightGear-Scenery-0.9.5/Terrain//e100n00 rsync --verbose --archive --delete --perms --owner --group scenery.flightgear.org::Scenery/e100n00/e104n03/ FlightGear-Scenery-0.9.5/Terrain//e100n00/e104n03 receiving file list ... rsync: link_stat e100n00/e104n03/. (in Scenery) failed: No such file or directory (2) done client: nothing to do: perhaps you need to specify some filenames or the --recursive option? rsync error: some files could not be transferred (code 23) at main.c(653) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrasync
On Thursday 06 January 2005 20:56, Durk Talsma wrote: the new scenery should really be 0.9.8. (if I understand the terrasync Hmm, okay, I guess that should be 0.9.7... I also should have mentioned that FlightGear ran perfectly for the duration of the trip (although I left it running unattended for most of the time). Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.8-pre2
On Monday 03 January 2005 21:43, Curtis L. Olson wrote: The second v0.9.8 prerelease of FlightGear (v0.9.8-pre2) is now available for download and testing (source only.) http://www.flightgear.org I ask as many people as possible to download the tarballs, build and test. The more problems we can catch now, the less problems our end users will catch. Okay, I'm downloading now. :-) I have a request for the windows developers/builders: Would you guys mind testing out the AI traffic and traffic manager code? I recently submitted a few directory path bug fixes, which I'm unable to test myself, because I only have linux/cygwin. TIA, Durk ___ 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
Re: [Flightgear-devel] Announce: FlightGear-0.9.8-pre1 and SimGear-0.3.8-pre1
On Wednesday 29 December 2004 20:59, Mathias Frhlich wrote: On Freitag 24 Dezember 2004 12:00, Ronny Standtke wrote: It would be great if as many people as possible could download this pre-release and give it a try and let us know if there are any problems. After a long time not using fgfs I tested this version and run straight into a small problem: transparent wings. (see attached screenshot) I wasnt running fgfs for almost a year now but I am very sure that this problem didnt exist in older versions of fgfs. It was introduced with Erik's display list patch at the time the crease patch came up. Do you use a radeon and/or r200 chipset with the dri drivers? Nobody other complained and it seems to work with the nvidia closed source drivers. So I *guess* that this is a driver problem with the radeon/r200. Hmm, I'm also seeing this problem with an NVIDIA driver. I never mentioned it because somebody else already did. :-) Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announce: FlightGear-0.9.8-pre1 and SimGear-0.3.8-pre1
On Tuesday 28 December 2004 10:05, Erik Hofman wrote: Durk Talsma wrote: On Tuesday 28 December 2004 01:24, Arnt Karlsen wrote: On Mon, 27 Dec 2004 16:40:39 +0100, Durk wrote in message Okay, fixed these. Took not nearly as much time as I thought it should. I just send a patch to Erik. ..you missed FlightGear-0.9/source/scripts/java/Makfefile.am, looks rather non-portable to me. ;-) ..# ll FlightGear-0.9/*/*/*/M*ile.* |grep -v Makefile -rw-r--r-- 1 root root19 Dec 26 01:06 \ FlightGear-0.9/source/scripts/java/Makfefile.am Well, not really: I only fixed those pathnamens inside the core code that I contributed to in the first place, and not any misnamed files in the autoconf system. Also, could you *please* be a little more explicit in future error reports? It took me my first cup of coffee this morning to figure out that your chain of commands returns a misspelled filename (notice the extra f), whereas just saying There's a wrong filename in FlightGear-0.9/source/scripts/java/Makfefile.am would have made it obvious immediately. Anybody with CVS access care to rename this file? Eh, no. Wat's the problem? Erik Notice that the filename in question (FlightGear-0.9/source/scripts/java/Makfefile.am) is named Makfefile.am instead of Makefile.am (notice the extra f after the 'k' in the name), which I guess is not what this file is supposed to be called. I never got an error message from this, btw, but Arnt mentioned it. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] EasyXML problem?
On Tuesday 28 December 2004 19:43, Jon S Berndt wrote: I've encountered an unexpected problem with the class I have derived from EasyXML. In one of the configuration files I have, the following lines are present: function NAME=aero/coefficient/Cndr descriptionYaw moment due to rudder/description product propertyaero/qbar-psf/property propertymetrics/Sw-sqft/property propertymetrics/bw-ft/property propertyfcs/rudder-pos-rad/property value-0.043/value /product /function When I parse this construct I find that the last tagged property does not get parsed correctly. What happens as the program is actually run shows this: DATA LINE: ***=fcs/rudde=*** Parsing property name: fcs/rudde FGPropertyManager::GetNode() No node found for fcs/rudde John, I seem to remember running into similar problems. Have a look at src/Traffic/TrafficMgr.cxx in FlightGear for a workaround. IIRC, easyxml reads the data in blocks, and at the border between two blocks you need to merge the data yourselves. Or something like that. It's been a while since I wrote that, so my memory is a bit rusty. HTH, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announce: FlightGear-0.9.8-pre1 and SimGear-0.3.8-pre1
On Wednesday 22 December 2004 21:55, Curtis L. Olson wrote: The first prerelease of FlightGear-0.9.8 and SimGear-0.3.8 are available for download. Please see their respective web sites for details: http://www.flightgear.org http://www.simgear.org It would be great if as many people as possible could download this pre-release and give it a try and let us know if there are any problems. Thanks, Curt. Curt, FYI: Thanks to Innis Cunningham, I found a few non-portable pathnames in FlightGear thatI would like to fix before the next release. I'll do my best to fix these before the next release, but I may need a day or two. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announce: FlightGear-0.9.8-pre1 and SimGear-0.3.8-pre1
On Monday 27 December 2004 14:56, Durk Talsma wrote: FYI: Thanks to Innis Cunningham, I found a few non-portable pathnames in FlightGear thatI would like to fix before the next release. I'll do my best to fix these before the next release, but I may need a day or two. Okay, fixed these. Took not nearly as much time as I thought it should. I just send a patch to Erik. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announce: FlightGear-0.9.8-pre1 and SimGear-0.3.8-pre1
On Tuesday 28 December 2004 01:24, Arnt Karlsen wrote: On Mon, 27 Dec 2004 16:40:39 +0100, Durk wrote in message Okay, fixed these. Took not nearly as much time as I thought it should. I just send a patch to Erik. ..you missed FlightGear-0.9/source/scripts/java/Makfefile.am, looks rather non-portable to me. ;-) ..# ll FlightGear-0.9/*/*/*/M*ile.* |grep -v Makefile -rw-r--r-- 1 root root19 Dec 26 01:06 \ FlightGear-0.9/source/scripts/java/Makfefile.am Well, not really: I only fixed those pathnamens inside the core code that I contributed to in the first place, and not any misnamed files in the autoconf system. Also, could you *please* be a little more explicit in future error reports? It took me my first cup of coffee this morning to figure out that your chain of commands returns a misspelled filename (notice the extra f), whereas just saying There's a wrong filename in FlightGear-0.9/source/scripts/java/Makfefile.am would have made it obvious immediately. Anybody with CVS access care to rename this file? Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic parking
Hi David, Some comments embedded in your original reply. On Monday 27 December 2004 00:16, David Luff wrote: Durk Talsma writes: I haven't implimented taxiway routing yet, so right now, each aircraft taxies straight from the gate to the active runway. I bet you can guess what my next logical move will be. :-) Hi Durk, Take a flight at KEMT with the ai-traffic turned on. There's some taxying going on there. Okay, I'll have a look. I've actually been browsing and using some of your code from time to time, in particular your method to determine the active runway. I'm thinking about moving this code over into a new FGAirport class, which I'm converting from the old FGAirport struct, which is currently in Airports/simple.[ch]xx The first significant extention consists of a vectro of available parkings and a method to return which one is available. The next logical step would be to add code to determine the active runway, i.e: airport-getActiveRunway(); airport-getAvailableParking(); So the new FGAirport class would provide a unified method to access any airport related data. I also wrote a little tool to test preferential runway use schemes, and managed with just a few relatively simple set of rules to mimic Schiphol (EHAM)'s rather complex preferential runway use system, so I would also like to see if I can inporporate that into the FlightGear FGAirport class. From this perspective, a airport-getTaxiRoute(); function, based on your taxi code would also seem to be a logical extension to FGAirport. There are some good bits and some bad bits in my taxying code. The in-memory storage of a node-arc network, and the routine to find a shortest path between any two nodes is probably quite reasonable (now there's a hostage to fortune ;-)), and possibly worth you using. The code to supply the network from FGGround to the AI plane, and the code for the AI plane to follow it, is really quite hideous, and probably still has a few potential blow-ups in it. It really needs re-writing from scratch. Note how the plane 'wiggles' a bit as it passes each node - I guess I ought to read up on my control theory. Would it be an idea to return the taxi route as a series of waypoints and than let Dave Culp's AIFlightPlan code do the actual manouvering? Eventually, we need to come up with a way to override flightplan instructions, but it would seem like a good start to me to do it this way (see my original design plan: Make sure everything works, but without worrying about separation conflics, then as a next step add seperation monitoring and handling). Anyway, at this point we definately need to start co-operating, since we're going to need the same file format and editing tools for both of our AI traffic, else users are going to suffer. The file format I used was never meant to be permament BTW - just a one-off quick hack to get the KEMT proof-of-concept up and running. Do you have any firm convictions in this area already? For me, pretty much the same holds, a lot of the TrafficManager/AI manager interactions are very experimental and the same holds for the parking code. Paul Surgeon mentioned that the new xplane format allows startup locations, so we should support those if possible, but I don't know yet if these are intended for user startup or for AI parking as well. In addition, I think we should/could e-mail each other off-list some proof-of-concept file formats and decide what we need. I'll send you some stuff once I get this a little further down the line. I just started a major overhaul of the FlightPlan autogeneration code, and my current development verison of FlightGear is in a state of flux, as I'm trying to track down a major segfault. I think that the time has probably come for the AI systems to merge IMHO. Yes, absolutely. I think that probably the best thing to do is for me to instantiate my models through the Dave Culp system, since his model code is much better than mine I think. Then I can add ATC-AI interaction in my own bit, and anything we both need (such as taxying) can go in the AI-models (Culp) code to be used by both of us from one bit of code. This will require the AI-models code API to be extended so I can instantiate and control the models programatically. I believe Erik has some plans to make sure all models can be distributed logically between multiple and networked clients as well - it can only help if all AI systems use the same model tree in that respect. Any objections? I'll take a look anyway and see how much damage I'd need to do to merge. Sounds good. From what I can tell, it is currently not possible to override AI traffic with flightplans, but it shouldn't be too hard to impliment this. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Realistic parking
On Sunday 26 December 2004 07:14, Paul Surgeon wrote: How does it work? Do the aircraft follow taxiways and park at gates or ramp designations? That's the ultimate goal. For the current code, ie. for testing, I created an xml file containing parking location and orientation information, which I converted from MS FlightSim (from project afcaddata) , using an exsiting bgl decompiler. Since the decompiler output was in xml format, reading it in to FlightGear was pretty trivial. I haven't implimented taxiway routing yet, so right now, each aircraft taxies straight from the gate to the active runway. I bet you can guess what my next logical move will be. :-) I still need to update the gate assignment and release logic a bit more, and also need to split the flight plan generation code, so that parking spots are not assigned until at the last minute. BTW : I see that the X-plane apt.dat file allows startup locations (for things like gate numbers, ramps, helipads) as of version 7.01 and up. Ah, that's good news. I didn't know yet, but it sounds like we should use this info in the future. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Realistic parking
Merry Christmas everybody, Yesterday, I had some time to have a first stab at adding realistic aircraft parking code to FlightGear. I've added some screenshots on my website: http://durktalsma.xs4all.nl/FlightGear/web/index.html This is all still very expermental. Involving a pretty big overhaul of FlightGear's airport handling code. In view of this and the upcoming release, I'm putting the submission of this code on hold for a little while. Nevertheless, it's a lot of fun to work on. :-) Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] apt.dat.gz replaces basic.dat.gz and runways.dat.gz
On Thursday 23 December 2004 03:09, Durk Talsma wrote: On Thursday 23 December 2004 01:00, Curtis L. Olson wrote: Everything seems to work as before, but I haven't tested the ATC/AI/Traffic manager stuff so someone who uses that stuff should do a quick check to make sure I didn't break anything there. I'll have a look at it tomorrow. Curt, I just checked this and it looks like everything is working just fine. One thing I did find though is that FlightGear quit when the AIFlightplan code tried to generate a flightplan into or out of a non-existing airport. I have a fix for the problem, which I would like to test a little further. Should be finished well in time before the new release. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] apt.dat.gz replaces basic.dat.gz and runways.dat.gz
On Thursday 23 December 2004 01:00, Curtis L. Olson wrote: Everything seems to work as before, but I haven't tested the ATC/AI/Traffic manager stuff so someone who uses that stuff should do a quick check to make sure I didn't break anything there. I'll have a look at it tomorrow. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [OT] Spectacular ground transport
Tonight an old KLM-747 will be shipped through the canals of Amsterdam on it's way from Schiphol Airport (EHAM) to the new Aviodrome (http://www.aviodrome.nl) museum at Lelystad airport (EHLE). I found some pictures at: http://www.ruudleeuw.com/phbuk-15dec04.htm The transport will pass near where I live in a few hours, so I'm tying to see if I can catch a glimpse. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI Aircraft Models
On Monday 29 November 2004 11:03, Chris Metzler wrote: On Wed, 24 Nov 2004 07:29:02 +0100 Durk Talsma [EMAIL PROTECTED] wrote: [ snip ] Another thing I noticed is that when the AIModel subsystem loads multiple copies of an aircraft, separate copies of each model are loaded each time, instead of referencing to the already loaded copy in the ssg scene graph. Having multiple copies of a polygon heavy AI aircraft led to severe memory problems on my system. Wow. For this and other reasons, I'm currently leaning toward favoring having a separate set of low-polygon count models for AI aircraft. Maybe I'm not following, but it seems like you're saying that the problem is the multiple loading of the same 3D model (for each AI aircraft) rather than reusing one existing copy in memory. Right? If that's the case, it would seem like trying to minimize how bad this is by using low-resolution models is not so much solving the problem as working within it; and the best solution would be to get plib to be able to only load the model once and to reference it for additional aircraft. But maybe that's really, really hard? -c These are kind of additional complicating factors. Loading multiple copied turned out to be a huge problem, so I fixed that after sending my first mail (code changes should be in CVS now; thanks Erik). However, eventually we still might have to need quite a variety of AI aircraft, especially when multiple liveries come into play. After solving the multiple copy problem, the AI system became a lot more flexible and I was able to load close to 1200 aircraft, but when multiple aircraft came into view, I experienced some nasty problems, including DList stack overflows. Reducing polygon count by creating special AI versions of all our common aircraft (i.e. omitting the cockpits, and instruments) reduced this problem further. There's still a lot of room for improvement, by optimizing model parameters and deleting models that are no longer used (not yet implimented), but it's also good to start thinking about ways of reducing polygon count for AI purposes. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Traffic Management screenshots
On Monday 29 November 2004 09:17, Chris Metzler wrote: Looking cool! I'm curious whether you have ideas on how to generate traffic data (flights and flightplans) for the aircraft that the TrafficManager and AIManager will handle. Are you thinking of doing real-world flights? If so, is there a good place to harvest that data? Thoughts on how to convert it into flightplans of the style you use? Many ideas, but no real solutions yet. I have made a few example traffic files by hand, based on airline and airport time tables and some imagination. Flight plans are currently autogenerated by FlightGear. Nothing fancy, but just a set of waypoints connecting the center point of the departure and arrival airports, using a runway for take-off. I don't know of any good data source for traffic schedules. Eventually, I'm hoping to be able to use the data from projectAI (http://www.projectai.com), using a conversion tool that exports their data into a FlightGear format xml file. I'm unable to contact them, however, because their contact email addresses appear not to be working. I'm thinking about making my conversion script available for download, so that users could download their own favorite PAI files and convert them to flightgear format. AFAICT, that wouldn't be in violation of their licence. I've also started writing a small tutorial on creating traffic files, but that's not ready for release yet. Given the work that still needs to be done, there's clearly no urgency to this. I'm just curious what direction you're going . . . Aside from finishing the tutorial and updating the pai-conversion script, I'm trying to add more realistic airport parking and taxi behavior. Once that's in place separation handling would be next. This is indeed not something that I expect to finish off soon. Anyway, cool stuff. -c Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.2.4 released
On Wednesday 24 November 2004 18:22, David Luff wrote: I've put TaxiDraw-0.2.4 up at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. This is purely a bug-fix release - there is another version in the works with some more features. Changes from 0.2.3 to 0.2.4 are: I just downloaded and installed taxidraw for the first time. Looks neat and fairly easy to use. I have a question. Would it be an idea to add a gate or parking editor function to taxidraw? The reason I'm asking is that I'm starting to think about ways to improve AI parking at the major airports. So eventually, for the major airports we would need to indicate at which exact coordinates aircraft could park. To me it seems this would be a logical extension of taxidraw. Any ideas? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Traffic Management screenshots
Hi Folks, This morning I decide to post a selection of FlightGear sceenshots on my website illustrating the development of the TrafficManager subsystem, and its interface with the AIManager. http://durktalsma.xs4all.nl/FlightGear/web/index.html Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Traffic Management screenshots
On Saturday 27 November 2004 09:38, Erik Hofman wrote: It's getting busy: 725 Aircraft in one scene! How is the performance in those situations? Erik I've actually had it up to close to 1200 AI aircraft. :-) It does take a hit on performance. With the traffic manager enabled, Initial performance on my system is about 30fps, which dropped to about 13fps once more than 1130 AIModels were created. It's not likely though that release versions of FlightGear will have to handle so much AI traffic in the near future though. The traffic file I used for testing is one that I converted from projectAI data, which I can't release without their permission and since the main contact email addresses on the projectAI website appear to be non-existent I wouldn't even know how to ask them for permission. Second, in the current version of the code, *every* aircraft that is within 500nm of the user is created as an AIModel. This covers a huge area, and can most likely be shrunk considerably. Third, once an AIModel is created, it is never released again by the AIManager once it flies out of user range again. Modifying the bahavior of the last two points is moving up my prioritylist pretty rapidly. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AI Aircraft Models
Hi Folks, Following up on Curt's question about the aircraft directory layout, I would like to bring up a slightly different but related issue, that of aircraft models for use in AI traffic. Over the past summer, we've had to deal with many inconsistencies that were related to the AI traffic manager subsystem using aircraft models that were not included in the release version of the base package. While given the experimental status of the traffic manager at the time, we reached an acceptable solution of not using traffic based on aircraft that are not in the base package, in the future, this is undesirable. Another thing I noticed is that when the AIModel subsystem loads multiple copies of an aircraft, separate copies of each model are loaded each time, instead of referencing to the already loaded copy in the ssg scene graph. Having multiple copies of a polygon heavy AI aircraft led to severe memory problems on my system. For this and other reasons, I'm currently leaning toward favoring having a separate set of low-polygon count models for AI aircraft. The basic idea would then be to have a directory looking like this: data/Aircraft/AI/ which then has subdirectories for each aircraft. Like data/Aircraft/AI/777 and within each directory there are subdirectories for various liveries for example: data/Aircraft/AI/777/American data/Aircraft/AI/777/KLM data/Aircraft/AI/777/United etc etc Then inside each of these livery subdirectories there would reside not only the texture files for the respective aircraft, but also all the traffic files for this aircraft. The traffic manager would then scan this directory and automatically load all the traffic files it would find here. This way, adding or removing AI aircraft would automatically adjust the amount of traffic generated. Any thoughts or ideas? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Traffic Manager update
Hi Everybody, The last couple of months have been extremely busy for me, so there wasn't much time left for FlightGear. But during the last week or so I managed to tweak my local copy of FlightGear so that the traffic manager controlled aircraft's behavior is extended in significant ways. To list some of the changes, A.I. traffic can now: - Be initialized while on the ground and remain parked until the scheduled time for take-off. - instead of disappearing at the end of a flight, load a new flight plan and wait in parking position until the next scheduled departure time. - communicate back to the traffic manager which aircraft have been deleted from the AIModels manager. The last part of the code would allow for flights that have gone out of user range to be deleted and recreated when necessary. I'm not using the latter part of the code though. I haven't submitted the new code yet, because I'd like to test it a little more. Hopefully I'll get it out sometime this week. Next, I'm thinking about creating some more traffic in and out of KSFO. Although there is no realistic aircraft parking yet, having some traffic moving at KSFO makes the area a lot more interesting. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MD11 model filenames
On Monday 08 November 2004 10:13, Richard Bytheway wrote: I have noticed that there are files in the MD11 model which have the same name on a system with a case insensitive filesystem: To the best of my knowledge, this duplication was introduced when Erik changed the original upper case names to lower case, because I thought the upper case filenames might give problems on windows systems, or something like that. But, on case-sensitive OSses (such as my trustworthy linux station). The 3ds model file expects all upper case texturefile names, which is why they were changed back to their original state. I guess the lower case files remained in CVS, but I'm not sure about that. Maybe Erik can enlighten us? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: Segfault
Dave, Looks like you are right: I also got these segfaults. Works again now. However, I discovered that the new version of the usb-pro-yoke.xml file undoes a few changes I submitted early summer. I changed the behavior of the flap switch to match it with how the keyboard handles it. Could we please add this part back in? button n=6 repeatablefalse/repeatable binding commandnasal/command scriptcontrols.stepFlaps(-1)/script /binding /button button n=7 repeatablefalse/repeatable binding commandnasal/command scriptcontrols.stepFlaps(1)/script /binding /button I've attached the modified file for those who want to try it out. Cheers, Durk On Saturday 16 October 2004 05:32, Dave Perry wrote: The cause of the segfault was the replacement of pro-yoke-usb.xml in CVS with a windows edit (moving the hat axes up by one which breaks linux). So I edited the new file with number unix5/unix windows6/windows /number and a similar edit for axis 6/7. I tested the edit with today's cvs in linux and the recent windows 9.6 binary. One caution. It seems that the propeller and mixture may have their axis interchanged between versions of the CH usb yokes. Would the person who changed this file in cvs please post the name that js_demo gives for his yoke. If his is different than mine, then using name ... /name, we could have two different files that have the right propeller and mixture axis for both. Also, I am attaching the edited pro-yoke-usb.xml file. It would be an improvement for both linux and windows users if this were added to cvs. Regards, Dave Perry ?xml version=1.0 encoding=UTF-8? PropertyList nameCH PRODUCTS CH FLIGHT SIM YOKE USB /name nameCH FLIGHT SIM YOKE USB /name axis n=0 descAileron/desc binding commandproperty-scale/command property/controls/flight/aileron/property power2.0/power /binding /axis axis n=1 descElevator/desc binding commandproperty-scale/command property/controls/flight/elevator/property factor type=double-1.0/factor power2.0/power /binding /axis axis n=2 descThrottle/desc binding commandproperty-scale/command property/controls/engines/engine[0]/throttle/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[1]/throttle/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[2]/throttle/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[3]/throttle/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[4]/throttle/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[5]/throttle/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[6]/throttle/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[7]/throttle/property offset type=double-1.0/offset factor type=double-0.5/factor /binding /axis axis n=4 descMixture/desc binding commandproperty-scale/command property/controls/engines/engine[0]/mixture/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[1]/mixture/property offset type=double-1.0/offset factor type=double-0.5/factor /binding /axis axis n=3 descPropeller/desc binding commandproperty-scale/command property/controls/engines/engine[0]/propeller-pitch/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/engines/engine[1]/propeller-pitch/property offset type=double-1.0/offset factor type=double-0.5/factor /binding /axis axis descView Direction/desc number unix5/unix windows6/windows /number low repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-heading-offset-deg/property step type=double2.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-heading-offset-deg/property step type=double-2.0/step /binding /high /axis axis number unix6/unix windows7/windows /number descView Elevation/desc low repeatabletrue/repeatable binding
Re: [Flightgear-devel] joystick support broken
Dave, I just tested my setup. Same problem here. I suspect that a recent change in plib broke things. Yesterdays cvs update of plib consisted mainly of js updates. I have also submitted some CH Yoke config changes to the base package, (mainly how it handles flaps) which were added to cvs yetsterday (thanks Erik). But they're unlikely to cause them not being recognized, because they worked with my setup before. I'm probably going to revert to a reseased version of plib. Once we have a better picture, we should probably mail the plib developers list. Cheers, Durk On Monday 16 August 2004 05:59, Dave Perry wrote: I just updated plib, SimGear, fgfs, and the base package from cvs. Both js_demo and fgfs dont identify my CH Flight Sim Yoke and my Pro Pedals, both USB. js_demo shows just for the name of both. jstest identifies both correctly. I tried and old js_demo and it worked as usual. Does anyone know of a change that could cause this? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Spawning new AI instances
On Wednesday 04 August 2004 14:41, Frederic Bouvier wrote: Is there a way to create new instances of AIAircraft or another kind on the fly, just by adding some nodes in the property tree, or running a command from the telnet interface, that is, without modifying the source code ? Is there something planned in this direction ? Fred, Just curious whether or not you had a specific purpose in mind.Creating a traffic file is probably the closest you can get to creating AIAircraft instances dynamically during the simulation, but it is not possible at the moment to start traffic by interacting with the property tree. As David already explained, creating traffic is rather involved and probably requires new code. While I like the idea and can see some uses for it, I didn't really design the traffic manager with that idea in mind, and I don't really see how the code could be adapted to do this. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Spawning new AI instances
On Wednesday 04 August 2004 20:54, Frederic Bouvier wrote: The idea would be to control the AI traffics ( creation, animation and deletion ) from an external program with the telnet interface. Someone ask me if it is possible lately, and I think he is prepared to do the required changes. I already suggested him to design new commands for creation/deletion and use the properties for animation. They would be 'run' from the telnet prompt. Hmm, that's an interesting thought, because that was actually one of the possible mechanisms that I had in mind for the traffic manager. That is, have the schedules managed by an independent program that would communicate with FlightGear through a network layer. In the end I decided not to go into this direction after doing some tests and finding that the the easiest way to do it was by adding the traffic manager as a subsystem to the main FlightGear program, specifically because the overhead of managing the schedules turned out to be a quite low. Doing this through a network remains an interesting option though... Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Interesting 747 ground handling bug
Hi Guys, Okay, here's an interesting take-off problem. Try running fgfs --airport=FHAW --aircraft=747 The runway has a pretty big slope and as soon as the nose wheel hits the sloping part, the FDM freezes. Cheers, Durk P.S., running fgfs-0.9.5-pre3, base-0.9.5-pre3, and terrasync scenery download enabled. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgfs aborted with the dc3
Hi Ron, That explains it: In version pre2, MD11 traffic is still generated, but the required aircraft is not included in the base package. Around the time one you're trying to start, one of the KLM MD11's starting from of heading for Asmterdam is probably causing trouble. Version pre3 has its own set of problems, but they should be fixed in the final release. Cheers, Durk On Saturday 31 July 2004 13:16, Ron Lange wrote: Hi Durk, here are the requested informations: fgfs-versions: FlightGear-0.9.5-pre2 / fgfs-base-0.9.5-pre2.tar.gz starting time: between 10:00am and 1:00pm (noon here in germany, while my son's sleeping...;-) ADEP: ETHB - Bückeburg, Germany (located in the e000n50 scenerey) with the Bo105 Regards Ron ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Segmentation Fault: (was Re: [Flightgear-devel] Ready for next release?)
Hmm, I hate to spoil the party, but I did get a segmentation fault in FlightGear today (running 0.9.5-pre3). I'm not sure when it happened, since I started FlightGear this morning and letting it fly between KSFO and EHAM (which appears to become my favorite test route :-)), while I went off to work. The crash happened somewhere in around 63-degs North and 84-west, based on the console output from terrasync., so that was probably after about 4 or 5 hours of running. Unfortunatly, being in a hurry this morning I didn't run flightgear from within gdb, so I don't have any idea yet what might have caused it. I do seem to see these kind of chrashes more with the 747 (yasim) than with any of the other jets (jsbsim) I've tried, but that's only a working hypothesis for now. Any Ideas, suggestions? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Segmentation Fault: (was Re: [Flightgear-devel] Ready for next release?)
Yes, the following files were missing. Curt wrote me yesterday that he had missed them somehow while updating from cvs, but that he has them now and thus be in the final release. The segfault I'm getting is not related to these missing files though, because that would only give a problem during initialization. Cheers, Durk Traffic/KLM/MD11/PH-KCA.xml Traffic/KLM/MD11/PH-KCB.xml Traffic/KLM/MD11/PH-KCC.xml Traffic/KLM/MD11/PH-KCD.xml Traffic/KLM/MD11/PH-KCE.xml Traffic/KLM/MD11/PH-KCF.xml Traffic/KLM/MD11/PH-KCG.xml Traffic/KLM/MD11/MD11.xml Traffic/KLM/KLM.xml Traffic/UAL/737/N388UA.xml Traffic/UAL/737/N376UA.xml Traffic/UAL/737/N377UA.xml Traffic/UAL/737/N390UA.xml Traffic/UAL/737/737.xml Traffic/UAL/UAL.xml Traffic/fgtraffic.xml On Thursday 29 July 2004 20:53, Erik Hofman wrote: I know the missing files you mentioned earlier spoiled it for me right at startup. They have to be included, otherwise it looks really bad on FlightGear. Could you explain which files are missing exactly? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
Curt, I'd say almost. My stuff has been checked in and seems to work fine now. My only concern is that I just downloaded pre3 about two hours ago and haven't even had a chance to compile it. Therefore, I'd prefer to wait just a little longer. Probably just a day or so to see if anything unexpected shows up. (if your schedule allows that of course). How's that sound? Cheers, Durk On Wednesday 28 July 2004 19:53, Curtis L. Olson wrote: We have now done 3 pre-releases and hopefully we have most of the major issues dealt with for this release. Have we missed any patch submissions? Are there any remaining issues that can be *quickly* dealt with? If I sat a chicken at a computer and made it look at even 1/2 the email I receive each day, I'd probably get put in jail for cruelty to animals, so I could very well have missed a patch or two or 10 along the way. Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Ready for next release?
Just one quick note: There are still a number of traffic files missing from the fgfs-base-pre3, even though they are in CVS now. Unfortunately, these file are required, even when the traffic manager is disabled. Fixing this is on my todo list, but I likely won't be able to fix this before the release. Cheers, Durk On Wednesday 28 July 2004 21:30, Curtis L. Olson wrote: Durk Talsma wrote: Curt, I'd say almost. My stuff has been checked in and seems to work fine now. My only concern is that I just downloaded pre3 about two hours ago and haven't even had a chance to compile it. Therefore, I'd prefer to wait just a little longer. Probably just a day or so to see if anything unexpected shows up. (if your schedule allows that of course). How's that sound? Sounds fine, I wasn't planning on rolling out the official release today anyway. Tomorrow is probably the earliest ... more likely friday. Regards, Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
