Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots)
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Maik Justus Sent: 18 December 2007 23:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots) Hi Viviam, Vivian Meazza schrieb am 18.12.2007 23:41: I've just a few moments ago added a few lines of code to AIBallistic which apply an external force (using the same math as above). The rest works as before. I just need few properties to set the magnitude and vector of the external force and it will be done, at least for testing. Thank you, very good. Is it possible to pass the forces in the earth fixed coordinates axes base? (in Newton or pof)? I'm planning, and have tested the passing of the force in terms of magnitude (pound force), azimuth (degrees, north = 0) and elevation (degrees, horizontal = 0, up = 90). I hope this is what you need, and can work with. It's trivial really, but I'm assuming that the external force applies no rotational force to the object. I think this could be easily faked. e.g. new_roll = old_roll + cos(old_roll) * force_in_y_direction * a_magic_constant * dt but i f I read the code correctly, yaw and hdg are pointing at the speed direction (slightly filtered)? Therefore we need something like _elevation = atan2(force_in_z_direction,force_in_x_direction) and then your filter to add some inertia? Right now there are 2 options - 1, the ballistic object aligns with the velocity vector (damped), or 2, it remains static. These options both work with the new code. I think option 1 will do for an under slung load? I haven't a great deal of time available in the run up to Christmas so no promises on completion. Same here. I will have very limited access to my computer (family visiting tour). Fortunately my computer is a notebook, but I am not sure if there is any space in the car for my joystick. We have a horde of family visitors over the coming days - all competing for my time and the computer. We'll see how much can be done (not a lot I expect). Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] External Cargo, was: Re: screenshots (and snapshots)
Maik Justus Sent: 18 December 2007 21:02 To: FlightGear developers discussions Subject: [Flightgear-devel] External Cargo,was: Re: screenshots (and snapshots) Hi, Vivian Meazza schrieb am 18.12.2007 00:27: Maik wrote Hi, Melchior FRANZ schrieb am 17.12.2007 02:18: * Georg Vollnhals -- Monday 17 December 2007: Just now (!!!) remembering Torsten's Dragonfly banner-trick (!!!) which is pretty similar: Yes, it's clearly a job for Maik's winch/anchor feature. He has already lifted me via MP: I was in a sgs233, and Maik lifted me with a bo105. There's just no visible rope (yet). Can an external force be added to the AIBallistic Objects? I don't see why not. Just designing on the back of an envelope - we already have one - wind. So in principle we add something like another wind. Not in the next few days though. Vivian I had a look to AIBase.?xx and AIBallisitic.?xx. I think all we need is already there. The objects speed can be modified by a Nasal script. YASims winch/aerotow/anchor can be connected directly to any AI object and (with some Nasal code, which copies the location) to anything else. The force on the other object is calculated and stored in the property tree. Some Nasal code only need to take this force, multiply it by dt and divide it by the objects mass and add the result to the objects speed (which need to be converted to (and afterwards back from) the earth-coordinate system). If we use a AIBallistic object, the gravity and drag effects would be calculated automatically. Therefore external cargo missions, SAR missions or even banner-towing with realistic forces on the aircraft should be possible with fg1.0.0 I've just a few moments ago added a few lines of code to AIBallistic which apply an external force (using the same math as above). The rest works as before. I just need few properties to set the magnitude and vector of the external force and it will be done, at least for testing. It's trivial really, but I'm assuming that the external force applies no rotational force to the object. I haven't a great deal of time available in the run up to Christmas so no promises on completion. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots (and snapshots)
Maik wrote us Sent: 17 December 2007 19:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] screenshots (and snapshots) Hi, Melchior FRANZ schrieb am 17.12.2007 02:18: * Georg Vollnhals -- Monday 17 December 2007: Just now (!!!) remembering Torsten's Dragonfly banner-trick (!!!) which is pretty similar: Yes, it's clearly a job for Maik's winch/anchor feature. He has already lifted me via MP: I was in a sgs233, and Maik lifted me with a bo105. There's just no visible rope (yet). Can an external force be added to the AIBallistic Objects? I don't see why not. Just designing on the back of an envelope - we already have one - wind. So in principle we add something like another wind. Not in the next few days though. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] missing fsfgdb files in base package?
Durk Talsma Sent: 16 December 2007 06:20 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] missing fsfgdb files in base package? On Sunday 16 December 2007 05:51, Curtis Olson wrote: Perhaps a short term fix would be to simply move the lights so they align properly with the existing terminal building. An even simpler fix would be to temporarily remove them until after the release. I've only had a chance to take a brief look around the new scenery so I hope there aren't other significant issues as well. I did notice 2 doubled up glide slope structures between the ends of 28L and 28R. For now, I've commented-out all references to the light-pole in the default scenery related stg files. While at it, I also took the liberty of commenting out the static aircraft, as they (at least the 747) were occasionally overrun by AI traffic. I hope these changes are acceptable to everyone. If not, it's fairly easy to undo them. For that reason, I decided to go ahead and commit these changes to the base package, so everybody will have a chance to look. In general, I do consider the new scenery an improvement, and considering that this release will ship under the V1.0 number a good argument for trying to get as many aspects of the program up to date as possible. For now, I really hope that the seahawk missing texture file really is the only correction we're waiting for. FWIW, I'm probably out of email contact until tonight, as my father and my sister (along with her family) will be visiting today. Hopefully we can roll up the base package tonight. As I have already said, I have no missing Seahawk file here, but if someone would please just say which one is missing I'll upload it immediately. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] BUG(S) with new(?) KSFO scenery in cvs
Durk Talsma Sent: 14 December 2007 07:54 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] BUG(S) with new(?) KSFO scenery in cvs On Friday 14 December 2007 00:02, Stewart Andreason wrote: Also, at KOAK Oakland, looking at the AI Traffic congregating around the terminal, would look better if the building were there. Perhaps nobody has built it yet? I have also seen a 747 sitting on top of a 737 on top of some third plane at N37*43.34 W122*13.12 but since it is not always there, I assume it is another AI traffic bug. Also, I have seen up to 4 airplanes at the NW terminal at KSFO sitting 50 feet off the ground. I just committed a first set of changes that makes the ground network more consistent with the new airport layout. But I still need to do a second pass and update the parking locations, so they're not partially overlayinig the terminal building. I'll try to get that done before the release. When you see stacked aircraft, that's usually a sign of overflow (i.e. more aircraft present than there are parkings available. If you see it, can you let me know around what time of day it occurs? So that I can have a look and see what kind of parkings need to be added. I assume that this is at KSFO? I'm off to a conference in a few minutes, and probably won't be in email contact for today and much of tomorrow. Assuming Vivian manages to update the remaining Sopwith Camel animations, and I manage to get the groundnetworks updated, I think we're ready to roll on Saturday. There is lots I would like to do on the Camel, but these can wait. It's now fit for plib release, but in making it so it's now broken in OSG. Over the next couple of days I will try and make it work in both, and see what else can be improved. Meanwhile, as I said, it is ready to go. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release in progress
Durk Talsma Sent: 15 December 2007 20:07 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Release in progress On Saturday 15 December 2007 20:46, Melchior FRANZ wrote: * AnMaster -- Saturday 15 December 2007: Yes but tar ball have been made [...] But they aren't released. Can still be fixed. Agreed. The missing file has already been committed by Syd Adams. Now I'm getting the following: WARNING: ssgSGIHeader::: Failed to open '/home/durk/src/FlightGear-0.9/data/Aircraft/dhc2/Models/chrome1.rgb' for reading. Object RLHFdoor.glass not found Doesn't seem to be a major problem, because I don't see anything obviously wrong with the model. Might be good if Syd could check. Assuming that the error above points to only a very minor problem, I guess the only issue is one missing file on the seahawk. Hmm - if I could find a missing file in the Seahawk, I'd fix it And there is a major issue with the chrome shader in the Camel - seems as if it makes the windscreen opaque in some systems - but not here. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] screenshots (and snapshots)
gerard robin Sent: 14 December 2007 15:31 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] screenshots (and snapshots) On ven 14 décembre 2007, Melchior FRANZ wrote: For a new release, especially one with version number 1.0, we should provide some new screenshots for the website. Normally, Curt would ask for that, but as he is/was away for a few days, I start with this reminder. Screenshots should ... SNIP Here's the result of a quick test with the A-10 near KNID. It isn't spectacular, but you can see that there's full antialiasing and still a nice shadow effect. This would have been quite hard (though possible!) with a real A-10 flight. http://members.aon.at/mfranz/a10.jpg [32.9 kB] m. yeah, i have one,:) It could be a tale the Alouette and the Cow http://pagesperso-orange.fr/GRTux/Alouette_III-img4.jpg (only a joke) Hey - a cow!!! First time I've seen one. Not bad at all :-) Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bleriot - Sopwith Camel?
AJ MacLeod wrote: Sent: 13 December 2007 20:19 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bleriot - Sopwith Camel? On Thursday 13 December 2007 19:52:18 Durk Talsma wrote: In light of some recently uncovered problems related to the bleriot, how about making a last minute decision to replace it with the sopwith camel? I just checked the aircraft, and can confirm that it doesn't segfault by switching on aircraft shadows. Hi Durk, I'd be very happy to see the Camel getting some exposure, but my only worry is that it was developed for OSG... it doesn't use any particularly special OSG-only effects, but last time I looked some of the control animations were broken in PLIB. They work perfectly in OSG, and of course we could probably rewrite them for plib, but I don't think I'll have time in the next day or two :-( Unless Vivian can? Needs a bit of work to make the animations right. Hmm - don't know what's required right now - but I could perhaps do it tomorrow sometime. Lot's and lots of vertices, and no easier to fly than the original! If Durk can give us a little time? Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bleriot - Sopwith Camel?
Durk Sent: 13 December 2007 22:34 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bleriot - Sopwith Camel? On Thursday 13 December 2007 23:13, Vivian Meazza wrote: If Durk can give us a little time? Sure, no problem. OK - I've fixed the main issue - the control stick - in cvs. Now for the minor ones. V. - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release update
Durk Sent: 11 December 2007 19:16 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Release update On Tuesday 11 December 2007 14:48, Melchior FRANZ wrote: * Durk Talsma -- Tuesday 11 December 2007: As it looks right now, either tonight, or Thursday evening will be my two windows of opportunity this week. I would rather go for Thursday, then. It's only known for a short time which aircraft are planned to go in, and even today and yesterday there were commits made to them. I could imagine that some want to make some last fixes and improvements. A release number of 1.0 may not mean much to some people here, but it *does* mean something for a lot of the people out there, and I expect a lot more attention to a FlightGear v1.0 release than to a 0.9.11 one. We might get more reviews in more important places, and it can't hurt to polish some more. (And I committed a code change yesterday that could still turn out to have broken something. It would be a disaster if we had to release 1.1 a week after 1.0. :-) Okay, since I've gotten a few requests to roll up the tar files on Thursday, let's do that. I usually try to make sure that I'm around for a little while after a major commit, in case something goes wrong. Therefore, I will commit all the required changes to make the release happen today (makefile, and configure stuff), but wait with tagging CVS and rolling up the tar files on Thursday. I've just updated the Seahawk in preparation for the release, and noticed a couple of thing: 1. Nav-lights seem to be broken across MP. I haven't been able to fix it, but I note that in multiplaymgr.cxx it's a float, but everywhere else it's a bool. I don't know if this is the cause, but anyway I've put a workaround into the Seahawk. 2. I still have stepping clouds here on start-up or when changing weather scenarios. The fix is trivial - I've worked with Tim Moore on a patch. Finally, I still get a crash if FG runs long enough. It _seems_ as if this can be avoided if I disable Traffic Manager, but it might just be hastening the inevitable end. Regards Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release update
Anders Gidenstam Sent: 12 December 2007 14:59 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Release update On Wed, 12 Dec 2007, Vivian Meazza wrote: I've just updated the Seahawk in preparation for the release, and noticed a couple of thing: 1. Nav-lights seem to be broken across MP. I haven't been able to fix it, but I note that in multiplaymgr.cxx it's a float, but everywhere else it's a bool. I don't know if this is the cause, but anyway I've put a workaround into the Seahawk. Hi, I'm pretty sure the types have to match for the property to be sent over MP. If most aircraft use bool for nav lights it is probably a good idea to change the type in multiplaymgr.cxx. (Bool does sound more logical to me, but none of my aircraft include proper nav lights yet so I don't know much about these.. :) Yes, I think that's the case, but I've changed the type in multiplaymgr.cxx to bool, and that doesn't fix it. I'm not sure what to do next. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Release update
Melchior wrote: -Original Message- Sent: 11 December 2007 13:49 Subject: Re: [Flightgear-devel] Release update * Durk Talsma -- Tuesday 11 December 2007: As it looks right now, either tonight, or Thursday evening will be my two windows of opportunity this week. I would rather go for Thursday, then. It's only known for a short time which aircraft are planned to go in, and even today and yesterday there were commits made to them. I could imagine that some want to make some last fixes and improvements. A release number of 1.0 may not mean much to some people here, but it *does* mean something for a lot of the people out there, and I expect a lot more attention to a FlightGear v1.0 release than to a 0.9.11 one. We might get more reviews in more important places, and it can't hurt to polish some more. (And I committed a code change yesterday that could still turn out to have broken something. It would be a disaster if we had to release 1.1 a week after 1.0. :-) I still have some tinkering to do on the Seahawk, since it's the first time this has appeared in the base package - Thursday please. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Building FlightGear, once again
Jon S. Berndt Sent: 10 December 2007 01:28 To: Flightgear-Devel Subject: [Flightgear-devel] Building FlightGear, once again For the first time in a very long time, I have a system on which I should be able to build and run FlightGear. I had a script some time ago that handled updating plib, simgear, and flightgear from cvs, and then built compiled that. I think things have changed quite a bit. I've got Cygwin and MS Visual C++ Express 2005. Which one would be better for me to use? How different is the build process at this time from what is was a few years ago? Where is the best resource on the FlightGear web site for me to refer to for building FlightGear on Windows? Last time I tried (some time earlier this year) OSG wouldn't compile under Cygwin due to compiler version incompatibilities. I was forced to change to MSVC8, and haven't regretted it - the necessary project files for FG are supplied in cvs (although they aren't always up to date), and MSVC8 has a nice editor for xml and C++ (works quite well for Nasal too). Running FG under Cygwin has a performance penalty. On the other hand Cygwin is still needed for terrasync, and I have not found a method of applying patches under Windows, not that I've looked very hard - Cygwin does just fine. HTH Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] wxradar bug fix and added feature
Melchior FRANZ wrote
Subject: Re: [Flightgear-devel] [PATCH] wxradar bug fix and
added feature
* Csaba Halász -- Sunday 09 December 2007:
Any ideas? Should we put in a comma-separated list of
symbolic names?
Not comma, but yes, I think that's the best thing. There
should IMHO already be a name/number list in AIBase.hxx. Then
the property could do what we do with logging classes:
/sim/logging/classes {STRING} = terrain|astro|flight|input|gl[...]
Of course, these names can also change between releases, but
they are at least readable and consistent in all of fgfs. The
question is, should there be shared flags, as in:
{ ship, 0x0001, }
{ aircraft, 0x0002, }
{ seaplane, 0x0003, } // ship and aircraft?
{ carrier, 0x0005, }
I wouldn't mind committing your patch as a temporary
solution, if you want to make sure that the functionality is
in the release. But I think this should be fixed in the long run.
I'm not cleat what type of radar we are modelling that can distinguish
between ships and carriers or seaplanes and aircraft, or even want to. There
are radars which can distinguish between carrier/ships and
seaplanes/aircraft. Mind you I have spent even less time than anyone
thinking about this. So far.
Vivian
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Google Earth scenery
AnMaster wrote Sent: 09 December 2007 21:21 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Google Earth scenery -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Gijs de Rooy wrote: Hi, I know there was/is a discussion about using real photo's as FlightGear textures. Google Earth was one of the softwares that are usable for our scenery. We know the pictures are copyrighted, but we may use them in FlightGear because: - FlightGear is non commercial software (non paid). And when we read this Google-quote we got the idea we may use the pics... You can personally use an image from the application (for example on your website, on a blog or in a word document) as long as you preserve the copyrights and attributions including the Google logo attribution. However, you cannot sell these to others, provide them as part of a service, or use them in a commercial product such as a book or TV show without first getting a rights clearance from Google. As you can sell GPL software (for example sell CDs with it on) google's license would not be GPL compatible I belive. But I'm not a lawyer. My English is not perfect so I may read these sentences on a wrong way. Please tell me if so. After all we just need someone who write Google to ask permission. Here's the aplication form: http://services.google.com/permissions/application :) We have already asked permission, altough soemtime ago now, and were refused. Regards Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
AnMaster Sent: 08 December 2007 14:02 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] multiplayer generic properties -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Vivian Meazza wrote: Anders has a really neat bit-mask utility which allows the transmission of up to 32 bools in one int property - much neater for light switches and the like. Vivian P.S. - by tradition we bottom-post on the devel list However for those aircrafts that I considered for lights they were not on/off but had birghtness setting too, check the A-10 and A-6E for example. Even better - for that there's nice slow signal interface using TDM - needs a pair of properties, preferably int. Panel light, nav lights, etc etc. In theory unlimited, but about 8 is practical. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer generic properties
AnMaster Sent: 08 December 2007 11:55 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] multiplayer generic properties -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Yes, I already made a patch (see [Flightgear-devel] Patch for Harrier: making it's thrust vector work over mp) for the harrier that makes use of this :) And I can think of several other aircrafts that could make use of this. For example position lights/anti-collision lights of some aircrafts. Would make formation flying in the dark over mp simpler. Regards, Arvid Norlander Melchior FRANZ wrote: After Maik has clued me up about multiplayer properties -- that only those are transmitted, which actually exist at init time (which is why they need to be defined in the *-set.xml file), it was time to add some generic properties for internal communication. That is: properties which aren't dedicated to a particular function, but can be used by an aircraft to send data to its mirror instances over MP. There are for now: /sim/multiplay/generic/string[0-9] /sim/multiplay/generic/float[0-9] /sim/multiplay/generic/int[0-9] Of course, this should be used sparingly. If you need to transmit a path, don't transmit the full path, but only the parts that are really necessary. For example, the bo105 will only transmit foo, when it actually means Aircraft/bo105/Models/Variants/foo.xml. The prefix and the .xml postfix will be stripped. There's still the possibility to transmit ../../foo if for some reason I want to refer to a file elsewhere. (I didn't add double/long/bool, as they would be transmitted as float/int/int, anyway.) In one of the next protocol revisions, we won't have to transmit these single-shot properties in every package (, I hope :-). m. Anders has a really neat bit-mask utility which allows the transmission of up to 32 bools in one int property - much neater for light switches and the like. Vivian P.S. - by tradition we bottom-post on the devel list - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Chat Menu and fix for chat repetition bug
Stuart Buchanan Sent: 05 December 2007 08:19 To: FlightGear Dev Subject: [Flightgear-devel] Chat Menu and fix for chat repetition bug Hi All, The latest and greatest chat menu system is now available. I have added a couple of new features and fixed a number of bugs: - The chat menu automagically creates messages that include the nearest airport, the current runway in use (based on the current weather conditions), and information about your aircraft and location. For example Half Moon Bay Traffic, G-FGFS is type Cessna, inbound from the south-west at 4,000ft, straight in approach runway 30, 4 miles to run. - The chat repetition bug should now be completely fixed (though I have only seen it twice, so I can't be 100% certain). - Going backwards and forwards through the message tree is now more reliable. The patch consists of a number of files (from http://www.nanjika.co.uk/flightgear/chatmenu.tar.gz): - multiplayer.nas: a complete replacement for Nasal/multiplayer.nas - chat-menu.xml: a new dialog to be placed under gui/dialogs - chat-menu-entries: an XML file defining the various chat messages, based on CAP-143 (UK standard radio phraseology). To be placed under ATC/ The patch also changes a small number of other files, for which diffs are included below. As Melchior doesn't spend much time using Multiplayer, he has asked that I post to the list, so someone with more MP experience can review and commit it to CVS. I think this is a big improvement over the current broken chat implementation and improves the MP experience significantly. I'd therefore ideally like it to be included in the release. As the patch is non-trivial, I'd appreciate it if it could be committed so that plenty of people can have the chance to try it out before the release. Thanks -Stuart Index: preferences.xml === RCS file: /var/cvs/FlightGear-0.9/data/preferences.xml,v retrieving revision 1.256 diff -u -r1.256 preferences.xml --- preferences.xml 4 Dec 2007 13:12:15 - 1.256 +++ preferences.xml 5 Dec 2007 07:58:48 - @@ -472,6 +472,7 @@ chat type=stringHello/chat transmission-freq-hz type=string11850/transmission-freq-hz chat-display type=bool userarchive=ytrue/chat-display + chat-menu include=ATC/chat-menu-entries.xml/ /multiplay user Index: menubar.xml === RCS file: /var/cvs/FlightGear-0.9/data/gui/menubar.xml,v retrieving revision 1.68 diff -u -r1.68 menubar.xml --- menubar.xml 4 Dec 2007 10:51:45 - 1.68 +++ menubar.xml 5 Dec 2007 07:57:44 - @@ -162,6 +162,14 @@ /binding /item + item + labelChat Menu/label + binding +commanddialog-show/command +dialog-namechat-menu/dialog-name + /binding + /item + /menu menu Index: keyboard.xml === RCS file: /var/cvs/FlightGear-0.9/data/keyboard.xml,v retrieving revision 1.103 diff -u -r1.103 keyboard.xml --- keyboard.xml 26 Nov 2007 17:55:28 - 1.103 +++ keyboard.xml 1 Dec 2007 10:08:51 - @@ -352,7 +352,17 @@ /mod-up /key - key n=46 + key n=45 +name-/name +repeatable type=boolfalse/repeatable +descCompose Chat/desc +binding + commanddialog-show/command + dialog-namechat-menu/dialog-name +/binding + /key + + key n=46 name./name descRight brake/desc binding @@ -773,6 +783,16 @@ /mod-up /key + key n=95 +name_/name +repeatable type=boolfalse/repeatable +descCompose Chat/desc +binding + commandnasal/command + scriptmultiplayer.compose_message()/script +/binding + /key + key n=97 namea/name descIncrease speed-up./desc I've tested this all with Start, and after some changes and bug fixes it is now in cvs-head. Unfortunately, my cvs client has crashed, and I can't backport it to plib until tomorrow. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Downloading and Quality
Err ... there's a 2D exterior? And a 3D cockpit is not necessarily better than a 2D. 2D is less demanding on frame rate, and can be just as effective as a 3D cockpit. And some of those are by no means brilliant. Horses for courses. Our most detailed ac need high end computers to run on, with good graphics cards. Not everyone has such a machine, and we have to have regard for them. Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gijs de Rooy Sent: 07 December 2007 14:30 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aircraft Downloading and Quality Nice idea! Why not add a system like: 5 stars for a very complete aircraft like the Senecca II or one for the not so goog like the fokker 70/100? So everyone can see, where is potential to develop?! Regards HHS --- Hans Fugal [EMAIL PROTECTED] schrieb: We could give a star for every single part of the development stadia. One start for the 3D Cockpit, one star for the Painting, One star for the 3D Model, One star for the flying performances etc. So if a plane has a 3D Cockpit and an 3d exterior model it gets 2 start by example. PS: If this is added, we may add also something wich let users rate the aircraft? _ Windows Live Messenger het beste van de toekomst Download NU! Windows Live Messenger! http://imagine-msn.com/messenger/launch80/default.aspx?locale=nl-nlsource= joinmsncom/messenger - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft Downloading and Quality
Gerard robin wrote Sent: 07 December 2007 15:44 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Aircraft Downloading and Quality On ven 7 décembre 2007, Heiko Schulz wrote: Yes we must not talk about artistic competences (here the msfs models are better :( ), only to answer the question: does the model simulate the real one ?which degree of simulation ? Right I think- eye candies are only one small part of being realistic, but if we want to be serious, we should attend this. Problem: how should we find out how realistic a aircraft is? Not all aircrafts here are based on save datas or have a real pilot as developer?! Regards HHS An answer only for fun: Yes the f16 is based on save data ( partly yes , however, it is ) Sorry, run that hog by me again - what is save data? Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Georg Vollnhals Sent: 07 December 2007 16:10 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear prerelease ... Snip ... 2. Aircraft shows up under a carrier on reset This happens when I reset FlightGear (Shift-ESC) on Nimitz. This is a bug which we never got around to fixing, so I guess we should call it a feature now. Vivian - SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft selection summary
Durk Talsma wrote: Sent: 06 December 2007 08:31 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Aircraft selection summary I wasn't able to jump in yesterday, but I've been following the aircraft selection disscussion closely. Below is a first attempt at compiling a new list based on the various suggestion made by everybody, and weighted by me based on my general impression of consensus. 737-300 - 787 I think Jon Berndt suggested keeping the 737, but a few people suggested replacing it by the 787, which seems to be our most complete jetliner. I like to follow that suggestion. A-10 As far as I can see, nobody suggested replacing this aircraft. So I guess we keep it. bf109 - A6M2 (Zero) Suggested by Melchior, for ease of operations use. I think this is a good point. The release will be the first FlightGear hands-on experience for many people and we want to make sure that that first experience is as positive as possible by providing aircraft that have reasonably easy handling characteristics. Not including the bf109 for that reason is by no means a quality judgment of the aircraft itself. bo105 c172 c172p Everybody seems to agree we keep these ones. c310 - SenecaII c310u3a - Beaver I haven't been able to check whether the c310 and c310u3a are really two separate aircraft, or just two different directories with shared components. Anyhow, we unanimously agree that the c310 should be replaced by the Seneca. The suggested replacement above seems to satisfy a few additional requests to have the Beaver included as well. Citation-Bravo - B1900D This seems a reasonable replacement, in particular since the author of the Citation has indicated preferring that is is not part of the base aircraft selection. One minor concern is the ease-of-use issue. IIRC, the B1900D is fired up in cold configuration, and has quite a complicated start-up procedure (things may have changed since I last checked). Complex procedures like these may intimidate first time users. f16 - Lightning Melchior reported that the f16 is broken. I haven't been able to test recently, but seem to recall similar problems about a year ago. Jon Berndt reported finding a possible cause, so chances are the reported problems might get fixed in time. Still, I would like to replace the F16 for other reasons: We need at least an AAR ready aircraft in the base package, and a carrier ready aircraft (these are two very prominent new AI features in this release that we want to showcase). So, how about replacing the f16 with the Ligntning (for AAR scenarios)? j3cub A few people have a suggested dropping the cub, but given its various qualities, I'd like to keep it. Hunter - SeaHawk As a few people suggested, we probably need a carrier ready aircraft, and the seahawk is advertised by the wiki carrier HOWTO as the easiest to master (and I can confirm that its doable. :-) ). p51d - () We already have one other WWII fighter. Do we really want to have two, or do we want to have some other category of aircraft represented? pa28-161 - pa24-250 A few people have suggested replacing the pa28-161 with the pa24-250. I haven't tried any of those recently, but would be open to the suggestion. Rascal - Bochian (or another glider) Many people have suggested dropping the Rascal, for being too specific, and suggested we add a glider. T38 - Concorde () Even though the T38 is probably a category of its own, my general impression is that the broader class this aircraft belongs to (let's say: small high-powered jet powered and highy manouvreable) is a bit overrepresented (with the A10, [f16/lightning], and [Hunter/SeaHawk] being present. Gerard Robin suggested adding the concorde, and there are some aspects of this proposal I like, asit is an altogether different category. However, when trying the condorde yesterday, I saw some performance issues (need to check again), and also found the 3D cockpit instruments to be a bit cartoonesque. This is probably a good candidate for future inclusion, but not quite there yet. ufo Keep as a general exploration tool. Its fun as such. I think everybody agrees. :-) wrightFlyer1903 - Osprey/ DragonFly/maybe another historic aircraft. Most people suggested dropping the wright flyer. A few people suggested adding an ultralight. it would be nice to have a historic aircraft (as in a really old one). During the version number discussion, somebody suggested doing named releases. We could do this implicitly, by changing our choice of historic aircraft from release to release. So 0.9.10 would have
Re: [Flightgear-devel] patch to use OpenSceneGraph database pager
Tim Moore Sent: 04 December 2007 23:01 To: FlightGear developers discussions Subject: [Flightgear-devel] patch to use OpenSceneGraph database pager -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, http://www.bricoworks.com/moore/0001-OSG-pager-megapatch.patch is a patch against current flightgear that uses the OSG database pager to load scenery tiles instead of the old tile loader. The main advantage of the database pager is that it schedules texture loading and display list compilation in a way that doesn't hammer the frame rate. Currently we don't do anything at all about compiling OpenGL resources, so you can get terrible stutter the first time you look at parts of a scene. With this patch, that's gone. Also, old tiles are deleted in the database pager thread, eliminating another potential cause of stutter. This will be checked into CVS soon, but I've been hesitating for three reasons: * It breaks the GLUT version; * Some bugs turned up with multiplayer play. I think I've fixed these, but some more testing would be good; * Without patches to OSG that have been submitted to osg-submissions, startup time is noticeably longer. Nevertheless, the patch is quite usable with OSG 2.2. Give it a try if you're feeling adventurous. I've been running with this patch for a while now with OSG 2.2. The load time isn't too excessive. It provides enhanced smoothness, but the stutters around KSFO are still apparent here. Overall, the advantages outweigh the small disadvantge of increased laoding time. I certianly won't be reverting the patch, and look forward to it being in cvs, and osg taking the changes aboard. Vivian - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Control surface position damping
Maik Sent: 02 December 2007 13:49 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] RFC: Control surface position damping Hi Roy, Roy Vegard Ovesen schrieb am 02.12.2007 14:13: When prssing the 5 key on the numeric keypad to reset the controls to zero, the control surfaces instantly move to their origin. Similar effects can also happen when an autopilot controller is activated, and when a noisy joystick is interfering with an autopilot controller. I think moving a control surface, like for example the rudder, from full left deflection to rull right deflection in an instant is unrealistic. To make this more realistic I think we should put in a low pass filter somewhere in the chain from crontrol device to FDM. My first thought would be to do the filtering just befir handing the value over to the FDM. Does anyone on the list have comments on this? With YASim you can limit the speed of any control surface, mostly used for flaps. I use it for all control surfaces where appropriate to simulate servo response time. I would not like key 5 to muck about with this in some pre-cooked and inappropriate way. Key 5 should be just centre the controls - that and no more. If individual aircraft designers want to modulate it in some way, that's down to them. This is a bad idea. Vivian - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear-devel Digest, Vol 19, Issue 25
LeeE wrote Sent: 30 November 2007 00:13 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Flightgear-devel Digest, Vol 19, Issue 25 On Thursday 29 November 2007 21:55, Melchior FRANZ wrote: Hey, * BARANGER Emmanuel -- Thursday 29 November 2007: Also, file names with spaces in them are garbage. There should be none of those in CVS. AAAHHHRRGGG ! The suprises CVS files which do not for the drive :( I erased now. Sorry. No problem. Not a big one, anyway. I'm happy about every new, great aircraft. (Especially the AlouetteII -- we've had some of them in our army, too, -- or the BV141). It's only natural that we use more disk space with every new one, but we have to make sure that we don't just waste it. Compressing textures is one thing to consider, not committing unnecessary files is another, such as *.bak, *.blend, *~ files. Or a few of those: :-} $ l SeaHawk* Models/SeaHawk-FGA6-WV859.ac -rw-r--r-- 1 m m 1453387 2007-09-28 01:18 Models/SeaHawk-FGA6-WV859.ac -rw--- 1 m m 707301 2003-04-21 22:29 Models/SeaHawk-WV908.ac -rw--- 1 m m 113282 2003-01-03 17:58 Models/SeaHawk.3ds -rw--- 1 m m 715739 2003-02-14 16:29 Models/SeaHawk.ac -rw--- 1 m m 226548 2003-01-09 16:04 Models/SeaHawkpair.3ds m. I'm pretty sure that the SeaHawk.ac, SeaHawk.3ds SeaHawkpair.3ds can be done away with right now. I think Vivian is doing all his development on WV859 and I'd like to keep WV908, if only as a placeholder and reminder, as it's the RNHF aircraft - afaik it's currently the only flying example. At some point I'd like to refine the 3d model geometry and then unify the two versions (perhaps it will only need different skins), incorporating all the development that Vivian has done... ...or Vivian might decide to do it before I do :) Ok with you Vivian? Yes, we must have WV908, but I don't think we would want to retain more then the textures for that longer term: doing an alternate livery is on my todo list. Otherwise the rest is all your stuff, and if you are content to have it removed, I'll do that. Your call. Hmm Mathias wanted to do a wingman using AI techniques ages ago, and it's always in the back of my mind. One of these days ... Vivian - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Informal version number poll
I think that the juxtaposition of 9.11 and Flight Simulator would be unfortunate, to say the least. I'm not sure how strongly I feel about that personally, but I recognise that there are those, particularly the other side of the pond, who do or might. Why give gratuitous and unnecessary offence? On the other hand Version 1.0. But we have OSG waiting in the wings, don;t we?. This is just a temporary release isn't it? perhaps 9.12 or something would be more appropriate. Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf OfOlson Sent: 30 November 2007 15:29 To: FlightGear developers discussions Subject: [Flightgear-devel] Informal version number poll How about a quick, friendly, positive, informal thread here to do a poll on what what folks are thinking for the next version number. I don't intend to slant the discussion, but here is what I'm thinking. 0.9.11 is the next in the logical sequence. But I'd like to avoid possible unintended connections that end users might interpret from such a version number. This has nothing to do with terrorism, they don't care what version numbers we use or don't use. There is no fear involved in wanting to avoid using this number. Try respect. It might have something to do with showing respect to those that were affected by 9/11 and those many heros that gave up their lives without hesitation to try to save the lives of others. I don't fault people who live outside of the USA or who have never been to New York or were never near ground zero for not getting it, there's an awful lot of stuff outside my little sphere of vision that I will never understand. But give me a break, what's the problem with yielding a small amount of leeway and respect to those that were affected by 9/11 or had connections there? We could skip over to 0.9.12, but then we are staring in the face of 0.9.13 and are we going to run into problems if we pick a version # 13? I wore number 13 in my soccer (err futbol) game the other evening and missed all my shots. I wore a different number last night and scored two goals. These facts cannot be ignored! We could go with 0.10.0, but then all the odd/even version number proponents are going to come out of the woodwork, and that is going to mire in it's own set of politics. We could go with v1.0 ... we've been at this 10 years, and averaging 0.1 versions a year isn't so bad. This is my preference. FlightGear is developing at a rapid rate, but if we stick with 0.9.12, 0.9.13, 0.9.14 it seems like we are bumping along with very minor increments every few (or many) months. Of course this all boils down to marketing. Who cares what the actual numbers are really, as long as they increment in a sensible way. But what image do we want to project to the world? Are we a bunch of old cranky developers (it looks that way sometimes!) :-) inching along at a snails pace, or are we a dynamic exciting group with fast paced development continually adding new and exciting features and aircraft? We've been at this 10 years, have we really only managed a 0.9.x release in all that time? Again, not that version number really mean anything, other than to project our image to the world. I say it's go time. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nimitz operation menu items
Hi Paul, I'm afraid I cannot add the items you ask for as they stand. The code only works with the existing Nimitz_demo.xml. If any other carrier demo is used, this carrier will be placed in the default Nimitz location by the use of this dialog. A dialog must be generally applicable, not apply to just one situation, and must most definitely not break anything. The idea is sound, and I encourage you to work the code up into something that works properly. Regards, Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bohnert Paul Sent: 22 November 2007 03:54 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nimitz operation menu items Hi All, For now please add the two items I asked for. I'll work on a new and improved stand alone carrier menu. It might take some time. I'm learning as I go. Best Regards, Paul B gerard robin [EMAIL PROTECTED] wrote: On mer 21 novembre 2007, Mike Schuh wrote: On Wed, 21 Nov 2007, Stuart Buchanan wrote: 1) I think splitting the dialog into two - one for AI/ATC and one for carrier settings would be a good idea. From the user's perspective, they are really two separate functions and there are now sufficient carrier functions to make this worthwhile. I agree. It might also be worth including buttons for engaging the launchbar, and even firing the catapult. I think it would be valuable to add a configurable time delay to the firing of the catapult. This would allow the user to click fire, close/dismiss the dialog window/box, and prepare to fly the plane. The default could be, say, 5 seconds, and there could be a separate dialog window/box that shows the time remaining before the catapult is fired (this separate dialog would automagically disappear when done). I suppose there should be an option to not show this countdown timer (or rather, showing it requires checking a box in the carrier dialog). Yes, you are right, for instance, I did include some delay (with a nasal script) , mainly to get a nice animation within my Air Navy Aircrafts, unfortunately up today it is only a private use ( you cannot get profit of it since these models can fly only with a specific carrier patched JSBsim FDM, .. old sad history ). However, the keys are necessary, to activate these features 2) The dialog currently is very specific to the Nimitz and its current location. I think it would be a good idea to instead provide controls for any number of carriers... I agree. Regards, -- Gérard http://pagesperso-orange.fr/GRTux/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try http://us.rd.yahoo.com/evt=51731/*http://mobile.yahoo.com/sports;_ylt=At9_q DKvtAbMuh1G1SQtBI7ntAcJ it now. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
Stuart wrote Sent: 28 November 2007 10:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Keyboard reorg Hi All, I've added the key assignments currently defined in keyboard.xml to the wiki page, so that we can easily see what assignments people think are missing, and any inconsistencies: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Key board_function_priority_list Note that this only lists the key assignments for the functions that people have added to the wiki. It doesn't list all the current key assignments so shouldn't be used to work out which keys are available :) I think it might be worth making a couple of small changes for the 0.9.11 release to make the key assignments more consistent, and to define which blocks of keys we want to reserve for aircraft designers, and which we will reserver for user's own custom assignments. That way we have a strategy going forwards, and designers of new aircraft will have some confidence that they will not be treading on other peoples toes. From looking at the list, one thing that looks worth resolving are the speedbrakes, spoilers and slats assignments. The current key assignment for Speedbrakes assumes that the brakes are on/off, and at least in the case of the Vulcan, they have multiple positions. I don't fly big iron much, but I'd guess that slats can similarly have multiple positions. Anyone care to comment? A similar situation to the Buccaneer - I retained ctrl B to toggle the airbrake (aka speedbrake) but also use j/k to step the airbrake through predefined detents. Luckily, it doesn't have spoilers as well. The A4F does, so that option wasn't available, so I stuck with the default keys. Hmm - the A4F has an automatic deployment option for the spoilers - must do that sometime. But how will I do the wing/flap/aileron blowing system? Haven't even thought about that yet. It might be worth adding a new list to the wiki page of the current functions for which there is a keyboard assignment we no-longer need. For example, the time warp and simulation rate key assignments which we will no-longer need once someone commits my Time of Day dialog changes ;) I've already re-used t/T for the auto-trim facility in the Buccaneer - but there's no reason to make that a permanent or default assignment Vivian - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nimitz operation menu items
Stuart Sent: 21 November 2007 10:11 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Nimitz operation menu items Bohnert Paul wrote I propose adding two items to the ATC/AI Options menu. The first one will enable users to set the speed of carrier Nimitz. The second will set Nimitz speed to 0 and place it at the it's start up location. This will allow MP players to place Nimitz at the same location without editing configuration files. Hi Paul, Providing an easy way to make the Nimitz more MP-compatible is an excellent idea. However, I have two comments on the implementation: 1) I think splitting the dialog into two - one for AI/ATC and one for carrier settings would be a good idea. From the user's perspective, they are really two separate functions and there are now sufficient carrier functions to make this worthwhile. It might also be worth including buttons for engaging the launchbar, and even firing the catapult. This will also allow us to hide the carrier menu if the carriers are not enabled. 2) The dialog currently is very specific to the Nimitz and its current location. I think it would be a good idea to instead provide controls for any number of carriers, or at least controls that will reset _all_ carriers to their default position. This may require a bit of re-jigging of the carrier scenarios so that their initial positions etc are accessible, but will give a lot more flexibility as the number of carriers increase. I realize that this has just trebled the workload for your enhancement, but I think that both these things will make it much more useful. Best regards, -Stuart As an ergonomic issue here - I would prefer not to try to juggle with mouse and joystick to either engage the launchbar or fire the catapult - the keyboard is a better option. I know there are some who can manage that, but I'm not one of them. Otherwise, this is all good stuff, and as the co-author of the original carrier stuff would be very willing to add the final version to cvs. Only temporarily, mind. We have been talking about doing the carrier (and other ai objects) over mp for years now. Perhaps some time soon ... Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/Buccaneerbuccaneer-obs-set.xml, 1.2, 1.3 buccaneer-set.xml, 1.23, 1.24
Melchior Sent: 19 November 2007 21:55 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] CVS: data/Aircraft/Buccaneerbuccaneer-obs-set.xml, 1.2, 1.3 buccaneer-set.xml, 1.23, 1.24 * Vivian Meazza -- Monday 19 November 2007: Log Message: Modify Buccaneer Observer to comply with Melchior's latest diktat Anyone else unhappy with my fgfs performance? Just say it! I've stated at least four times that views 0 to 99 are reserved for the system, that is: are to be avoided by aircraft files. I have explained why. I've asked three people, to *please* comply with this rule. Everyone did. Except one who doesn't think he has to play by the rules. This pisses me off, and I hereby stop working in this area. Just pulling your leg, Melchior. It's been hard enough getting Anders' stuff to work without changing View numbers, and I was waiting to see which way was best before doing nugatory work. And it's now all done. I think what you have done so far is very nice. Sorry you were offended, and no Latin I promise :-) Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default glider model
John Wojnaroski Sent: 18 November 2007 16:15 To: FlightGear developers discussions Subject: [Flightgear-devel] Default glider model Hi, Running OSG-2.2 and FG cvs... After turning off all the models, panels, views, etc, I'm left with the default yellow-green glider model in the scene. Does one have to set the view or eyepoint in front of the model to make it disappear or is there a more correct way to eliminate the aircraft model from the scene graph? Regards John W. I don't know exactly what you are trying to do, but if you use this in your -set.xml file you will get no model, and no yellow/BLUE glider model pathModels/Geometry/null.ac/path /model Not sure how you get rid of yellow/green ones Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Keyboard reorg
AJ MacLeod wrote Sent: 12 November 2007 12:09 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Keyboard reorg On Monday 12 November 2007 06:31:26 John Denker wrote: Agreed! I've thought for ages that a top-to-bottom reorg would be helpful. The starting point for me was the realization that there are far more aircraft functions that need to be controlled than there are keys on the keyboard Which is why we have cockpit hotspots. The simple fact of the matter is this; we model a vast array of aircraft, of almost every type imaginable. We are modelling them in an ever more detailed way, and each aircraft really is very different; far too different to provide enough key bindings to make each aircraft controllable by the keyboard alone. For those who never fly or model anything other than single engine light training type fixed-wing aircraft, perhaps the problem isn't so noticeable; these are comparatively simple and probably have a reasonable degree of commonality of functions between aircraft. There are, IMHO, very few functions indeed which really _require_ a keyboard binding by default. Why try and squeeze every aircraft type and function into one cramped mould? In situations such as this, the time-honored solution is to come up with a _language_. A good language has *) some orthogonality, and *) some mnemonic value. And will be detested (indeed, completely shunned) by the average user. While I can see your point, and some possible advantages with your idea, it's a complete non-starter from the point of view of the non-programmer normal user. Maybe most of us on this list find it natural to think in such terms, but I can assure you (from dealing with typical users every day) that most people don't. I would add that the current assignments have evolved over the best part of a decade, and are the results of a degree of consensus. It is likely that any review will: A. Only tinker round the edges. B. Be different rather than better, and quite likely worse. Consensus is unlikely, other than more or less around what we have already. Any major change would require our users (and developers) to unlearn the old and relearn the new. Unlikely to win many friends. Evolution is usually better than revolution. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml, 1.99, 1.100
gerard robin Sent: 11 November 2007 13:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml,1.99, 1.100 On sam 10 novembre 2007, Vivian Meazza wrote: gerard robin Sent: 10 November 2007 18:37 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml,1.99, 1.100 wonder if it would not have been better to find a global agreement on which key can do what, before to make that update. There is some aircraft within CVS which are carrier compatible. With that update the launchbar will not work now. Should be OK, the carrier bindings will over-write the keyboard bindings. It will be a problem if there is an aircraft with both tail wheel lock _and_ carrier launch bar (F4U?) I haven't checked that. And perhaps we can come up with a long term solution. I'm sure Melchior's little grey cells are working overtime. Still, perhaps we shouldn't be making changes until we are clearer about the consequences. Vivian I did not check it , but your Seafire has both Launchbar and tailwheel lock, What is the matter now with the keyboard updated ? Regard Not really, later on in the YASim config, it's ignored. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor keyboard reassignment
Gerard robin wrote Sent: 10 November 2007 09:29 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Minor keyboard reassignment On sam 10 novembre 2007, Melchior FRANZ wrote: * Melchior FRANZ -- Saturday 10 November 2007: L is used to engage in the aircraft carrier's catapult (see $FG_ROOT/Input/Keyboard/carrier-bindings.xml). So around 10 aircraft will overwrite the new lighting binding anyway. err ... the tailwheel lock binding. (I didn't even know that it was there. I have that on my js.) We have still several keys globally unassigned, but it's increasingly hard to find one that isn't used by at least one aircraft. In the long run we'll have to reorganize a bit. We waste a lot of keys for obscure features that a typical simulator user will never need and/or that are too easy to press by accident (a/A, t/T, r, ...). The carrier bindings could IMHO be in a small popup dialog (like the ATC dialog). They aren't for controlling the aircraft after all, but to give orders to the carrier crew. m. Anyhow, I am not sure it would be a good idea to use the reserved carrier KEYS. There is only a the little number of persons who use and like the carriers, which is not the majority of the FG community :(, so i can understand that many persons don't mind about carrier, and i worry it. The L is very useful , i mean a key on the keyboard (not a like ATC dialog). Please keep it. And I don't think a dialog would be a good way to fire the catapult. Regards Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Minor keyboard reassignment
Melchior FRANZ Sent: 10 November 2007 10:00 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Minor keyboard reassignment * Vivian Meazza -- Saturday 10 November 2007: Gerard robin wrote There is only a the little number of persons who use and like the carriers, I'm not even sure about that. It's one of the frequently asked questions, and it seems as if everyone of the IRC regulars uses the carrier once in a while. I do pretty often. The L is very useful , i mean a key on the keyboard (not a like ATC dialog). And I don't think a dialog would be a good way to fire the catapult. Hmm ... ok. I'm just not sure if having two separate keys is a good thing. Maybe we should standardize on c ... toggle canopy C ... engage disengage (toggle) catapult \__c as in carrier Ctrl-c ... launch catapult / control the crew :-) l ... lights (though most are operated via 3D cockpit switches!) L ... tail wheel lock Ctrl-l ... liveries (l for liveries is a bit exaggerated, anyway) Sounds reasonable to me. V. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml, 1.99, 1.100
gerard robin Sent: 10 November 2007 18:37 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data keyboard.xml,1.99, 1.100 On sam 10 novembre 2007, David Megginson wrote: On 10/11/2007, gerard robin [EMAIL PROTECTED] wrote: I can notice the update has been done , before we could give any opinion on the topic. Does it mean , that there is not any other alternative, and the CHOICE is that way nothing else :) :) :) From my original message: quote I just moved tailwheel-lock from lowercase 'l' to uppercase 'L', and reassigned lowercase 'l' to toggle lighting (for easy night starts without searching for switches). I assigned lighting to the lowercase 'l' because I think it would be much more commonly used than tailwheel lock, but if there are general objections (from DC-3 users?) I can swap the two around so that tailwheel lock goes back to 'l'. Let me know what you think. /quote I or anyone else with access can change it again once there's a consensus -- remember that CVS is the experimentation branch, not the release branch. All the best, David Oh, i am only like the dog which try to catch his tail. Since we had the 'L used with carrier , (this was talked before), i only wonder if it would not have been better to find a global agreement on which key can do what, before to make that update. There is some aircraft within CVS which are carrier compatible. With that update the launchbar will not work now. Should be OK, the carrier bindings will over-write the keyboard bindings. It will be a problem if there is an aircraft with both tail wheel lock _and_ carrier launch bar (F4U?) I haven't checked that. And perhaps we can come up with a long term solution. I'm sure Melchior's little grey cells are working overtime. Still, perhaps we shouldn't be making changes until we are clearer about the consequences. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [ANN] - Buccaneer - Back seat ride
Hi, Tonight we carried out our first ride in the backseat of a Buccaneer over MP, thanks to some excellent recent work by Melchior and Anders. AJ was the intrepid Observer/passenger, and reported himself well pleased with the experience. To try it you need the Pilot and Observer on MP in the Buccaneer, and then the Observer selects the Model Cockpit View (V/v), then cycles through the cockpit views (Q/q) until he reaches the back seat of the Buccaneer. That's it - the Pilot can then fly with his Observer aboard. Sick bag might be necessary :-). Only available in cvs, of course, and there's much work to be done to both generalise this to all mp aircraft, and to provide the appropriate facilities and connectivity in the backseat so that the Observer can be more than just a passenger. AJ was navigating using the MPMap, so that's a start. Anders is hard at work extending this into a co-pilot facility - watch this space. Meanwhile - if you are on MP we're aboard and watching you :-). Regards Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] - Buccaneer - Back seat ride
I wrote: -Original Message- From: Vivian Meazza [mailto:[EMAIL PROTECTED] Sent: 10 November 2007 23:20 To: 'FlightGear developers discussions' Subject: [ANN] - Buccaneer - Back seat ride Hi, Tonight we carried out our first ride in the backseat of a Buccaneer over MP, thanks to some excellent recent work by Melchior and Anders. AJ was the intrepid Observer/passenger, and reported himself well pleased with the experience. To try it you need the Pilot and Observer on MP in the Buccaneer, and then the Observer selects the Model Cockpit View (V/v), then cycles through the cockpit views (Q/q) until he reaches the back seat of the Buccaneer. That's it - the Pilot can then fly with his Observer aboard. Sick bag might be necessary :-). Only available in cvs, of course, and there's much work to be done to both generalise this to all mp aircraft, and to provide the appropriate facilities and connectivity in the backseat so that the Observer can be more than just a passenger. AJ was navigating using the MPMap, so that's a start. Anders is hard at work extending this into a co-pilot facility - watch this space. Meanwhile - if you are on MP we're aboard and watching you :-). Regards Vivian P.S. Clipping plane problems mean that this only works properly in OSG. We can probably fix it quite quickly in plib, but haven't thought through the consequences yet. V. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view handling news
Melchior wrote Sent: 07 November 2007 23:14 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] view handling news Since David complained about the damping mechanism in viewer.cxx, I wanted to check whether the same feature could also be done in Nasal. (Damping is at the moment only used in the Chase View. It's just lowpass filters on the heading/pitch/roll angles, which make the viewer follow the aircraft with a slight delay.) I had to fix a jitter problem in the main loop, and there's one more to fix for replay (already done on my HD), but most of the work is done. There's now a manager in $FG_ROOT/Nasal/view.nas where one can register Nasal view handlers. This is by default only done for the Fly-By-View. Here are two more examples. Each of them is an XML file with some settings and embedded Nasal code, and implements a new view. You can try them out at once: $ fgfs --aircraft=j3cub ~/chase-view-II.xml ~/model-view.xml Use full paths for the files. (~ expands to a full path :-) chase-view-II.xml is a proof of concept. It's a slightly extended chase view, where also latitude/longitude/altitude are lowpass filtered. This is nice to see how far an aircraft drops in a barrel roll. Might also be nice for movies. model-view.xml allows to cycle through all carriers, tankers, aircraft, multiplayer (untested) with the q/Q keys. The jitter in plib has pretty well been fixed here by these modifications. There remains some low frequency and relatively long pauses around KSFO and other texture/model rich environments. The sound bug has been fixed. The model-view with multiplayer has been tested here and works very well. This facility is a very nice add-on to FG. Pity it wasn't available for the FSWeekend event in Lelystad, because it is particularly applicable to this kind of event. Well done Melchior Regards Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view handling news
I wrote: Sent: 08 November 2007 08:16 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] view handling news Melchior wrote Sent: 07 November 2007 23:14 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] view handling news Since David complained about the damping mechanism in viewer.cxx, I wanted to check whether the same feature could also be done in Nasal. (Damping is at the moment only used in the Chase View. It's just lowpass filters on the heading/pitch/roll angles, which make the viewer follow the aircraft with a slight delay.) I had to fix a jitter problem in the main loop, and there's one more to fix for replay (already done on my HD), but most of the work is done. There's now a manager in $FG_ROOT/Nasal/view.nas where one can register Nasal view handlers. This is by default only done for the Fly-By-View. Here are two more examples. Each of them is an XML file with some settings and embedded Nasal code, and implements a new view. You can try them out at once: $ fgfs --aircraft=j3cub ~/chase-view-II.xml ~/model-view.xml Use full paths for the files. (~ expands to a full path :-) chase-view-II.xml is a proof of concept. It's a slightly extended chase view, where also latitude/longitude/altitude are lowpass filtered. This is nice to see how far an aircraft drops in a barrel roll. Might also be nice for movies. model-view.xml allows to cycle through all carriers, tankers, aircraft, multiplayer (untested) with the q/Q keys. The jitter in plib has pretty well been fixed here by these modifications. There remains some low frequency and relatively long pauses around KSFO and other texture/model rich environments. The sound bug has been fixed. The model-view with multiplayer has been tested here and works very well. This facility is a very nice add-on to FG. Pity it wasn't available for the FSWeekend event in Lelystad, because it is particularly applicable to this kind of event. P.S. We get views like this: ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/Model-viewer.jpg V. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view handling news
Melchior Sent: 08 November 2007 11:48 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] view handling news * Vivian Meazza -- Thursday 08 November 2007: The model-view with multiplayer has been tested here and works very well. What doesn't work well yet is Nasal based chase view in replay mode (fixed on my disk), and model view in fg/osg (fixed on my disk). Replay is firmly off here (creates too much jitter - I can live without it), and I haven't tested the new chase view. FG/OSG is barely usable here, and the jitter fixes which work so well in pilb seem to have no effect on osg, but I haven't given it a fair test yet. Well done Melchior Thanks. That's just the beginning. Once the remaining jitter problems are solved the only limiting factor is our fantasy. ;-) Just a back-seat view would do me for starters - I can come up with more I expect. V. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [ANN] Buccaneer
Hi, I've just added a fuel dump facility to the Buccaneer. A screenshot is here: ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/bucc-fuel-jettison.jpg Looks nice? Don't be fooled: the particles are firmly tied to the aircraft. There is much work to be done to integrate particles into FG. Not least the right frame of reference, and the proper wind. Regards Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] compilation problems with MSVC 2005
Sergey Sent: 05 November 2007 15:38 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] compilation problems with MSVC 2005 Hello Georgi, you might want to replace your version of plib with that on my site in archive http://www.sim-ai.org/FlightGear0.9.11beta1completecode.zip from http://www.sim-ai.org/FlightGearlesson.htm the problem is in plib ac reader where wrong open file option is set. I don't think so ( the only difference with you - I used beta of vs2008 so you will need to keep your project files) On 11/5/07, Georgi Ivanov wrote: Hi I am trying to compile FlightGear 0.9.10 with Visual Studio 2005. However, in fg_os.c line 141 when the following code executes I get an error. Hmmm, no need for modified plib here with MSVC8. You do need the right version of Simgear though, and then make sure that your MSVC8 is configured correctly. Plib 1.8.4 works with 0.9.10. plib-cvs is better with 0.9.11. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d file formats and crease angles
Roberto Sent: 04 November 2007 09:55 Hi, I've been modeling for fgfs a few objects around the world. I'm used to output everything as .AC files since it looks to me it's the most used format in FGFS but that has a few limitations that I'd like not having. The one I'm concerned now is the crease angle limitation. AC3D makes me set a crease angle for an entire object and does not let me choose to set different crease angles to each surface inside the same object. That's why I have to break the object in pieces when I want some of it's surfaces to have different crease angles than others. That's a pain :-( I don't know if that's a limitation of the .ac file format or of AC3D editor. I wonder if you can suggest me a way to avoid this limitation in AC3D. I also think I could switch to other 3d file formats, any suggestions? What 3d file formats does FGFS support other than .AC? I'd prefer working with plain ascii files if possible but I will consider other more obscure ones if they provide more flexibility and fewer limitations. You are quite right AC3D has crease angle set on a per-object basis, and AFAIK, there is no way round this. I have not found it a limitation - it is a transition value between crease and smooth. Like you, if there isn't a convenient value I break the object. There's no penalty for that - numbers of objects and groups have no performance penalty. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing head lag
David Sent: 03 November 2007 02:25 To: FlightGear developers discussions Subject: [Flightgear-devel] Fixing head lag I think it's great that FlightGear added head lag to the sim -- it's a good alternative when the pilot can't feel forces -- but I think we'd do better to model it based on perceived forces, not on roll/yaw/pitch damping. For example, simply entering a coordinated bank gently shouldn't cause any head movement at all, but flying straight in a forward slip should, because there's a yaw force pulling the head slightly sideways. Likewise, while the pilot is perceiving 1G the head should move up a bit, and while the pilot is perceiving 1G, the head should move down a bit. Would anyone object to my checking in some changes over the next week or two to change this? We can always roll them back if they don't work. As Melchior said, the head-shake mechanism does indeed regard the head as a mass and a (damped) spring, but it's a bit more sophisticated than that - the resistance of the neck muscles are modelled as well. (The distance moved in various directions are measured from my own body strapped into a 4 point harness - YMMV). I think that aspect is quite well simulated. The original code was written by Josh Babcock, but the math was heavily modified by me. The code structure could do with review and revision. I keep on meaning to make this more sophisticated by stabilizing the eye viewpoint, but never got around to it. While theoretically necessary, I'm not absolutely sure that would improve the appearance of the simulation much. Regards, Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing head lag
David Sent: 03 November 2007 15:58 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Fixing head lag On 03/11/2007, Melchior FRANZ [EMAIL PROTECTED] wrote: I should do something similar for planes. Of course, this is still configurable per aircraft, too. Just not via properties, but by defining a Nasal handler. I'll review that. And again: I appreciate suggestions for improvements or patches. Just not commits to that nasal file. You don't know how picky I am! ;-) Now that I understand what it's for (and the fact that it's not enabled by default), I don't plan to touch it -- and as I mentioned, it is a cool idea. I would like to get some kind of force-based head lag working, through. As I said before, but perhaps you didn't notice, we already have a force based system working on the input of pilot g. It moves the pilot's eye position according to this input. And as Melchior pointed out, we probably need to stabilise the point at which the pilot looks to make this totally realistic. Try the Hunter to see it in action (together with black/redout). Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing head lag
David Sent: 03 November 2007 19:19 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Fixing head lag On 03/11/2007, Vivian Meazza [EMAIL PROTECTED] wrote: As I said before, but perhaps you didn't notice, we already have a force based system working on the input of pilot g. It moves the pilot's eye position according to this input. And as Melchior pointed out, we probably need to stabilise the point at which the pilot looks to make this totally realistic. Is there a way to enable it in general, without tying to a specific aircraft model? I'm afraid not - it's in all my models, but it has not been picked up as something we want as a generic feature. It's only a moderate number of Nasal lines of code. Wouldn't take much to do make it generic. I think would like to tidy up the code first, but ... Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] frame rates...
SydSandy Sent: 27 October 2007 01:08 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] frame rates... With a pending PLIB release come up Would now be a good to push for setting (again) ... sim frame-rate-throttle-hz30/frame-rate-throttle-hz /sim as default in the preference file ? I picked 30 because I argee that anyrhing over 30 is a waste ...unless bragging about computer speed, of course, :)... It makes autopilot behavior and tuning much easier (for me at least ) , and can be easily changed if a user doesn't like it ... Hmm. That seems to make the stuttering worse here, even at 50hz. But perhaps the interdependence of the autopilot and the frame rate needs fixing. And , of course , I'm still hoping for a multiplayer sim/model/texture property putting that on my Xmas wish list :) Yup, I'm with you on this one. Regards Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Unknown failure while Initializingsubsystems on win32 and Fedora 7 x86_64
Durk, Sent: 26 October 2007 07:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Unknown failure while Initializingsubsystems on win32 and Fedora 7 x86_64 On Thursday 25 October 2007 21:39, Melchior FRANZ wrote: * Durk Talsma -- Thursday 25 October 2007: Probably the best course of action is to send a friendly reminder to the plib list, and if it doesn't happen again, stick to plan B. Yes, but I won't do that. I did it on 2007/04/02, and the question remained unanswered. The last posting before that was two and a half months earlier, and the next was two months later. There are nicer places to be ignored. I'll ask. FWIW, I am also very skeptical that it will lead to anything, as I'm afraid plib is close to dying. Nevertheless, I'd like to ask, as courtesy to the well intended people over there (in particular John Fay, who's put a lot of effort into keeping plib going). I'm a bit impatient with plib, and I think that integrating the code into fgfs becomes more and more desirable. Which is also a reason why I would like to have the fgfs code cleaned up w.r.t. to the GUI parts. But I can commit my one year old patch right after the release, too. It would just be a pity if people continued to use the broken plib version out of laziness (and because we don't force them to use the fixed one. :-) IIRC, my plan B was something like, If plib manages to do a new release before we're ready for 0.9.11, we use that one. If not, we still use 1.8.4, and give them until the release of 0.9.12 (or whatever FG version number is next). If by then, we still haven't seen a new release, we fork our own versions of the relevant libraries. Assuming we stick to the plan of releasing one more plib version and then switch over to OSG, how much of plib do we still depend upon? The scene graph and the audio lib are already replaced by OSG and openal, so I guess it's joystick code and pui? Anything else? The problem with this plan is that OSG is simply not fit for purpose, at least not here. If you think the stuttering was a problem in plib, it's twice the problem in osg. Yes, the animations are better implemented, and the pick animation is particularly good, but frame rates are about 2/3rds that of plib, and we still lack random objects, 3d clouds, shadows, and the ordinary clouds aren't anything to write home about either. Even the much-vaunted particles are broken if you look at them closely. Of particular concern is that there has been no real progress for 12 months now. I'm sure we all know all of this, but perhaps it was worth restating. Regards, Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Unknown failure while Initializingsubsystems onwin32 and Fedora 7 x86_64
Heiko Sent: 25 October 2007 23:01 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Unknown failure while Initializingsubsystems onwin32 and Fedora 7 x86_64 Hi, I'm not sure but I'm think the problem is maybe in WinCVS. Today I noticed that the CH47 was not quite uploaded. The ac.model was missing though Syd had uploaded 3h before Maybe I have to try the TortoiseCVS... ... Snip ... I have used both WinCVS and Tortoise for years, and the only problem has been my finger trouble. Did you forget to use -d? Don't forget that you can force Unix line endings by checking the appropriate box in WinCVS preferences. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Sent: 25 October 2007 14:10 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes * Torsten Dreyer -- Thursday 25 October 2007: To make things easier for developers, can we think of a plug-in system for callbacks so a potential developer write a library that is linked in dynamically by the flightgear core? No. That would mean to add and maintain plug-in loader code for all supported platforms, as well as hundreds of lines of documentation, for people who are bright enough - to set up a development environment - to understand enough of fgfs internals to write a module - that follows an interface API specification but are too stupid - to add three lines to a Makefile.am - one line to fg_init.cxx and - one line to main.cxx Such a feature wouldn't make developing one bit easier or faster -- quite on the contrary. And it would lead in no time to Windows/Linux/Mac-*only*, binary *only* addons. Sure, the GPL would prohibit to run such modules with fgfs, and Curt would be happy to sue all infringers (because he has too much time and too much money. :-) This is not where we want to go. (As far as I'm concerned, but I don't speak for the project.) And to add my two pence worth, I have never had the slightest dificulty in getting new or amended code into fg, provided that it was: A. Justified B. Worked. There has been the odd difficulty over style, indents, and tabs. But let's not go there. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Unknown failure while Initializing subsystems onwin32 and Fedora 7 x86_64
Heiko Schulz Sent: 25 October 2007 19:21 To: FGFS Developers Mail List Subject: [Flightgear-devel] Unknown failure while Initializing subsystems onwin32 and Fedora 7 x86_64 Hello, Me, Aeortro and maybe some ohthers noticed a problem with fgfs. With the builts from 10/24/2007 and 10/05/2007 in both branches OSG and plib FGFS shut down while intializing subsystems. There are no error messages in the shell and no on the win32 eventmanager... Does anyone else have this problem? And how to get rid of them? I can't go on working on the 737-cockpit with these troubles This is not a fgfs problem - I compile my own versions of both branches for Windows, and have never had that problem (yet :-)). Looks like a data compatibility problem, or a bad binary. Why not compile your own, too? MSVC8 is a free download, and the project files are provided. It takes a little setting up, but once it's done compilation is swift, and (usually) painless. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Georg Vollnhals Sent: 23 October 2007 23:34 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? I have tested with vsync on and off. On balance vsync on seems to make the situation worse. I have also tried throttling the frame rate: this definitely is counterproductive, noticeably increasing the frequency and magnitude of the hesitations. One significant difference is that the Buccaneer has no malformed listeners in its Nasal so the gain in correcting this bug would, I think, be marginal. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Durk Sent: 24 October 2007 07:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes On Wednesday 24 October 2007 00:15, Vivian Meazza wrote: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Hmmm, I didn't say that FlightGear is completely pause free now. I did say that the mysterious interval pauses are gone. These are the pauses that become increasingly longer and longer over time (up to the point of several seconds, or even minutes). The interval pauses are not affected by terrain type or whatever, and originate because the nasal memory footprint keeps growing and growing. From the sound of it, you're experiencing model loading pauses (either caused by Multiplayer / AI, of the tile loader). Most likely, the pauses you see correspond to pauses coming from the terrain loader (since they don't correspond to Subsystem activity). To verify, place a debug statement in simgear/scene/model/model.cxx, line 462, or thereabouts. Something like: SG_LOG(SG_GENERAL, SG_INFO, Requesting model path); and see if that message corresponds to the pauses you see. Its obvious that eventually we need to address these pauses too. This may take a bit longer, because it requires redesigning. In plib we're actually hitting a design limitation, but in OSG it should be possible. Having said that, addressing the model loading pauses isn't nearly as daunting, because the problem is well understood. This is stark contrast with the interval pausing, where none of us really had a good idea what was going on, until about a week ago or so. Thanks for clearing that up: yes, we do seem to have cleared a significant bug. Your analysis of the problem seems plausible. I'll try the debug statement later today. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes
Heiko Schulz Sent: 23 October 2007 23:55 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FlightGear/Plib periodic stutter notes Hi, Couldn't test it, waiting that someones will do a precompiled binary for windows. But it sounds good, very good though at least there are still some perfomance issues. I think of AI and the loading of the scenery tiles. What Vivian is writing sounds for me like the stutters of loading of objects. If I use Random Objects FGFS is hardly to use, even I decrease the count of objects. It would be good if Vivian could send his choosen settings for comparing. HHS --- Georg Vollnhals [EMAIL PROTECTED] schrieb: Vivian Meazza schrieb: Not here, I'm afraid. Very good frame rates using the Buccaneer (70+) but there are still noticeable pauses over land. None over the ocean tiles. The pauses, or hesitations do not seem to be associated with any Subsystem Timing Alert, of which there are almost none. Regards, Vivian Hi Vivian, mmmh, as it really works for me as I already posted I want to add that my test still was made with Sync to VBlank on AND all AI stuff swiched off in the preferences.xml. AI stuff might now work without resulting in stuttering, I have to test it, but I doubt that I can omit the Sync switch, this seems to be another special problem. Did you think of that? This test was run with every option de-selected, including --prop:/sim/replay/disable=1 Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] optimized generic_pylons and .osg models
Tim Moore Sent: 13 October 2007 01:40 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] optimized generic_pylons and .osg models Melchior FRANZ wrote: * Tim Moore -- Saturday 13 October 2007: I've added a feature to SimGear that substitutes a model with a .osg extension for other models (not .xml) when it exists. This seems to be a bit controversial [...] That's quite an understatement. You asked on IRC about that and got *only* objections. You were the only one who liked the idea, IIRC. I find it quite disturbing that you ignore the opinions that you *asked* for, and do it anyway. If I had received only objections, I wouldn't have checked it in. My characterization of the discussion, including discussion today, is fair. This is IMHO an important performance enhancement that I feel is important to get out there. Like I said, I'm willing to change the mechanics of it. I'd prefer that explicitly stated paths are respected and are not replaced behind the scenes. Now, if an XML file only demanded a pathfoo/path without extension, then it would be ok to first try foo.osg and then foo.ac. But we told you yesterday ... m. My objective is to be able to override model file paths that seem to be hard to change, like those in the scenery files. Perhaps it's easier than I think to update those? How often is the scenery rebuilt? The discussion on IIRC was brief, late at night and the proposal was both not well put or understood. As I now understand it, the proposal is to automatically use .osg files in scenery in place of .ac files, where the former exist. I for one have no difficulty with this. If performance is better, or at least no worse, than with the .ac version, and provided that ft-lb is unaffected then no harm is done. This should be quite invisible to the user. I can't see that this should be in the least controversial. Let's try it Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
David Megginson Sent: 12 October 2007 15:11 To: FlightGear developers discussions Subject: [Flightgear-devel] Consistent aircraft states On 12/10/2007, dave perry [EMAIL PROTECTED] wrote: Welcome back. I am the one that made all the changes to the Warrior. Starting directions and keyboard switch equivalents are under the help menu-Aircraft help, just like with the pa24-250. It was after you had commented on how you liked what I had done on the pa24 that you sent me your pictures and asked if I wanted to continue developing the Warrior, so I used the pa24 nasal work as a starting point for implementing the Warrior electrical system and switches. You did a great job on it -- I'm very impressed. I still consider the Warrior your aircraft and had communicated to you off list in mid August that I had made updates and changes. I asked for feedback in that note. I assume that you did not disable or bypass the nasal implemented switches with the above change. No, but I did migrate some of the property settings out of the Nasal script and into the XML settings file. I am clearly one that prefers to start with the brakes set and all switches off as that is the way every real flight starts. (An aside: In my experience, it's rare that the parking brake is on when a real light plane is parked, because line staff wouldn't be able to move it around without gaining inside access -- in fact, when I get out of the plane at a remote airport, the first question from line staff is usually not do you need fuel? but is the brake off?. Normally, a plane on an apron is chocked, while a plane in longer-term parking is tied down.) But I also see the advantage of having an easy option to start in the air with switches and fuel valve set for an approach. Perhaps with a little more effort, there is a way to accomplish both. Here are a few usability guidelines that might help: 1. Consistency - all aircraft should start in same default state as far as possible (obviously, a glider doesn't have an engine), so that a user isn't surprised when switching aircraft types. 2. Configurability - it should be not only possible but very easy for a user to override the default state without editing XML or Nasal files. 3. Simplicity - the default state should be the easiest one for new users. Experienced users will have an easier time changing the default. I suggest that we introduce a new global property, such as /sim/start-state, which can be set to (say) parked, in-air, or idling. The configuration files for every aircraft could respect that property, so that if you set it to parked, *every* aircraft (even the default 172) would start parked, etc. (we could even put it on the apron instead of the runway if we add parking coordinates to the airports file). I think idling should be the default the first time someone runs FlightGear, since it's standard with all flight sims and by far the easiest for new users, but one menu selection should be able to switch to parked for people (like you) who prefer to go through the startup and taxiing routine every time. All the best, You can have your aircraft any way you want, but don't force it on other designers without some real thought. Start the Spitfire and forget to zero the throttle, you will start on your nose. That doesn't give a good impression to newcomers. On the other hand, there are quite a number of ac which seem to need some tlc. Several JSBSim ac want to start on their backs here post recent updates. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] oil platform...
Syd wrote Sent: 04 October 2007 01:39 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] oil platform... On Wed, 3 Oct 2007 17:29:54 -0700 SydSandy [EMAIL PROTECTED] wrote: If you define it to be typecarrier/type you can define solidObject/solid and you may define a park position no need to have wire and catapult Regards -- Gérard http://perso.orange.fr/GRTux/ ah thanks ! I tried typeshiptype and typestatictype ... Didn't try carrier though... -- SydSandy [EMAIL PROTECTED] so I guess my next question is , is this an option that could be added to all demo objects ? Cheers Of course, anything is possible, but it's only applicable to ships and static objects. If a ship can operate an ac, the it could be called a carrier anyway. So why not leave it as it is, and call a static oil rig a carrier. Any drawback to doing that? Hmm. I have some difficulty with putting oil rigs in locations where they aren't in RL. Realism is our watchword. After all, there are hundreds, if not thousands of the darned things all over the shallow oceans for you to put one in the right place. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Hi Durk Sent: 25 September 2007 19:57 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FGFS 0.9.11 release candidate two Hi Vivian, On Tuesday 25 September 2007 17:39, Vivian Meazza wrote: Here's a short burst of the output of Fred's profiling code using Windows XP, with the source code complied using MSVC8; Subsystem Timing Alert : 19000 fx Subsystem Timing Alert : 15000 fx Subsystem Timing Alert : 14000 replay Subsystem Timing Alert : 11000 replay Subsystem Timing Alert : 15000 replay Subsystem Timing Alert : 14000 replay Subsystem Timing Alert : 12000 fx Subsystem Timing Alert : 18000 replay Subsystem Timing Alert : 17000 fx Subsystem Timing Alert : 32000 input Subsystem Timing Alert : 19000 fx Subsystem Timing Alert : 11000 fx Subsystem Timing Alert : 11000 fx Subsystem Timing Alert : 11000 fx Subsystem Timing Alert : 63000 ai_model Subsystem Timing Alert : 12000 fx Subsystem Timing Alert : 16000 fx Visually, the stutters do not seem to coincide timewise with the output from this code, so I'm not _totally_ convinced that we are getting anything very useful. Is there anything else I can do to help? Thanks for the report. Looking at your report, I'm not seeing that many alarming timing problems (yet). Looks like the longest one is a 63 ms ai_model one. A few questions regarding your testing conditions: - How much time since program start had passed since taking these? - Which aircraft did you try. FWIW, I've been testing using the SenecaII-jsbsim. Initially the timing problems aren't that bad, but after about leaving FlightGear running for about 3 hours, I'm getting very significant timing problems, the last one before I killed the program being close to 45 seconds. I got the following timing errors: Subsystem Timing Alert : 12553567 replay Subsystem Timing Alert : 1953303 controller Subsystem Timing Alert : 1955229 environment Subsystem Timing Alert : 6890232 replay Subsystem Timing Alert : 39674 controller Subsystem Timing Alert : 41267 environment Subsystem Timing Alert : 108117 replay I just don't understand what's going on here... That was using the Sea Vixen, and I only ran that particular test for 5 mins or so, and the report was just an extract of more of the same. I agree with your observation that there were no particular problems shown up here, neither was there much visible on the screen. But as I said there was a little stutter visible, but didn't seem to tie up with any output Subsystem Timing Alert. I have run a much longer test, but without very different results to date. I'll test some more. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.11 release candidate two
Durk Talsma Sent: 25 September 2007 07:36 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] FGFS 0.9.11 release candidate two On Sunday 23 September 2007 13:50, I wrote: Some observations: - Some small pauzes seem to be caused by consecutive calls to the systems controller and environment. Execution times of these systems is variable, between calls, but the execution time of environment seems to be just slightly longer than that of controller: Subsystem Timing Alert : 18150 controller Subsystem Timing Alert : 20519 environment Subsystem Timing Alert : 47917 controller Subsystem Timing Alert : 49514 environment The longer and icreasingly growing pauzes seem to be caused by replay, possibly in interaction with some of the other subsystems. I haven't really found out what is going on here. Just a quick follow-up question: Has anybody tried running FlightGear / plib with the last SimGear checkout (with Fred's profiling code)? The observed timing problems are the major show stopper for the next release (IMHO), so I think we should try to get to the bottom of it. I'm postponing putting out a release candidate until we have some better understanding as to what's going on. I might have another look this weekend, but don't have time right now. Here's a short burst of the output of Fred's profiling code using Windows XP, with the source code complied using MSVC8; Subsystem Timing Alert : 19000 fx Subsystem Timing Alert : 15000 fx Subsystem Timing Alert : 14000 replay Subsystem Timing Alert : 11000 replay Subsystem Timing Alert : 15000 replay Subsystem Timing Alert : 14000 replay Subsystem Timing Alert : 12000 fx Subsystem Timing Alert : 18000 replay Subsystem Timing Alert : 17000 fx Subsystem Timing Alert : 32000 input Subsystem Timing Alert : 19000 fx Subsystem Timing Alert : 11000 fx Subsystem Timing Alert : 11000 fx Subsystem Timing Alert : 11000 fx Subsystem Timing Alert : 63000 ai_model Subsystem Timing Alert : 12000 fx Subsystem Timing Alert : 16000 fx Visually, the stutters do not seem to coincide timewise with the output from this code, so I'm not _totally_ convinced that we are getting anything very useful. Is there anything else I can do to help? V. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Looks great
Melchior FRANZ wrote Sent: 22 September 2007 16:03 * Durk Talsma -- 9/19/2007 10:17 PM: Currently, the situation isn't as clear anymore, because the OSG version also has many new features which the PLib version doesn't, The most obvious differences are AFAIK: fg/plib fg/osg --- volumetric shadows -- random objects -- 3D clouds -- bugfree 2D clouds -- -- pick animation -- multi-view There are a couple more: heat haze shader -- scale/personality scale/personality animation bugs animation bugfree I appreciate that the animation issue is perhaps more interpretation than bug, but it does mean that some complex animations work in osg, but mot in plib, and vice versa. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serious simmer
Robin van Steenbergen -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sent: 21 September 2007 04:03 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Serious simmer Ampere K. Hardraade schreef: I have seen far more serious simmers. :P Ampere That basically translates as: We really want some pictures of that! All of that guy's sim is MSFS-based with third party add-on instruments, and all of the monitors on his desk are run from a single PC. If FG is going to be used in home cockpits (Which I REALLY am in favor of) we need some way to get the instruments currently in FG out in an external application, which can run a 2D panel on a separate monitor. FG of course already has the possibility of exporting data over the network and linking copies for visuals (--external-fdm) but I'm not sure to what extent all of the instruments will follow in the slaved FG copy. The most important instrument you will have to run offboard except the basic six are engine gauges, radio and possibly map navigation. Making a decent (preferably OpenGL, vector-based) framework for FG panels would be a good development step, and it need not neccesarily be in the FG branch. As long as it follows the FG spec for the current instruments it will work, and we might be able to add XML-based vector artwork for glass cockpits later (SVG instrument rendering, anyone?). We could borrow some ideas from ARINC661 here. The project would be similar to X-Panel, already developed for X-Plane, so PanelGear might be a suitable name? Obviously someone who keeps right up-to-date with FG, and reads our website :-). Try this: http://www.flightgear.org/Projects/ John Wojnaroski is particularly active in this field Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The Release
Stewart Andreason Sent: 01 September 2007 15:03 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] The Release Did anybody ever acknowledge, duplicate, or fix the bug I reported in Simgear-0.3.11-pre1 on May21? make[3]: Entering directory `/usr/src/SimGear-0.3.11-pre1/simgear/math' FAIL: SGMathTest Stewart Not under MSVC8 - compiles correctly. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Particle Systems
John Wojnaroski Behalf Of Sent: 01 September 2007 21:47 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Particle Systems I've yet to see a system that IMHO tops what Mark Harris did a few years ago part of his doctoral thesis. See http://www.lfstech.com/img/sfo_clouds.jpg. Someone made a decision a few years ago to replace rather than improve. Think we all lost a very promising implementation, but there might be an opportunity to recover what was lost. Stay tuned... John Detlef Faber wrote: Hello everybody, I've been playing around with OSGs Particle Systems and found this might be suitable to create some 3d clouds. But see yourself: http://www.sol2500.net/flightgear/ksfo-under-clouds.jpg http://www.sol2500.net/flightgear/cloudfront.jpg http://www.sol2500.net/flightgear/clouds-over-ksfo.jpg http://www.sol2500.net/flightgear/bushfire.jpg Here is a zip containing the files. http://www.sol2500.net/flightgear/ParticleSys.tar.gz Put it in /Models/ and use the ufo to place them. clouds.xml creates a 20x20 km big cloud field. Sometimes particle systems do not work at once. They cannot (yet) be placed as static objects in the scenery. Finally they get clipped by the Cloud Layer, so be sure to switch off any clouds. Perhaps someone with knowlage of the weather system has an idea how to use these. Greetings Detlef I'm with you on this one John, except I can't see how to integrate that solution, or the particle solution with the weather radar. But perhaps some real expert can ... Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Bug-Report] Stutterer and pauses withdynamic-view
Robert Black Sent: 29 August 2007 03:41 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [Bug-Report] Stutterer and pauses withdynamic-view On Tuesday 28 August 2007 18:44, Laurence Vanek wrote: also had this problem in general (not with dynamic view). only thing that helped was adding the following to my .fgfsrc file: --prop:/sim/frame-rate-throttle-hz=75 as far I know no one has solved this problem. apparently only a few of us seem to have the issue. I thought everyone had this behavior. Most videos I have seen of FG have the stutter and pause. Robert I certainly do. I suspect that people have given up complaining about it and have come to regard it as normal. At its worst it makes FG almost impossible to use. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [ANN] Seahawk Update
Hi, I've just uploaded some updates to the Seahawk to correct the detailing for the FGA6 variant, and took the opportunity to add drop tanks, and a more accurate representation of the pilot and the Martin-Baker Mk 2 ejection seat. This update has been much enhanced by AJ working some magic on textures (something to do with trousers, don't ask). Some screenshots: ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/ ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/MB-MK2-5.png MB-MK2-5.png ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/ ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/MB-MK2-6.png MB-MK2-6.png I've also tinkered with the YASIm config. For those that like that kind of thing I've realigned the pilot's eye, the gunsight, and the cannon. Should be really easy to get hits now :-). Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC8 link problem - Missing function ingnnode.cxx?
Geoff Air
Sent: 06 August 2007 12:47
To: flightgear-devel@lists.sourceforge.net
Subject: [Flightgear-devel] MSVC8 link problem - Missing
function ingnnode.cxx?
Hi Durk,
The file src/Airports/gnnode.hxx declares a function -
FGTaxiNode(double, double, int);
Then in parking.hxx, you added -
: FGTaxiNode(lat,lon,idx);
about July 5 from the CVS logs ...
In WIN32, MSVC8 can NOT locate this function, and marks it as
a missing
external.
It seems obvious from the code that this should be something
like - FGTaxiNode::FGTaxiNode(double lat, double lon, int idx) {
setIndex(idx);
setLatitude(lat);
setLongitude(lon);
}
which I added to gnnode.cxx, and got my clean link, but
really wonder why
this has not come up on other systems. How can they resolve
FGTaxiNode(lat,lon,idx);???
Or have I missed something here? The src/Airports/makefile.am
seems to
include both parking.cxx and gnnode.cxx since about mid-July ...
Regards,
Geoff.
Hmmm, compiles as is under MSVC8 here, although I would agree that there
does seem to be a typo. Can't explain why MSVC8 doesn't mind, though. I can
click on the method FGTaxiNode(lat,lon,idx), and MSVC8 seems happy to find
it.
Vivian
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] CVS checkout of OpenProducer?
Holger Wirtz Sent: 28 July 2007 20:36 To: Flightgear Developers List Subject: [Flightgear-devel] [OT] CVS checkout of OpenProducer? Hi, does anyone know what's up with the CVS of OpenProducer? I tried to checkout for several days but it seems that the account data was changed. I tried to contact them and got the information that the CVS is now at cvs -d :pserver:[EMAIL PROTECTED]:/cvs/Producer co Producer But the same happens: wrong auth... I tried to get information from [EMAIL PROTECTED] but noone answered... So I asked here: does anyone know how to check out OpenProducer? Thanks, Holger It's no longer required for OSG. Do you need it for some other reason? Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] XMLLoader error
Kumar There is no error that I can see. Compiles and runs here using yesterday's CVS HEAD. Can you confirm that you have added XMLLoader.cxx and XMLLoader.hxx to your project file? Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of visa faq Sent: 27 July 2007 17:52 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] error Hi There, Did any one fixed the error with XMLLoader function. Please let me know the procedure to fix that. Appreciate your time. thanks. kumar _ Park yourself in front of a world of choices in alternative vehicles. Visit http://us.rd.yahoo.com/evt=48246/*http://autos.yahoo.com/green_center/;_ylc =X3oDMTE5cDF2bXZzBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDZ3JlZW4tY2VudGVy the Yahoo! Auto Green Center. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Broken Clouds
Hans Fugal Sent: 26 July 2007 14:57 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Broken Clouds On 7/26/07, Vivian Meazza [EMAIL PROTECTED] wrote: Hans Fugal I have never seen or heard of any problem with osg and clouds of any sort. Xnview reports no errors in cirrus.rgba, or with any of the textures. Perhaps you have corrupted the clouds textures locally? Did you open them in any editor before you saw the weird effects? Of course, people might be just accepting the weirdness, and not reporting it. Jester, jentron, and I did some investigating last night. The textures in question seem to be a less-common format that some programs understand and others do not. For example, IrfanView and ImageMagick both treat cirrus.rgba similarly - it looks something like this: http://hans.fugal.net/tmp/fg/cirrus-abstractart.png . I think we can agree this is not what the sky should look like. Some programs refuse to open it at all, complaining that they don't recognize the format. Jester has a better understanding about just what this format is, but I believe the salient features are 2-channel: greyscale with alpha. ImageMagick's identify(1) reports them as PseudoColor images (vs DirectColor) That's what I would expect, but Melchior is more knowledgeable than I. Gimp opens them fine, as does osgviewer --image cirrus.rgba. The latter is most important, it means that OSG itself can handle this format. So we likely are looking at a memory corruption bug in OSG when this particular type of image is loaded. Something about the way things work on intel macs is causing the corruption to manifest itself where as it goes unnoticed on linux by sheer luck. Just a theory anyway. On Windows, too. Incidentally, I have observed in both linux and osx in fg/osg that cloud layers don't work quite like I'd expect. If the weather is scattered clouds at 3000 ft and overcast at 5000, then when I'm sitting on the runway I see blue sky between the scattered clouds. It's not until I go above 3000 that suddenly there's overcast sky above me. I'm rather afraid that this last is a feature rather than a bug. As I understand it, it is a consequence of the way osg orders/handles transparencies. Not good at all. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Broken Clouds
Hans Fugal Sent: 26 July 2007 01:14 To: FlightGear developers discussions Subject: [Flightgear-devel] Broken Clouds Textures/Sky/broken.rgba seems to be literally just that, broken. Or rather, corrupted. As do scattered, few, and cirrus. fg/osg (but not plib) frequently crashes and I've traced it down to the cloud cover (clouds == likely crash, or crazy sky as in http://hans.fugal.net/tmp/fg/fgfs-screen-007.png, no clouds == probably no crash). ImageMagick does not think these corrupted (identify(1) should return nonzero if it encounters a corrupted file), but some of them are obviously not being interpreted correctly by ImageMagick. Try display cirrus.rgba to see what I mean. Unfortunately this means we can't just use convert(1) or mogrify(1) to fix the files that are broken. On the other hand opening them in Gimp they all look as they should. I saved them as PNG and then ran convert $i.png sgi:$i.rgba, and the crashes went away. Melchior says that gimp sometimes creates corrupt SGI files, and this is the likely root of the problem. I haven't been able to figure out a way to systematically identify corrupt SGI files (no doubt there are some more out there), but I'm moderately confident that this takes care of the Sky textures. Please import the fixed textures into CVS from http://hans.fugal.net/tmp/fg/Sky , or someone close to textures might prefer to fix them himself. Here's what identify returns on the files in my Textures/Sky directory: Snip ... I have never seen or heard of any problem with osg and clouds of any sort. Xnview reports no errors in cirrus.rgba, or with any of the textures. Perhaps you have corrupted the clouds textures locally? Did you open them in any editor before you saw the weird effects? Of course, people might be just accepting the weirdness, and not reporting it. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile FlightGear linking errors XMLLOaderfunction error
Hmm - same problem here - I look forward to someone coming up with an answer Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of visa faq Sent: 25 July 2007 17:24 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Compile FlightGear linking errors XMLLOaderfunction error Note: forwarded message attached. _ Ready for the edge of your seat? Check out http://us.rd.yahoo.com/evt=48220/*http://tv.yahoo.com/ tonight's top picks on Yahoo! TV. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile FlightGear linking errorsXMLLOaderfunction error
That's an easy one - make sure the files are added to your project - there are some missing from the existing project in cvs. When you do so the project will compile correctly. I've just confirmed that it will here. Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vivian Meazza Sent: 25 July 2007 18:19 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Compile FlightGear linking errorsXMLLOaderfunction error Hmm - same problem here - I look forward to someone coming up with an answer Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of visa faq Sent: 25 July 2007 17:24 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Compile FlightGear linking errors XMLLOaderfunction error Note: forwarded message attached. _ Ready for the edge of your seat? Check out http://us.rd.yahoo.com/evt=48220/*http://tv.yahoo.com/ tonight's top picks on Yahoo! TV. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compile FlightGear linkingerrorsXMLLOaderfunction error
Simple.cxx - that depends - I have the ground radar patch added in osg, so it's slightly different shouldn't make any difference. Do you have ~\source\src\Airports\xmlloader.cxx and .hxx in your project? That should fix the linking error. Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of visa faq Sent: 25 July 2007 19:07 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Compile FlightGear linkingerrorsXMLLOaderfunction error Hi What do you mean? I was able to compile it but when it starts linking, its giving the error that I have mentioned in the previous mail. Do you mean you were able to fix the problem of XML loader function that shows up while linking? I am attaching the simple.cxx program to this email. please let me know if you have a different one. thanks. kumar. Vivian Meazza [EMAIL PROTECTED] wrote: That's an easy one - make sure the files are added to your project - there are some missing from the existing project in cvs. When you do so the project will compile correctly. I've just confirmed that it will here. Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vivian Meazza Sent: 25 July 2007 18:19 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Compile FlightGear linking errorsXMLLOaderfunction error Hmm - same problem here - I look forward to someone coming up with an answer Vivian -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of visa faq Sent: 25 July 2007 17:24 To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Compile FlightGear linking errors XMLLOaderfunction error Note: forwarded message attached. _ Ready for the edge of your seat? Check out http://us.rd.yahoo.com/evt=48220/*http://tv.yahoo.com/ tonight's top picks on Yahoo! TV. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Luggage? GPS? Comic books? Check out fitting gifts http://us.rd.yahoo.com/evt=48249/*http://search.yahoo.com/search?fr=oni_on_ mailp=graduation+giftscs=bz for grads at Yahoo! Search. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
Durk Talsma Sent: 07 July 2007 08:22 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Today's CVS Hi Vivian, On Friday 06 July 2007 23:31, Vivian Meazza wrote: After further testing I can confirm that the disappearance is readily repeatable. If you position your ac on the threshold of 28R at KSFO, as the AI aircraft are about to trample all over you they obligingly commit suicide. The first then reappears well down runway 28L taking off, the second just disappears. This I can replicate! I was unable to reproduce this, until you provided a vital clue in the current message: as they are about to trample all over you. I usually try to get off the runway ASAP using the UFO, when inspecting traffic behavior, so I missed this one completely. Initially, I was a little confused about the teleporting part of your bug report, but it makes sense now. You couldn't know, but the disappearing and respawning are two independent phenomena. There is some basic proximity detection code which cause AI aircraft to wait for the user's aircraft. More recently I added a new function that detects situations in the ground network were aircraft are eventually waiting for themselves. (i.e. a waits for b; b waits for c; but c waits for a). The occurrence of these is not frequent, but when it happens, the waiting aircraft can block all other traffic. Eventually, this needs to be resolved more gracefully, probably by moving one of the offending aircraft back, or by implementing more sophisticated hold position instructions. Until that time the offending aircraft are removed from the scene. It seems this function is triggered whenever an AI aircraft is waiting for the user. I believe a solution is fairly straightforward, but requires some more testing. I'll probably have something at the end of the day. The respawning on the other hand, is a different phenomenon. During initialization, the traffic manager makes an estimate as to which stage of a flight an aircraft is: Wait at gate / push back / taxi / take off / climb / cruise. When an aircraft is considered to be in the take off stage, it is placed on the runway, and given take off speed during initialization, thus creating the illusion of a spontaneous spawning of these aircraft. It's not really an ideal situation, waiting for refinement. OK so it's 2 features, not 1 bug - excellent. I also noted that the route taken from parking to active runway seemed a bit odd, but then I compared our taxiways to those on Google Earth - we seem to have bits missing alongside 28L, which explains that. Not good for our default airport though. FWIW, I also hope to have a look at the tanker speeds this weekend. Your proposed fix seems to work here, on the basis of just one test, I haven't had time to do the job properly. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Today's CVS
Hi all, Today's cvs seems to have solved thru problem of crashes with traffic-manager when compiled with MSVC8, at least for short runs. My testing is incomplete, since I have not been able to test for extended periods, so the longer term memory leak that has been reported may still be present. That is the good news. The bad news is that the ac taxiing towards KSFO 28L disappear just as they arrive at the threshold. Reagan Thomas has already reported seeing this. So far as I can see, the ac are teleported to 28L, where they take off and carry on normally. I have tracked this visually and on radar, and it is repeatable. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's CVS
I wrote Sent: 06 July 2007 12:56 To: 'FlightGear developers discussions' Subject: [Flightgear-devel] Today's CVS Hi all, Today's cvs seems to have solved thru problem of crashes with traffic-manager when compiled with MSVC8, at least for short runs. My testing is incomplete, since I have not been able to test for extended periods, so the longer term memory leak that has been reported may still be present. That is the good news. The bad news is that the ac taxiing towards KSFO 28L disappear just as they arrive at the threshold. Reagan Thomas has already reported seeing this. So far as I can see, the ac are teleported to 28L, where they take off and carry on normally. I have tracked this visually and on radar, and it is repeatable. After further testing I can confirm that the disappearance is readily repeatable. If you position your ac on the threshold of 28R at KSFO, as the AI aircraft are about to trample all over you they obligingly commit suicide. The first then reappears well down runway 28L taking off, the second just disappears. On second thoughts this isn't perhaps such a bad idea after all, perhaps it's a feature not a bug. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Durk Talsma Sent: 03 July 2007 06:36 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] crash in AI traffic On Tuesday 03 July 2007 00:20, Vivian Meazza wrote: Vivian Meazza wrote: What were we saying about incompletely tested and poorly ^^ [Lot's a latin skipped for clarity] Perhaps you recall this thread: C++ code beautifier / Codingstandardsproposal Seems to me that we are just revisiting these issues. ...which is actually complete nonsense. Didn't I send you a preview of the latest patch, asking for a second opinion and potential MSVC issues? And now you're suggesting this patch was insufficiently tested, without mentioning this very fact? That's rather unfair, isn't it? Yes, you sent the patch to me, and I welcomed that. You will recall, I fixed one bug and reported another. But I also suggested that you submit the patch to this list for a fuller review and comment, and pointed out that my testing was incomplete. Please accept one fact. Code breakage does happen, whether we like it or not. I certainly don't like it, and I'm not intentionally trying to break code. It has happened to me in the past that someone else broke code I worked on. I don't like, it but usually I just go, find the problem, suggest a workaround, and notify the developer breaking the code of the proposed solution. As an example, the --start-date options were broken for quite some time, and even some code submitted by The Man himself once upon a time broke AI taxi behavior. Did I get mad about it? I don't recall. Of course code breakage happens. But in an ideal world, it shouldn't get into cvs. It makes us all look unprofessional. Proper peer review can help prevent this. At least it gives others, perhaps more expert than us a chance to spot things that we have missed. I missed the exit thing (I won't next time!): others might have seen it and raised objections, and suggested improvements before it all got into cvs. Then we can all move ahead together. Surely that's not too much to ask? Remember: P 6 - Piss Poor Peer-review Prevents Proper Performance Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Martin Spott wrote Sent: 02 July 2007 09:25 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] crash in AI traffic Melchior FRANZ wrote: Several people (mostly developers) on IRC have stated that they have the traffic manager turned off because [...] If you're really that serious about it, then you might start to help getting the thing into better shape by asking these people to report properly on this very mailing list instead just complaining, I am one of those developers who have the traffic manager turned off. I have taken the trouble sometime ago to inform Durk directly, so he is well aware of this bug. Along with the one which causes AITankers to move at warp speed factor 2. I would like to say that the recent changes have fixed it, and some short tests seem to indicate that is so, except that fg seems now to crash on reset instead of shortly after start. AIAircraft also disappear, apparently after takeoff. I can't say if this is a new bug - it's the first time I've got this far. Tankers are still at warp speed. But that is not really the point. We have some code which is intended to cause fg to exit, without an error message, and which is turned on by default. During testing some new code, it took me quite some (wasted) time and effort to establish that it wasn't my new code that was at fault. This is quite unacceptable. And I don't care how this situation is rectified, just so long as there is no repeat. What were we saying about incompletely tested and poorly reviewed code getting into cvs ... ? Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Csaba Halász Sent: 01 July 2007 21:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar Hello! Here is a new version of my radar patch. *** This is still for OSG only *** Theoretically the ai.diff wxradar.diff can be applied without the others to get data display on the wxradar. *Note: I have temporarily changed the texture size to 512. For a 1:1 mapping this will have to be dynamic later. Any objections? Included is a preliminary osgfont.diff that can optionally be applied to osg (duh). Having done that you can change the #if 0 in wxradar.cxx:844 and specify a truetype font in /instrumentation/radar/display-controls/font (I use VeraMono.ttf) to get nicer looking output. The ATC is currently nicest in 1024x768. Still on the TODO list: make more stuff configurable (colors), add highlight support, show taxiway designations, fix ATC panel bugs, support different resolutions, etc... You can get the package from http://w3.enternet.hu/jester/fgfs/atc-20070701.tgz [116kB] Let me know if I have broken something. You certainly have! That patch seem to apply cleanly here and compiles under MSVC8, but wxradar.diff breaks the KC-135, but we knew about that and it's readily fixable (already done and teested here). The new texture seems to break the whole display - it doesn't rotate correctly, and I seem to get 2 displays. Reverting to the one in cvs fixes it. There are no symbols that I can see - just 2 very small dots which are hardly visible. No runways - big disappointment - should there be? The aircraft number selector works in the wrong sense, and goes between 0-1, even when there are more ac on the radar The range selector appears to have no effect. Increments of 1nm? Most radars I'm familiar with have steps which double the range at each step 5, 10, 20 or 4, 8, i6, 32 are the ones I'm most used to. Great text!!! Well done No callsigns from the Traffic Manager stuff - did we break that? I would think that we could get wxradar.diff into cvs, but unless I applied the patch incorrectly (possible), the rest needs a bit more work. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
I wrote Sent: 02 July 2007 13:15 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar Csaba Halász Sent: 01 July 2007 21:12 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar Hello! Here is a new version of my radar patch. *** This is still for OSG only *** Theoretically the ai.diff wxradar.diff can be applied without the others to get data display on the wxradar. *Note: I have temporarily changed the texture size to 512. For a 1:1 mapping this will have to be dynamic later. Any objections? Included is a preliminary osgfont.diff that can optionally be applied to osg (duh). Having done that you can change the #if 0 in wxradar.cxx:844 and specify a truetype font in /instrumentation/radar/display-controls/font (I use VeraMono.ttf) to get nicer looking output. The ATC is currently nicest in 1024x768. Still on the TODO list: make more stuff configurable (colors), add highlight support, show taxiway designations, fix ATC panel bugs, support different resolutions, etc... You can get the package from http://w3.enternet.hu/jester/fgfs/atc-20070701.tgz [116kB] Let me know if I have broken something. You certainly have! That patch seem to apply cleanly here and compiles under MSVC8, but wxradar.diff breaks the KC-135, but we knew about that and it's readily fixable (already done and tested here). The new texture seems to break the whole display - it doesn't rotate correctly, and I seem to get 2 displays. Reverting to the one in cvs fixes it. There are no symbols that I can see - just 2 very small dots which are hardly visible. No runways - big disappointment - should there be? The aircraft number selector works in the wrong sense, and goes between 0-1, even when there are more ac on the radar The range selector appears to have no effect. Increments of 1nm? Most radars I'm familiar with have steps which double the range at each step 5, 10, 20 or 4, 8, i6, 32 are the ones I'm most used to. Great text!!! Well done No callsigns from the Traffic Manager stuff - did we break that? I would think that we could get wxradar.diff into cvs, but unless I applied the patch incorrectly (possible), the rest needs a bit more work. It helps if you put the new texture in the right place, it was the old one which broke everything. Now it works much better! I can now see symbols and the runways, and range now works. Apart from that all the above remarks still apply, with the addition that the tower position is marked with the own ac symbol - that is now selectable: heading-marker type=boolfalse/heading-marker Display runway up? or something? Most radar displays are North up AFAIK - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Thomas Förster Sent: 02 July 2007 13:41 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar No callsigns from the Traffic Manager stuff - did we break that? Probably not, never seen any... (so, if broken, not with the wxradar patch) Good. Phew. No callsign in the flightplans? I couldn't compare with earlier, since today is the first time I have actually seen this stuff working. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Martin Spott Sent: 02 July 2007 15:42 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] crash in AI traffic Vivian Meazza wrote: What were we saying about incompletely tested and poorly reviewed code ^^ getting into cvs ... ? - Plural majestatis ? Haud. Ego relatum ut an mane sermo. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Martin Spott Sent: 02 July 2007 16:32 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] crash in AI traffic Vivian Meazza wrote: Martin Spott Vivian Meazza wrote: What were we saying about incompletely tested and poorly ^^ reviewed code getting into cvs ... ? - Plural majestatis ? Haud. Ego relatum ut an mane sermo. Qui participavit in conclusio illa ? Magis personae quam una ? Non conclusio sed disputatio. Quod praeter unus alio disputatio. (I may have translated your Latin incorrectly personae does not mean persons but personalities, so my reply might be a non sequitor :-) ) V. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash in AI traffic
Martin Spott Sent: 02 July 2007 22:45 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] crash in AI traffic Vivian Meazza wrote: Martin Spott Sent: 02 July 2007 16:32 Vivian Meazza wrote: Martin Spott Vivian Meazza wrote: What were we saying about incompletely tested and poorly ^^ reviewed code getting into cvs ... ? - Plural majestatis ? Haud. Ego relatum ut an mane sermo. Qui participavit in conclusio illa ? Magis personae quam una ? Non conclusio sed disputatio. Quod praeter unus alio disputatio. (I may have translated your Latin incorrectly personae does not mean persons but personalities, so my reply might be a non sequitor :-) ) Well, before this turns into mutual instructions on how to translate Latin, we'd better return to a more common language. We still don't know the answer to your question What were we saying about , do we ? Perhaps you recall this thread: C++ code beautifier / Codingstandardsproposal Seems to me that we are just revisiting these issues. V. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [off list] patch forcontrol lockingbyautopilot
John Denker Sent: 30 June 2007 17:16 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [off list] patch forcontrol lockingbyautopilot Note that there are four stages of sophistication among FG users: a) Using the keyboard for primary flight control; b) Using the mouse for primary flight control; c) Using a plain old joystick for primary flight control; or d) Using a joystick with force-feedback (or position servos) for primary flight control. Must have missed the implementation of force-feedback in FG. Last I remember it had been disregarded on realism grounds. Did someone change this? Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Martin Sent: 23 June 2007 14:08 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar Vivian, Vivian Meazza wrote: I will attend to thus once the patches are approved/agreed in principle. [...] filename=fg_wx_radar_osg.diff.tgz In Instrumentation/wxradar.hxx at line 26 this patch introduces a dependency on plib/ssg.h. I think this is neither required nor desired, If it's not required, then it's certainly not desirable. I'm sure that can be removed. Thanks Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
-Original Message- Syd Sent: 22 June 2007 15:43 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar On Fri, 22 Jun 2007 13:42:16 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: * Vivian Meazza -- Wednesday 13 June 2007: Tim Moore has been hard at work recently (with the smallest of inputs by me), and has ported the improved weather radar already available for plib to OSG. No objections and other comments since the patches were published on 2007/06/20. Because of the nearing release (not that we have the slightest idea when this could be :-) and the nature of the patch I want to give developers one last chance to object: if nobody does that until tomorrow 2007/06/23 20:00 GMT, then I will: (a) apply those radar patches to sg and fg for osg and plib (b) comment out the delete rt in src/Instrumentation/od_gauge.cx:89 PRO + we have a nice c++ radar implementation in both branches, which handles arbitrary numbers of AI/MP aircraft, ships, TACAN emitting and other objects + we can drop the quite clumsy and limited limiting XML radar implementation + fixes a bug in AIManager (ask Vivian :-) + instantiates impact sub-submodels in correct order CONTRA - - bigger commit despite the near(?) release, with potential risk to break something BUT: + the patch touches only files that can hardly have side effects on other subsystems, and isn't executed at all when aircraft without od_gauge/radar are used (which is the vast majority). So even if there'd be problems, they would only affect the E3B, the T38(?), and ... the harrier? And even then one could comment out the radar instrument in the XML file and avoid all problems. + the patches were tested by, at least, Vivian, AJ, Csaba Jester(?) and me, and found functional and not causing problems, except the following (AJ and I): - requires to comment out the destruction of the RTT class to avoid crashes on exit on (some?) nVidia cards. That's hackish, BUT: + that's exactly what the 3D clouds are doing since years! They don't destruct the RTT class either! Nobody has reported problems that could be linked to that, none of the developers has observed such problems (AFAIK). + that's exactly what the TestRenderTexture.cxx test application by the very author of the RenderTexture class does. He doesn't destruct the class either (except before creating a new one during mode changes on user request). + it can be assumed that the card frees this resource like all others, when the context is destroyed, so the buggy freeing operation via glXDestroyPbuffer() should be optional in this case. m. Hi , I vote for adding it , and I've had that shutdown error since I first used the wxradar ,it's not a new one here... Just my 2 cents worth :). Cheers That's very interesting information. We suspected that this was a longstanding problem, but had no evidence. And does Melchior's fix, fix it for you? V. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Syd Sent: 22 June 2007 20:18 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar On Fri, 22 Jun 2007 16:56:34 +0100 Vivian Meazza [EMAIL PROTECTED] wrote: -Original Message- Syd Sent: 22 June 2007 15:43 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar On Fri, 22 Jun 2007 13:42:16 +0200 Melchior FRANZ [EMAIL PROTECTED] wrote: * Vivian Meazza -- Wednesday 13 June 2007: Tim Moore has been hard at work recently (with the smallest of inputs by me), and has ported the improved weather radar already available for plib to OSG. No objections and other comments since the patches were published on 2007/06/20. Because of the nearing release (not that we have the slightest idea when this could be :-) and the nature of the patch I want to give developers one last chance to object: if nobody does that until tomorrow 2007/06/23 20:00 GMT, then I will: (a) apply those radar patches to sg and fg for osg and plib (b) comment out the delete rt in src/Instrumentation/od_gauge.cx:89 PRO + we have a nice c++ radar implementation in both branches, which handles arbitrary numbers of AI/MP aircraft, ships, TACAN emitting and other objects + we can drop the quite clumsy and limited limiting XML radar implementation + fixes a bug in AIManager (ask Vivian :-) + instantiates impact sub-submodels in correct order CONTRA - - bigger commit despite the near(?) release, with potential risk to break something BUT: + the patch touches only files that can hardly have side effects on other subsystems, and isn't executed at all when aircraft without od_gauge/radar are used (which is the vast majority). So even if there'd be problems, they would only affect the E3B, the T38(?), and ... the harrier? And even then one could comment out the radar instrument in the XML file and avoid all problems. + the patches were tested by, at least, Vivian, AJ, Csaba Jester(?) and me, and found functional and not causing problems, except the following (AJ and I): - requires to comment out the destruction of the RTT class to avoid crashes on exit on (some?) nVidia cards. That's hackish, BUT: + that's exactly what the 3D clouds are doing since years! They don't destruct the RTT class either! Nobody has reported problems that could be linked to that, none of the developers has observed such problems (AFAIK). + that's exactly what the TestRenderTexture.cxx test application by the very author of the RenderTexture class does. He doesn't destruct the class either (except before creating a new one during mode changes on user request). + it can be assumed that the card frees this resource like all others, when the context is destroyed, so the buggy freeing operation via glXDestroyPbuffer() should be optional in this case. m. Hi , I vote for adding it , and I've had that shutdown error since I first used the wxradar ,it's not a new one here... Just my 2 cents worth :). Cheers That's very interesting information. We suspected that this was a longstanding problem, but had no evidence. And does Melchior's fix, fix it for you? V. Hi Vivian, No I haven't tried the updated version yet ... anxiously awaiting CVS version ;).But I can try it first if you like , and see what I get ... Cheers -- It would be helpful if you could comment out delete rt in src/Instrumentation/od_gauge.cx around line #89, and tell us if that fixes the problem in the old code. Thanks Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Melchior FRANZ Sent: 19 June 2007 12:23 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar * Vivian Meazza -- Sunday 17 June 2007: That's done - the patches are attached. The are NOT formatted properly, so no rants about tabs, spaces or trailing spaces. That's OK for the old code (and less so for the added code. :-} Meanwhile the files for the base package are available, too (even committed), so testing is actually possible. The patches applied cleanly and compiled with a few warnings. I found only minor things to fix: - dead but uncommented code in one case [if (foo false) ...] - redundant assignments [float x = 0; x = foo-getFloatValue();] - compiler warnings I didn't thoroughly review (nor understand ;-) all the code, especially not the OSG parts, but I trust Tim. Also, the patches don't touch much other code, so I wouldn't be worried about it. The patch did not work for me at first, because (like other developers, I guess) I'm using /sim/sceneryloaded-override. This prevented that /sim/sceneryloaded ever became true, while od_gauge waited exactly for that. This is meanwhile fixed (main.cxx). After that the code worked in both fg/plib and fg/osg, but in fg/plib I get a segfault on exit, which comes from RenderTexture.cpp. That's quite a hairy piece of code, and I'm not really competent to fix it. I checked on the net if newer RenderTexture implementations have that code part fixed, but this is not the case. #0 0x7773612f in ?? () #1 0xb7c4f52f in _X11TransWritev () from /usr/lib/libX11.so.6 #2 0xb7c54f21 in _XSend () from /usr/lib/libX11.so.6 #3 0xb7c4625b in XQueryExtension () from /usr/lib/libX11.so.6 #4 0xb7c3ab0b in XInitExtension () from /usr/lib/libX11.so.6 #5 0xb6ffb0f3 in XextAddDisplay () from /usr/lib/libXext.so.6 #6 0xb7db368e in glXChannelRectSyncSGIX () from /usr/lib/libGL.so.1 #7 0x08a69258 in ?? () #8 0x08b008c0 in ?? () #9 0xb7de2eb5 in std::basic_streambufchar, std::char_traitschar ::showmanyc () from /usr/lib/libGL.so.1 #10 0xb7df2dc0 in std::basic_streambufchar, std::char_traitschar ::showmanyc () from /usr/lib/libGL.so.1 #11 0x0011 in ?? () #12 0x08b008c0 in ?? () #13 0x1137ead8 in ?? () #14 0x08589295 in RenderTexture::_Invalidate (this=0xb7db5fe0) at simgear/screen/RenderTexture.cpp:848 #15 0x0858ea8f in ~RenderTexture (this=0x1137ead8) at simgear/screen/RenderTexture.cpp:204 #16 0x083b9e22 in ~FGODGauge (this=0xb45e518) at src/Instrumentation/od_gauge.cxx:89 #17 0x085d6b2d in ~Member (this=0xd1ea7a0) at simgear/structure/subsystem_mgr.cxx:227 #18 0x085d7ba9 in ~SGSubsystemGroup (this=0xb7dadb67) at simgear/structure/subsystem_mgr.cxx:85 So, applying the patches for fg/plib would mean to replace a cheesy but not-crashing radar implementation by a nice but crashing one. I don't say that the radar patch is buggy, it's just the old render-to-texture feature. (It's also not my graphics card driver, as Qt4 has no problems with RTT.) I would very much like to apply the patches, but I think the crash should be fixed first. (Or should the fg/osg patches go in, anyway?) That crash is not repeatable here, but perhaps that wouldn't be unexpected. I am surprised by it though - the code (od_gauge.cxx) which interacts with RenderTexture.cpp is untouched by this patch. Perhaps this isn't a new bug after all. Perhaps someone else could confirm this behaviour? Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new pseudo FDM for vehicles (osg branch)
Melchior FRANZ Sent: 20 June 2007 16:01 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] new pseudo FDM for vehicles (osg branch) * Anders Gidenstam -- Tuesday 19 June 2007: It is also fairly easy to make liftless aircraft FDM configs for ground vehicles in JSBSim - I made a simple one for a mule / small tow truck yesterday. You can get it here: http://www.gidenstam.org/FlightGear/misc/towtruck_fgfs.tar.gz Note: it is not particularly well tuned yet.. :) Wonderful already! Browsed around with it in KNID, LOWL, and KSFO. YASim would just have been nicer as an FDM, for the surface material aware gear and the towing capabilities. One could really tow a 747 over MP with it. :-) Hey - you can drive around the deck of Nimitz in it - great. But I couldn't get down into the hangar because it won't stay still long enough with the brakes on. Why not a YASim towtruck then we can pull ac out of the hangar etc.? And we need reverse gear. Good fun ... Now I must do something about lashings for ac on the carrier ... Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Melchior FRANZ Sent: 20 June 2007 16:35 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar * Vivian Meazza -- Wednesday 20 June 2007: Melchior FRANZ I don't say that the radar patch is buggy, it's just the old render-to-texture feature. (It's also not my graphics card driver, as Qt4 has no problems with RTT.) Perhaps this isn't a new bug after all. Yes, that's my assumption. I've spent some time on that but still haven't found the cause. Tender-to-texture works in fg/osg and QT4, so it doesn't seem to be a graphics card driver problem. 3D clouds also use RenderTexture but don't cause crashes. So, what's the difference? Answer: the clouds never call the RenderTexture destructor! If I comment out delete rt in ~FGODGauge(), then I don't get a crash either. Unfortunately, I couldn't find out if the destruction is really needed (calling glXDestroyPbuffer()). The RTT instruments are only destroyed at exit, and maybe the destruction of the GL context frees everything, anyway? BTW: the TestRenderTexture app in simgear/screen/ does also not crash, despite calling glXDestroyPbuffer() for mode changes (Return-key). But it does also not destroy the RenderTexture class at exit! So is this an acceptable method? Would commenting out delete rt be the solution for 0.9.11? (And committing the radar patch, of course. :-) Hmm, I don't get the crash here, so it is difficult to take a view. On the one hand, if 3D clouds don't call the destructor, then that should be good enough for od-gauge. On the other hand, would not calling the destructor cause memory not to be released on exit? I'll test it here to see if I can detect an adverse effects. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Melchior FRANZ * Vivian Meazza -- Wednesday 20 June 2007: On the one hand, if 3D clouds don't call the destructor, then that should be good enough for od-gauge. On the other hand, would not calling the destructor cause memory not to be released on exit? I could well imagine that at the end of the GL application everything is freed, anyway. But I didn't find anything about it on the net. The clouds don't destruct the RenderTexture class at exit, simgear's TestRenderTexture app doesn't, not even Mark HARRIS' own TestRenderTexture application does! ... only od_gauge does, with little success. :-} (The instrument subsystem is apparently not destroyed/recreated on reinit, so this wouldn't be a problem either.) Hmm ... I just don't know ... :-/ m. There seems to be no difference after I removed the destructor here. I would say on the evidence of the 3d clouds etc. the one in od_gauge can safely be removed. V. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] new pseudo FDM for vehicles (osg branch)
Melchior FRANZ wrote * Oliver Schroeder -- Tuesday 19 June 2007: attached is a patch for the osg-branch, which will introduce a new pseudo FDM for ground vehicles and (large) ships. The FDM isn't perfect, but good enough to allow driving vehicles. I'd very much like to have a car FDM. A realistic one like Curt mentioned. But this suggested FDM is even less sophisticated than the ufo, and I guess that a special yasim config would make a far better car. So, if it isn't a serious FDM from the beginning, then I think we are better off with a car-o-matic script, which -- in analogy to jsbsim's aeromatic -- would knock out yasim configs from simple car properties. m. To follow these remarks - there is a quite sophisicated pseudo-fdm already in AIShip, which takes into account turning circles, rudder angles, speed, and acceleration and rolls and steers the ship accordingly. This code is able to accept inputs of the form of target course and speed, or direct input of rudder angles. Is there something wrong with it? I also have doubts that a single fdm can accurately reproduce ship and car characteristics - a ship isn't a big truck which travels over sea rather than land. Ships do not respond immediately to rudder inputs, and to stop a turn they require counter-rudder. They also roll in turns. In this sim the 100,000 ton Nimitz seems to have no mass, and a turning circle significantly tighter that a destroyer. Max rpm is more likely to be 250 rpm than 2500 rpm. Take it from an old salt - this is the least ship like ship simulator I have come across. I love the views - particularly the bridge. Somewhere along the line, I seem to have lost the wake here, which spoils some of the views a bit. Don't know if these comments are particularly helpful, but I fully support your intention to have a MP carrier. However, it's fun for a few minutes to steer a carrier, or it might be if it were a lot more realistic, but actually, I'd like this automated, so that I can fly off the darned thing, and not be a taxi-driver for the Airedales. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instrument-altimeter unable to indicate altitude above 61831 feet
John Sent: 18 June 2007 10:41 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Instrument-altimeter unable to indicate altitude above 61831 feet On 06/18/2007 04:06 AM, Stefan Seifert wrote: snip 4) By the way, did you ever wonder what osi means, in the context of the mp-osi property? The only documentation I can find on the subject is here: http://baron.flightgear.org/pipermail/flightgear-devel/2003-Ma y/017373.html The only problem is that it is 100% false. Hmm - I always thought that it was a typo that no one got around to fixing. I tried once, but it crept back in. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Melchior Sent: 17 June 2007 18:39 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar * Vivian Meazza -- Friday 15 June 2007: ftp://abbeytheatre2.org.uk/fgfs/instrumentation/osg/ We now have the improved weather radar code available for plib and osg, [...] I intend to get this code into cvs-HEAD and cvs-PLIB over the coming weekend, I haven't tested that, as this osg directory contained several files with few hints about what goes where, and no apparent files for the plib branch at all. I would have preferred five links to patches (not ftp directories!) -- each of them one patch to be applied at the base directory: plib: changes to sg/plib changes to fg/plib osg: changes to sg/osg changes to fg/osg common: changes to base But maybe someone else has tested the radar for plib and osg and can report success/failure? Now that the situation seems to have settled, I'm already redoing the patches in exactly that format. I hope to have finished later today - perhaps. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Sent: 17 June 2007 19:29 To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar Melchior Sent: 17 June 2007 18:39 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar * Vivian Meazza -- Friday 15 June 2007: ftp://abbeytheatre2.org.uk/fgfs/instrumentation/osg/ We now have the improved weather radar code available for plib and osg, [...] I intend to get this code into cvs-HEAD and cvs-PLIB over the coming weekend, I haven't tested that, as this osg directory contained several files with few hints about what goes where, and no apparent files for the plib branch at all. I would have preferred five links to patches (not ftp directories!) -- each of them one patch to be applied at the base directory: plib: changes to sg/plib changes to fg/plib osg: changes to sg/osg changes to fg/osg common: changes to base But maybe someone else has tested the radar for plib and osg and can report success/failure? Now that the situation seems to have settled, I'm already redoing the patches in exactly that format. I hope to have finished later today - perhaps. That's done - the patches are attached. The are NOT formatted properly, so no rants about tabs, spaces or trailing spaces. I will attend to thus once the patches are approved/agreed in principle. Vivian sg_wx_radar_plib.diff.tgz Description: application/compressed fg_wx_radar_osg.diff.tgz Description: application/compressed fg_wx_radar_plib.diff.tgz Description: application/compressed sg_wx_radar_osg.diff.tgz Description: application/compressed - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
I wrote Sent: 13 June 2007 16:54 To: 'FlightGear developers discussions' Subject: [Flightgear-devel] [ANN] OSG - Improved Weather Radar Hi, Tim Moore has been hard at work recently (with the smallest of inputs by me), and has ported the improved weather radar already available for plib to OSG. The patches are here: ftp://abbeytheatre2.org.uk/fgfs/instrumentation/osg/ And a reminder of the improvements available: raw radar contacts etc, and most important, no longer requires some convoluted .XML here: ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/radar.jpg ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/radar1.jpg ftp://abbeytheatre2.org.uk/fgfs/Screen-shots/radar2.jpg Vivian We now have the improved weather radar code available for plib and osg, originally written by Harald Johnsen, extensively modified by me, and ported to OSG by Tim Moore. Csaba Halász is busy extending this into a very clever Airport Surveillance Radar for use in Control Towers. Unless there are substantive objections, I intend to get this code into cvs-HEAD and cvs-PLIB over the coming weekend, so that we can more easily move on to some future enhancements. Probably the only user of the full range of features of this radar is the KC-135. We intend to develop this instrument into a more generalised facility so that it could be used for example in the E3B. Tim Moore has some embryo plans for adding ground echoes. We have yet to port 3D clouds to osg, so there is no weather to display on the osg version of wxradar. In the longer term we would like to retire the clumsy .XML implementation of a radar. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
John Sent: 15 June 2007 16:26 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar Vivian Meazza wrote: embryo plans for adding ground echoes. We have yet to port 3D clouds to osg, so there is no weather to display on the osg version of wxradar. FWIW... Unfortunately, I won't have any time for about two or three months, but might suggest a relook at Mark Harris' code for 3D clouds as a candidate to port to OSG. I personally liked the look and feel of the clouds produced by his algorithms over the current version I rather agree with you, I don't recall the reason for the changeover. Perhaps someone could enlighten us? The new 3d clouds have potentially lots of good features like rain and turbulence, but I'm not sure we use them. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ code beautifier / Coding
Alexis Csaba Halász a écrit : Looks like tacan is the magic word to make Vivian mad ;) Don't worry, Csaba, TACAN works again now... Whoa. I'm sorry I was out last night and haven't had a chance to properly test that nice little patch (although I see that it has been committed to my code). Did you test it with MP as well? My (untested) analysis indicates that it should work, but I can't confirm that till later today. But AAR seem to be broken too... Yesterday first tests show that contact don't behave has expected. I'll try to confirm this today. Due to the unfortunate multiplicity and unnecessary duplication of aar code this is going to be a significant task to find, test and fix in the run up to a release. And right now I think we have a problem in that a tanker will show up as an ordinary AIAircraft over MP, so we might need separate code to cope with both situations. I don't have time right now to embark on investigating that. Some bad-tempered mail started showing up on this list recently. For me flightgear is great fun both flying and coding and I intend to keep it that way. So everybody be nice and don't get mad at each other, okay? Sure :) We are a good team *and* we enjoy flaming. I don't, and I don't want to be wound up enough to do it: it's not good for my blood pressure. Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
