Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: fails in the end. After the 'standard' shapefile-based scenery has proven to work we can start tackling issues like the Great Lakes shorelines and such. The SRTM water body dataset seems to give some nice improvements on this front. It does need smoothing though, since all the points are the SRTM "pole" locations - so when viewed close up it's just made up a lots of perpendicular lines. Jon _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Stefan Seifert wrote: > Martin Spott wrote: >> You can zoom in and see, if the curves match your expectation and so >> on. O.k., you probably should not submit your very first try but the >> second one might be a good guess. If the result in FlightGear looks >> much worse, then blame Curt :-) >> > But how do I know what's wrong about the first try? I simply redid my favourite airport from scratch a second time, profiting from the expience I gained the first time and because I had the desire to make it nearly perfect, I redid it a third time before submitting :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: Then, why don't you simply post a link to your work and ask someone else to have a look at it. I didn't feel offended by your decision not to try TaxiDraw, I simply can't follow your argument. That's actually an interesting idea. Didn't occur to me. So if someone wants to see my first steps in TaxiDraw, here it is... Nine LOAB.dat Description: MPEG movie _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NOTIFICATION: List server change!!!
"Curtis L. Olson" wrote: > Thanks for your patience, cooperation, and understanding as we make this > move to a new list server. Will you take care of those accounts that have mail delivery disabled ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: You can zoom in and see, if the curves match your expectation and so on. O.k., you probably should not submit your very first try but the second one might be a good guess. If the result in FlightGear looks much worse, then blame Curt :-) But how do I know what's wrong about the first try? There are only two ways and like you said submitting it right away is probably not the best idea, which leaves only generating the scenery, which may be too difficult for some. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Stefan Seifert wrote: > I just wanted to point out, that the reason for so few people (if it > really are few) use it yet is, that it may be just too difficult and/or > time consuming to start using it. I actually took some hours to port > TaxiDraw to wxGTK-2.6 so I could finally compile it. I took an easier route and used wxX11-2.4 for TaxiDraw :-) O.k., I admit that I had a very urgent desire to get a certain airport accepted into the airport database that there was almost no room for investigation if I like TaxiDraw or not > I normally try to get something into the best shape possible before > submitting my work. Using TaxiDraw for the first time and not knowing if > I did it anything nearly correct, I just didn't feel comfortable > submitting it. Then, why don't you simply post a link to your work and ask someone else to have a look at it. I didn't feel offended by your decision not to try TaxiDraw, I simply can't follow your argument. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Karsten Krispin wrote: > Am Dienstag, 20. Dezember 2005 22:05 schrieb Martin Spott: > just submit your >> airport and you'll see how it looks after the next scenery update. > [...] Do you contribude C++-Code to CVS without > testing it for functionality or even for syntac correctness, you don't, > right? > > And in particular this is the same with Taxiways: > I don't believe that what I see in TaxiDraw is exactly what I get in FGFS. To > become clear: Taxiways without centerlines, because the taxiway is to big; > wrong overlapping curve-tiles (immitating a curve with many small rects, you > know..) and so on. To my experience the 'preview' in TaxiDraw gives a pretty good guess what you have to expect. This one for example: http://document.ihg.uni-duisburg.de/bitmap/FGFS/LCHM-screen05.jpg You can zoom in and see, if the curves match your expectation and so on. O.k., you probably should not submit your very first try but the second one might be a good guess. If the result in FlightGear looks much worse, then blame Curt :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! ---------- _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Am Dienstag, 20. Dezember 2005 22:05 schrieb Martin Spott: just submit your > airport and you'll see how it looks after the next scenery update. Hi Martin, but that's the point where Stefan and I and probably many other don't agree with. When I produce something, I want to see the result before pulluting the FGFS-Enviroment with broken stuff. Do you contribude C++-Code to CVS without testing it for functionality or even for syntac correctness, you don't, right? And in particular this is the same with Taxiways: I don't believe that what I see in TaxiDraw is exactly what I get in FGFS. To become clear: Taxiways without centerlines, because the taxiway is to big; wrong overlapping curve-tiles (immitating a curve with many small rects, you know..) and so on. Karsten _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: I usually don't judge a piece of software after just one single use - I wonder how you managed to stick to FlightGear as it definitely has some rough edges for the first-time user. Having at least a second try with TaxiDraw does not only get you into routine, you probably also have the chance to explore additional features. _And_, you don't have to build the scenery - just submit your airport and you'll see how it looks after the next scenery update. I'm sorry, I did not want to offend anyone and I for sure did not judge TaxiDraw. If I had to, I'd say it's a great tool, as it allowed even me to somehow model that airport quite easily. I just wanted to point out, that the reason for so few people (if it really are few) use it yet is, that it may be just too difficult and/or time consuming to start using it. I actually took some hours to port TaxiDraw to wxGTK-2.6 so I could finally compile it. Never submitted the patch though, because someone else obviously did the same and without CVS history it was nearly impossible to merge the changes. I'm for sure no one that gives up too early because of a few rough edges. I normally try to get something into the best shape possible before submitting my work. Using TaxiDraw for the first time and not knowing if I did it anything nearly correct, I just didn't feel comfortable submitting it. Also like I said, it's not too much fun to do something and having to wait for months before being able to try it out and see the results. Maybe I, or someone else finds the time somewhere to try to make the scenery generation part easier. So I hope you accept my apologies. Nine _______________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] NOTIFICATION: List server change!!!
Please read this message carefully!!! It applies to YOU! (and to everyone else involved in the FG project.) In order to balance resource usage, I am moving the FlightGear mailing lists to SourceForge. (http://www.sourceforge.net) You do not have to be a registered sourceforge user to use the sourceforge mailing lists, you can participate with any valid mailing address. You will be automatically unsubscribed from the [EMAIL PROTECTED] mailing lists (very soon), and automatically subscribed to the corresponding [EMAIL PROTECTED] mailing lists (this is happening now.) This might be a good time to evaluate which lists you want to be subscribed to (or not) and update your subscription options. If you have receive/don't receive options and digest options enabled for your flightgear lists, you will have to manually set these options yourself on the new lists. If you have any problems or questions, please ask. We are trying to make this switch-over as seamless and as painless as possible, but there are bound to be small glitches here and there. If you recently subscribed or unsubscribed to any of the FlightGear lists, please check to make sure that you are on/off the corresponding source forge lists. I have made every attempt to catch everyone, but I know a couple of the most recent subscribes and unsubscribes will be missed. Thanks for your patience, cooperation, and understanding as we make this move to a new list server. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Paul Surgeon wrote: We're still stuck not being able to model airports properly. TaxiDraw is a great tool but I really don't like being limited to rectangular taxiway sections - they look awful. I started playing with the idea of modeling them as a 3D model in Blender and sticking that into the terrain instead. Yes it's a lot slower but you can get things spot on like the real thing. A few decent, well known airports would be nice in FG. I'm sure Curt would love to include a few dozen of them everytime he does a scenery rebuild. :P What would be really helpful though is a way to snap the vertices of the terrain in fgsd to the vertices of a placed model to eliminate seams or a way of converting a 3D model to one of those special binary model files that the airports are in. (*.btg.gz) In the long term an automatic airport slicer/cutter would be the best option. Pre-generate or generate an airport on the fly and cut and stitch it into the underlying terrain at run time. Hi Paul, We have had past discussions about making FG specific extensions to the X-Plane airport format and possibly maintaining the extra data ourselves. Curved taxiways is very high on that list, as well as some (yet to be determined) way to lay down arbitrary taxiway and hold short markings on top. That won't let you do every thing you want to do, but could be a big step in the right direction and make future airport building better and faster. (If you haven't noticed, I like to concentrate my effort on the db/algorithms side of life, rather than the one-off hand modeling side of life.) In terms of matching airport cutouts, you could provide an exact hole to the terragear scenery builder and it would honor that and leave that exact hole cut out of the scenery. There are some issues when a hole crosses tile boundaries, you might get some transformation/math errors so your points end up being up to a pixel off (from frame to frame) in the tiles that don't own the airport object. One idea to work around this problem is to build small skirts around the airport and the cutout. That hides the gaps pretty well if both sides have skirts. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Hi, Paul Surgeon schrieb: We're still stuck not being able to model airports properly. TaxiDraw is a great tool but I really don't like being limited to rectangular taxiway sections - they look awful. Work is under way for major modifications to TaxiDraw, which also target different modelling possibilities. However, this is nothing which is done in a day or even seven days ;-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Stefan Seifert wrote: > Well, TaxiDraw is it's own story. Took me some hours to get it running > (due to wxGTK incompatibilities that are worked on in the CVS version). > Did one airport as good as I could but never submitted because actually > looking at the result would have taken me several more hours to play > with terragear and scenery generation, which I just did not have then. > > That's not really encouraging to do more. I usually don't judge a piece of software after just one single use - I wonder how you managed to stick to FlightGear as it definitely has some rough edges for the first-time user. Having at least a second try with TaxiDraw does not only get you into routine, you probably also have the chance to explore additional features. _And_, you don't have to build the scenery - just submit your airport and you'll see how it looks after the next scenery update. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Paul Surgeon wrote: We're still stuck not being able to model airports properly. TaxiDraw is a great tool but I really don't like being limited to rectangular taxiway sections - they look awful. NURBS surface primitives would be a great tool instead of being stuck to rectangles; of course, a further conversion to triangles would be necessary but that could be accomplished with a postprocessing algorithm, right before including the taxiways into the final airport file. Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
On Tuesday 20 December 2005 18:17, Dave Culp wrote: > I'm still itching to get the approach light structures working at KSFO, and > I think Curt's improvements will allow accurate modeling of unusual > airports, like KLGA, where both runways are extended out over the water on > "decks". We're still stuck not being able to model airports properly. TaxiDraw is a great tool but I really don't like being limited to rectangular taxiway sections - they look awful. I started playing with the idea of modeling them as a 3D model in Blender and sticking that into the terrain instead. Yes it's a lot slower but you can get things spot on like the real thing. A few decent, well known airports would be nice in FG. I'm sure Curt would love to include a few dozen of them everytime he does a scenery rebuild. :P What would be really helpful though is a way to snap the vertices of the terrain in fgsd to the vertices of a placed model to eliminate seams or a way of converting a 3D model to one of those special binary model files that the airports are in. (*.btg.gz) In the long term an automatic airport slicer/cutter would be the best option. Pre-generate or generate an airport on the fly and cut and stitch it into the underlying terrain at run time. Paul ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Sim Reset
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Vassilii Khachaturov schrieb: > IIRC a destructor can't call virtual methods, so if the interface > needs to do some kind of cleanup it can only be something pertaining > to this instance and using just the compile-time resolved calls. > I haven't looked at the code you cite above so this might be irrelevant > there, but I am a bit suspicious because of the name "FGInterface" that > hints at an abstract class. Not knowing if it helps (I don't even know about what part of the code you are talking about): Virtual functions can be avoided in many cases by using the so called Barton-Nackman trick (http://en.wikipedia.org/wiki/Barton-Nackman)... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDqFJFlhWtxOxWNFcRAr5eAJ42G38BOCWzN5QysINniU+2Tfp9sQCgt81Q 12s6Yq3RH93GlvlN3FUmcyA= =iW5n -END PGP SIGNATURE- ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Martin Spott wrote: Dave Culp wrote: Adding to that, think of the Scenery Objects database. This database has been live for several months now and we're far from the situation where we have to queue submissions because we can't cope with the workload. The opposite is the case: I'm happy for every contribution. Think of TaxiDraw: This is a great tool for creating or improving airport layouts. It appears to me that the number of X-Plane users employing TaxiDraw for their airport layouts supersedes the number of FlightGear-TaxiDraw users significantly. Well, TaxiDraw is it's own story. Took me some hours to get it running (due to wxGTK incompatibilities that are worked on in the CVS version). Did one airport as good as I could but never submitted because actually looking at the result would have taken me several more hours to play with terragear and scenery generation, which I just did not have then. That's not really encouraging to do more. Nine _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OT: Flightdeck UI
This is a bit off topic, but I know there are a few sysadmin/unix weenies that hang out here (myself included) so this might be of interest to a few people. Flightdeck-UI is an open source/free software project that utilizes the ideas in aircraft controls and instruments design for creating general purpose user interfaces. http://www.openlight.com/fdui/ That's intriguing in and of itself. From the screeshots (http://www.openlight.com/fdui/screens.html) and demo (http://www.openlight.com/fdui-panels/) it appears to be most useful as a system (or multi variable) monitoring tool. I'm not sure if it's poised to knock KDE/Gnome off the top of the heap, but it's an interesting project. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b1900d logo
syd wrote: > I see from user screenshots that my idea of a transparent logo for the > B1900d was a bad idea . I always assume that if it works on my computer > it must work on everyone else's:) BTW, my screenshot overhead the Tempelhof building was done on Win32, the logo looks correct on XOrg with the OpenSource ATI r200 driver without shadows. I just don't own a computer (I don't own any PeeCee at all ) that is powerful to display shadows, so I have to eomploy some Windows machine if I want to profit from all those nice features. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Dave Culp wrote: > On Tuesday 20 December 2005 09:55 am, Martin Spott wrote: >> ... After the 'standard' shapefile-based scenery has >> proven to work we can start tackling issues like the Great Lakes >> shorelines and such. > > I think whoever is the gate keeper for scenery improvements is going to be a > VERY busy person! Well, you know, a really good plan (TM) per se includes guidelines on how to distribute the workload :-) I'm confident that when we announce our plan to the community, this plan is clear enough about the submission guidelines that the people involved will manage to handle the submissions that might show up. Adding to that, think of the Scenery Objects database. This database has been live for several months now and we're far from the situation where we have to queue submissions because we can't cope with the workload. The opposite is the case: I'm happy for every contribution. Think of TaxiDraw: This is a great tool for creating or improving airport layouts. It appears to me that the number of X-Plane users employing TaxiDraw for their airport layouts supersedes the number of FlightGear-TaxiDraw users significantly. Creating Scenery Objects or airport layouts as well as tweaking landcover data involves a certain amount of work for the contributor himself and I think this effect alone will prevent us from being covered with contributions for a while Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! ------ _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Melchior FRANZ -- Tuesday 20 December 2005 02:22: > * Ampere K. Hardraade -- Tuesday 20 December 2005 02:00: > > I'm not too excited about having to create another instance of the wings. > > Good news for you: you don't have to do *anything*! (Was the bitching > on IRC not enough?) Umm ... sorry for the harsh reply. You wanted a better solution, and "bitching" (or rather: criticizing the current approach) was a good ... or at least a working way to achieve that. :-) The best approach would probably be to have a generic "morph" animation (for parachutes etc.), and a special "bend" animation that works well for wings. These would then *too* work with ssgTween, but not require two or more instances, but just one from which the others are calculated at init time (using Ralf's magic formula). The first step will, of course, be to make the ssgTween thing work with "morph". (We could make our own interpolator, but this could well face the same problems.) m. _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b1900d logo
Jean-Yves Lefort wrote: As far as I know, rotation speed with no flaps and a service payload is about 105/110 kts. I could lift it at that speed some weeks ago, but some changes in the yasim code and/or in the b1900d.xml file caused a regression. Looking back through CVS, I think the big change was that the fuel load got doubled. If you cut the fuel down to about 2000 lbs total I think the aircraft will return. I made a small change to the config file so the aircraft lift/drag solution is computed at 80% fuel capacity rather than 20% fuel capacity ... this makes a huge difference in bringing the numbers back closer to what I'd expect. This is a WAG though ... we need to find a POH and start double checking stall speed and climb performance numbers to make sure we are in the right ball park here. I hate to guess too much. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
On Tuesday 20 December 2005 09:55 am, Martin Spott wrote: > ... After the 'standard' shapefile-based scenery has > proven to work we can start tackling issues like the Great Lakes > shorelines and such. I think whoever is the gate keeper for scenery improvements is going to be a VERY busy person! Once we have the tools to make permanent improvements to the scenery we'll have lots of people working on their favorite locales. Airplanes? This is about airplanes? ;) I'm still itching to get the approach light structures working at KSFO, and I think Curt's improvements will allow accurate modeling of unusual airports, like KLGA, where both runways are extended out over the water on "decks". Dave ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Vassilii Khachaturov wrote: >> This next world scenery build will include SRTM2 data. In the USA I > [snip] >> My goal is to have everything done (for this round) by Jan 1 of the new >> year. But I reserve the right to push that date back in case I run into >> any new glitches. > Thanks! Don't forget to take the rest on the seventh day of the world > creation :-) Hah, good point ! I'm in favour of Curt's current approach because it enables us to iron out those glitches that might surface during the shapefile-based scenery generation _before_ we start major changes alias improvements in the landcover nomenclatura. It's always dangerous to work on two different ends of such a complex building because you never know where the problems lie if something fails in the end. After the 'standard' shapefile-based scenery has proven to work we can start tackling issues like the Great Lakes shorelines and such. Best regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! ------ _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
Vassilii Khachaturov wrote: Thanks! Don't forget to take the rest on the seventh day of the world creation :-) As I go through the process of world modeling, it become very clear that God is God and I am not even close! :-) It gives me a renewed appreciation for the immensity, complexity, beauty, and variety of our little Earth and it's surroundings. I don't feel so bad about the FG scenery shortcoming when I consider who I'm competing against. :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
> This next world scenery build will include SRTM2 data. In the USA I [snip] > My goal is to have everything done (for this round) by Jan 1 of the new > year. But I reserve the right to push that date back in case I run into > any new glitches. Thanks! Don't forget to take the rest on the seventh day of the world creation :-) Vassilii _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b1900d logo
On Tue, 20 Dec 2005 09:59:36 + (UTC) Martin Spott <[EMAIL PROTECTED]> wrote: > syd wrote: > > I see from user screenshots that my idea of a transparent logo for the > > B1900d was a bad idea . > > Don't worry, the B1900D is still several users all-time-favourite ;-) > I wouldn't care that much for the logo. I consider performance numbers > to be of higher priority: You need to reach at least 130 kts in order > to rotate (at sea level without flaps) but I'd expect such an aircraft > to rotate at significant lower speed. As far as I know, rotation speed with no flaps and a service payload is about 105/110 kts. I could lift it at that speed some weeks ago, but some changes in the yasim code and/or in the b1900d.xml file caused a regression. -- Jean-Yves Lefort [EMAIL PROTECTED] http://lefort.be.eu.org/ pgpiM3fmHe8iD.pgp Description: PGP signature ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Ralf Gerlich -- Tuesday 20 December 2005 15:16: > Just an idea, but would it help to define a specialised bending > animation instead of the general purpose morph? Why instead? Adding a "bend" animation would probably not be that hard for someone proficient with vector calculation. Which I am not. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Next world scenery build
In case anyone is wondering, I just wanted to let you all know that I am indeed working on the next world scenery rebuild. I am maintaining a little blurb on my home page with status updates and ETA's for those that are really keen on tracking my progress. This next world scenery build will include SRTM2 data. In the USA I have filled the srtm voids from the USGS DEM data, outside the usa, I simply interpolate across the voids because there are no other detailed data sources generally available. I have done quite a bit of (subtle) work on the airport generator code and there have been a few other bug fixes along the way as well. Right now I am processing the vmap0 -> shapefile conversion data. Now that our basic land use/land cover data is in shapefile format, the hope is that we will be able to use more common tools to fix and update the data for specific locations. This build will also have all the latest objects from Jon's object database. My goal is to have everything done (for this round) by Jan 1 of the new year. But I reserve the right to push that date back in case I run into any new glitches. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
Hi, Josh Babcock schrieb: Especially if there are a lot of other objects attached to it. The B-29 has over a hundred objects attached to the wings. Each of those would have to be animated with the wings, and that would mean duplicates of all of them using the tween method. Just an idea, but would it help to define a specialised bending animation instead of the general purpose morph? By defining a transformation function which could bend a structure and applying it to all meshes in a given branch at least bending the wings could be made a whole lot easier for the modellers. Such a function transforming a point p into p' could be (out of the back of my head) p'=p+k*u*((p-p0)*v)^2 where p0=(p0x,p0y,p0z) defines a fixpoint of the transformation, u=(ux,uy,uz) with defines the up-axis in which direction the mesh is bent and v=(vx,vy,vz) defines the axis along which the bending increases. k*||u|| and ||v|| define the strength of the bending, where k is a floating factor controlling the bending just like the morphing factor. Hrm, no that would still leave us with the problems regarding the other animations (center-points, rotation axes), except if these would be applied before the bending. Ah, well, I'll go back to my scenery now ;-) Regards, Ralf _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
Jon S. Berndt wrote: >>>Unfortunately, so far it only works with "solid" (unsmoothed) objects. >>>Looks like a plib bug to me, but I have yet to find the exact reason. >> >>Ahh, that would be a shame. I'm very much looking forward to see this in >>action (or better yet, see it in FlightGear). >> >>Erik > > > For wing flex (at least at first) I'm thinking that rotating the wing about > it's joint with the fuselage would be the easiest. > > Jon > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Especially if there are a lot of other objects attached to it. The B-29 has over a hundred objects attached to the wings. Each of those would have to be animated with the wings, and that would mean duplicates of all of them using the tween method. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
--- Georg Vollnhals <> wrote: > Hi Stuart, > Thanks! > How do you feel is the front-wheel steering (low speed, low rpm)? > If I look from outside the wheel points to one direction but the action > of the aircraft is very slow. > At a little bit higher speed the a/c is sliding forward dispite the > wheel direction. > Just a hint, nothing more. I don't have enough real world taxiing experience to say whether the turn rates are correct or not - most of my modifications have been to the "eye-candy" rather than seeking to correct the FDM. Of course, if anyone has a C310 and wants to give me a flight... I'll have a look at the nose-wheel animation and ensure that it matches the turn behaviour more closely - it could well be incorrect. Father Christmas is getting me a set of rudder pedals, so I'll be much more interested in taxiing soon! -Stuart ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
Thank you Jon, I thought it to be a problem just for this a/c. Now I know better and look forward .. Regards Georg EDDW ... Hi Stuart, Thanks! How do you feel is the front-wheel steering (low speed, low rpm)? ... FYI, the coming version of JSBSim will be having very much improved ground handling. Almost there ... Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] C310 Update
> Hi Stuart, > Thanks! > How do you feel is the front-wheel steering (low speed, low rpm)? > If I look from outside the wheel points to one direction but the action > of the aircraft is very slow. > At a little bit higher speed the a/c is sliding forward despite the > wheel direction. > Just a hint, nothing more. > I also wish you and your family a peaceful and happy Christmas time. > Georg EDDW FYI, the coming version of JSBSim will be having very much improved ground handling. Almost there ... Jon _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
Hi Stuart, Thanks! How do you feel is the front-wheel steering (low speed, low rpm)? If I look from outside the wheel points to one direction but the action of the aircraft is very slow. At a little bit higher speed the a/c is sliding forward dispite the wheel direction. Just a hint, nothing more. I also wish you and your family a peaceful and happy christmas time. Georg EDDW Buchanan, Stuart schrieb: --- "Buchanan, Stuart" <> wrote: Hi All, I've been working on an update for the civilian Cessna 310R, and my patches are now available for review/check-in. Thanks for all the feedback. I've updated the c310.tar.gz and quadrant.tar.gz file to fix the following issues: - mixture (and prop!) levers the wrong way around - bad top wing surfaces - alpha issues on panel. Work-around by creating a background. Not perfect, but I haven't got to the bottom of the issue. - Transparent cabin when viewed from above. Fixed by re-ordering .ac file. As before, the files are available from http://www.nanjika.co.uk/flightgear/c310/. Finally, I hope everyone has a good holiday season. -Stuart ___ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/ _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Wing motion
> > Unfortunately, so far it only works with "solid" (unsmoothed) objects. > > Looks like a plib bug to me, but I have yet to find the exact reason. > > Ahh, that would be a shame. I'm very much looking forward to see this in > action (or better yet, see it in FlightGear). > > Erik For wing flex (at least at first) I'm thinking that rotating the wing about it's joint with the fuselage would be the easiest. Jon ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Melchior FRANZ -- Tuesday 20 December 2005 10:46: > I just hoped that the transformation would somehow > be morphed, too. Steve is using tweening for his exposer, and I > would be a bit surprised if he hadn't thought of that. Hmm ... no. I take that back. Will hardly be considered by plib. Then we'd need to make the movable objects on the wing separate "morph" animations. Or something. But as long as smooth object don't work, I won't think much about that. :-/ m. _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: b1900d logo
* syd -- Tuesday 20 December 2005 04:18: > I see from user screenshots that my idea of a transparent logo for the > B1900d was a bad idea . Just use a "noshadow" animation on the logo. That's what the seahawk has yet to do, as well as others. The bo105 does since a while, although this causes a different problem there: The rotor shadow doesn't appear on the emblem. But as the b1900d doesn't have a rotor ... m. _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] b1900d logo
syd wrote: > I see from user screenshots that my idea of a transparent logo for the > B1900d was a bad idea . Don't worry, the B1900D is still several users all-time-favourite ;-) I wouldn't care that much for the logo. I consider performance numbers to be of higher priority: You need to reach at least 130 kts in order to rotate (at sea level without flaps) but I'd expect such an aircraft to rotate at significant lower speed. Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Erik Hofman -- Tuesday 20 December 2005 10:26: > Melchior FRANZ wrote: > > In theory, aileron/flap/... movements should still work. > I'm afraid they don't work properly anymore since the center > point and the normal axis' probably have changed after the animation... Yes, possibly. I just hoped that the transformation would somehow be morphed, too. Steve is using tweening for his exposer, and I would be a bit surprised if he hadn't thought of that. But I haven't looked yet. m. _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Ralf Gerlich -- Tuesday 20 December 2005 10:16: > Melchior FRANZ schrieb: > > Unfortunately, so far it only works with "solid" (unsmoothed) objects. > > Looks like a plib bug to me, but I have yet to find the exact reason. > > Maybe the normals of the faces don't get interpolated as well? (Just a > stab in the dark) That was, of course, what I was suspecting, too. There *is* code to interpolate them, and it doesn't look wrong to me. I'll ask on the plib list. The suspicious thing is that both "solid" and "smooth" sphere are made of 92 vertices. But in the scenegraph, the solid one has 540(!?), but the smooth one only the 92. And some faces of the smooth one seem to be smooth when rendered. The real problem is that only a couple of faces are rendered, while the others are just missing. Looks like a skeleton. m. _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
Melchior FRANZ wrote: At least that's how it currently (sort-of :-) works. In theory, aileron/flap/... movements should still work. But I haven't tested that yet. Good point, I'm afraid they don't work properly anymore since the center point and the normal axis' probably have changed after the animation... Erik _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
Melchior FRANZ schrieb: Unfortunately, so far it only works with "solid" (unsmoothed) objects. Looks like a plib bug to me, but I have yet to find the exact reason. Maybe the normals of the faces don't get interpolated as well? (Just a stab in the dark) Regards, Ralf _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
Tween method (for the curious ones): That's how you would current set up such an animation. First you organize your objects in the 3D modeler like so: |___wing |normal | |main | |aileron | |... | |bent |main |aileron |... where "normal" and "bent" are almost identical and best generated by copying the "normal" wing to "bent" and then manually bending that. 3D modeler apps should have tools for achieving good bending results. In the animation file you would then say: morph wing /sim/model/foo/wing-bending At least that's how it currently (sort-of :-) works. In theory, aileron/flap/... movements should still work. But I haven't tested that yet. m. ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
Melchior FRANZ wrote: Unfortunately, so far it only works with "solid" (unsmoothed) objects. Looks like a plib bug to me, but I have yet to find the exact reason. Ahh, that would be a shame. I'm very much looking forward to see this in action (or better yet, see it in FlightGear). Erik _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Sim Reset
Alex Romosan wrote: Alex Romosan <[EMAIL PROTECTED]> writes: + delete Atmosphere; Atmosphere=0; I know there's no real styleguide for FlightGear. But please let's stick to the one command per line rule. Lines are not that expensive after all :) And I think it's even more obvious, when you can look if only every odd line is a delete. delete Atmosphere; Atmosphere=0; delete FCS; FCS=0; delete Propulsion; Propulsion=0; Nine _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
--- "Buchanan, Stuart" <> wrote: > Hi All, > > I've been working on an update for the civilian Cessna 310R, and my > patches are now available for review/check-in. Thanks for all the feedback. I've updated the c310.tar.gz and quadrant.tar.gz file to fix the following issues: - mixture (and prop!) levers the wrong way around - bad top wing surfaces - alpha issues on panel. Work-around by creating a background. Not perfect, but I haven't got to the bottom of the issue. - Transparent cabin when viewed from above. Fixed by re-ordering .ac file. As before, the files are available from http://www.nanjika.co.uk/flightgear/c310/. Finally, I hope everyone has a good holiday season. -Stuart ___ Yahoo! Exclusive Xmas Game, help Santa with his celebrity party - http://santas-christmas-party.yahoo.net/ ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Sim Reset
> > On Monday 19 December 2005 21:26, Alex Romosan wrote:
> >> > The Interface is deleted and a new one is created.
> >> > That is a bit crude, but it works ...
> >>
> >> it doesn't work anymore though:
> >>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> [Switching to Thread -1223874848 (LWP 22155)]
> >> 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
> >> 237 {
> > It's hard to help for me either since I cannot preproduce ATM.
> >
> it's happened with all the jsb aircraft i've tried so far (including
> the F80 dave culp just announced). i noticed this at sfo but i just
> tried a few random airports and the same thing happens. it does not
> happen with yasim planes. again, my jsb fdm has the carrier patch
> applied.
>
IIRC a destructor can't call virtual methods, so if the interface
needs to do some kind of cleanup it can only be something pertaining
to this instance and using just the compile-time resolved calls.
I haven't looked at the code you cite above so this might be irrelevant
there, but I am a bit suspicious because of the name "FGInterface" that
hints at an abstract class.
Sorry I am overloaded with non-fgfs tasks right now --- I haven't even
pulled the last week's CVS updates and haven't reviewed them :-( ---
but maybe sharing this piece of info is better than doing nothing at all.
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Sim Reset
Alex Romosan <[EMAIL PROTECTED]> writes:
> it's happened with all the jsb aircraft i've tried so far (including
> the F80 dave culp just announced). i noticed this at sfo but i just
> tried a few random airports and the same thing happens. it does not
> happen with yasim planes. again, my jsb fdm has the carrier patch
> applied.
sorry about the noise, it turns out i had two
delete GroundCallback;
in FGFDMExec::DeAllocate(void) (in src/FDM/JSBSim/FGFDMExec.cpp). it's
probably an artifact of the carrier patch. that aside, i guess it
would make sense to set the pointers to zero right after we delete
them so things like this won't happen again.
looking at FGFDMExec::DeAllocate(void) it also looks like there are
some pointers we are deleting without setting them to zero (even
later) (GroundCallback being one of them). maybe we can apply
something like this:
Index: src/FDM/JSBSim/FGFDMExec.cpp
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/FDM/JSBSim/FGFDMExec.cpp,v
retrieving revision 1.14
diff -u -r1.14 FGFDMExec.cpp
--- src/FDM/JSBSim/FGFDMExec.cpp11 Jun 2005 08:19:16 - 1.14
+++ src/FDM/JSBSim/FGFDMExec.cpp20 Dec 2005 08:18:32 -
@@ -271,40 +271,27 @@
bool FGFDMExec::DeAllocate(void)
{
- delete Atmosphere;
- delete FCS;
- delete Propulsion;
- delete MassBalance;
- delete Aerodynamics;
- delete Inertial;
- delete GroundReactions;
- delete Aircraft;
- delete Propagate;
- delete Auxiliary;
- delete Output;
- delete State;
+ delete Atmosphere; Atmosphere=0;
+ delete FCS; FCS=0;
+ delete Propulsion; Propulsion=0;
+ delete MassBalance; MassBalance=0;
+ delete Aerodynamics; Aerodynamics=0;
+ delete Inertial; Inertial=0;
+ delete GroundReactions; GroundReactions=0;
+ delete Aircraft; Aircraft=0;
+ delete Propagate; Propagate=0;
+ delete Auxiliary; Auxiliary=0;
+ delete Output; Output=0;
+ delete State; State=0;
- delete IC;
- delete Trim;
+ delete IC; IC=0;
+ delete Trim; Trim=0;
- delete GroundCallback;
+ delete GroundCallback; GroundCallback=0;
FirstModel = 0L;
Error = 0;
- State = 0;
- Atmosphere = 0;
- FCS = 0;
- Propulsion = 0;
- MassBalance = 0;
- Aerodynamics= 0;
- Inertial= 0;
- GroundReactions = 0;
- Aircraft= 0;
- Propagate = 0;
- Auxiliary = 0;
- Output = 0;
-
modelLoaded = false;
return modelLoaded;
}
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Josh Babcock -- Tuesday 20 December 2005 02:54: > I wonder what the performance hist will be. I assume that it will > go linearly with the number of vertecies. I only had two spheres side by side in the scenery (next to the bo105 in KMRY), with 92 vertices each. They were constantly morphing into each other, back and forth. This had no impact. Of course, with a very detailed wing it could be a different matter, but I don't think that it would be a big problem. Morphing is something that you only want on a few nearby objects. And yes, it should be linear. It interpolates four float values per vertex in "full mode", but could be limited to 2 (we don't *really* need to interpolate UV coords and vertex colors :-). Unfortunately, so far it only works with "solid" (unsmoothed) objects. Looks like a plib bug to me, but I have yet to find the exact reason. m. _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Sim Reset
Mathias Fröhlich <[EMAIL PROTECTED]> writes:
> On Monday 19 December 2005 21:26, Alex Romosan wrote:
>> > The Interface is deleted and a new one is created.
>> > That is a bit crude, but it works ...
>>
>> it doesn't work anymore though:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> [Switching to Thread -1223874848 (LWP 22155)]
>> 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
>> 237 {
> It's hard to help for me either since I cannot preproduce ATM.
>
> Which aircraft, airport?
> Commandline flags?
> Your ~/.fgfs*?
it's happened with all the jsb aircraft i've tried so far (including
the F80 dave culp just announced). i noticed this at sfo but i just
tried a few random airports and the same thing happens. it does not
happen with yasim planes. again, my jsb fdm has the carrier patch
applied.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Sim Reset
On Monday 19 December 2005 21:26, Alex Romosan wrote:
> > The Interface is deleted and a new one is created.
> > That is a bit crude, but it works ...
>
> it doesn't work anymore though:
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1223874848 (LWP 22155)]
> 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
> 237 {
It's hard to help for me either since I cannot preproduce ATM.
Which aircraft, airport?
Commandline flags?
Your ~/.fgfs*?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Sim Reset
"Jon S. Berndt" <[EMAIL PROTECTED]> writes:
>> 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
>> 237 {
>>
>> (gdb) where
>> #0 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
>> #1 0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
>> #2 0x08113095 in ~FGJSBsim (this=0xb4b39e0) at JSBSim.cxx:308
>
> What on earth is logstream?
it's in SimGear/simgear/debug/. it's a class to manage the debug
logging stream (and it seems to have a problem with the destructor).
i'll try to find some time and look at this a bit more carefully.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fonts...
Hi all ...one more question . I haven't been able to solve this one either.I cant seem to get any fonts to display on a 2d panel other than LED and a default font . Ive tried all in the Font directory ,but the font doesnt appear to chance . Im trying to get a bold font for the glass cockpit on the Bravo Has anyone had any luck in this area , or am I trying to do something that isnt implemented yet ? Thanks for any help . Syd ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Sim Reset
> 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
> 237 {
>
> (gdb) where
> #0 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
> #1 0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
> #2 0x08113095 in ~FGJSBsim (this=0xb4b39e0) at JSBSim.cxx:308
What on earth is logstream?
Jon
_______
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] b1900d logo
I see from user screenshots that my idea of a transparent logo for the B1900d was a bad idea . I always assume that if it works on my computer it must work on everyone else's:).Im learning ! Syd ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] jet engine ....
I guess this question should be direct toward Andy , but is there a way to shut down the jet engine yet?Ive seen this question asked myself , so Ive been going through the code trying to figure it out on my own but its still a bit of a mystery to me ... I havent yet sorted out how the FDM's are tied together. Id be quite happy to work on it myself if someone could point me in the right direction.Im working on switches for the Citation Bravo , currently have an reasonably accurate electrical system and a crude hydraulic system (I want to try landing gear and flap failures) .Any tips would be appreciated.Thanks in advance.And Merry Christmas all ! Syd ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
Vivian Meazza wrote:
> Melchior FRANZ
>
>
>>* Jon S. Berndt -- Monday 19 December 2005 05:04:
>>
>>>Would it be possible to change the visual appearance of wing flex during
>>>flight?
>>
>>As Curt and Joacim have mentioned already, there are ways to do it:
>>
>>(A) ornithopter method: several instances of the wing. This has the
>>disadvantage that you'd need a lot of them for smooth transitions.
>>No problem for the fast moving ornithopter, but one would probably
>>need a *lot* of such instances for a glider wing.
>>
>>(B) bo105 method: wing/blade made of smaller parts that are each
>>animated with smaller rotations. Smooth movements, but the hinges
>>between them can look quite ugly. Not a big problem for the bo105,
>>because the blade is dull and black. Wouldn't work well for a shiny
>>white wing.
>>
>>(C) tween method: this isn't implemented in fgfs yet, but plib offers
>>an ssgTweenController ("A morph controller") class. Maybe "we" should
>>make it available in fgfs for wings/blades. It interpolates between
>>two or more objects with the same number of vertices&faces, so one
>>would only need two instances of the wing and could smoothly
>>interpolate. Would probably work better than either (A) or (B).
>>(see http://plib.sourceforge.net/ssg/branches.html and the
>>test application: $PLIB/examples/src/ssg/tween_test/tween_test.cxx)
>>
>
>
> The tween method would be the way to go. There might well be other
> applications for this animation: I'm thinking of pilot animation in
> particular. So the effort involved could be well worth it.
>
> Vivian
>
>
> ___
> Flightgear-devel mailing list
> Flightgear-devel@flightgear.org
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
> 2f585eeea02e2c79d7b1d8c4963bae2d
>
Ohh! Ohh! I have dibs on the Nakoma Narrows bridge! And let's see,
towers in high winds, windsocks, parachutes, giant cartoon balloons, jet
exhaust cones, smoke and fuzzy dice in the cockpit! This is gonna be
fun. I wonder what the performance hist will be. I assume that it will
go linearly with the number of vertecies.
Josh
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Ampere K. Hardraade -- Tuesday 20 December 2005 02:00: > I am looking forward to it, although I'm not too excited about having to > create another instance of the wings. Good news for you: you don't have to do *anything*! (Was the bitching on IRC not enough?) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Wing motion
On December 19, 2005 02:49 am, Melchior FRANZ wrote:
> (C) tween method: this isn't implemented in fgfs yet, but plib offers
> an ssgTweenController ("A morph controller") class. Maybe "we" should
> make it available in fgfs for wings/blades. It interpolates between
> two or more objects with the same number of vertices&faces, so one
> would only need two instances of the wing and could smoothly
> interpolate. Would probably work better than either (A) or (B).
> (see http://plib.sourceforge.net/ssg/branches.html and the
> test application: $PLIB/examples/src/ssg/tween_test/tween_test.cxx)
On December 19, 2005 04:38 am, Melchior FRANZ wrote:
> I had already started. Just have to finish now. :-)
>
> m.
I am looking forward to it, although I'm not too excited about having to
create another instance of the wings.
Ampere
_______
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Sim Reset
Mathias Fröhlich writes:
> Hi,
>
> On Monday 19 December 2005 14:10, Jon S. Berndt wrote:
>> When a sim reset is selected from the menu, what is the calling sequence to
>> the FDMs that follows? That is, which FGInterface functions are called (and
>>
>> >from where)? I thought that might be done from main.cxx, but I can't find
>> > it
>>
>> at the moment.
> The Interface is deleted and a new one is created.
> That is a bit crude, but it works ...
it doesn't work anymore though:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223874848 (LWP 22155)]
0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
237 {
(gdb) where
#0 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
#1 0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
#2 0x08113095 in ~FGJSBsim (this=0xb4b39e0) at JSBSim.cxx:308
#3 0x0806c7fc in fgInitFDM () at fg_init.cxx:1331
#4 0x0806deaa in fgReInitSubsystems () at fg_init.cxx:1922
#5 0x08221e31 in reInit (cb=0x0) at gui_local.cxx:81
#6 0x0821c4ad in do_reinit_dialog (arg=0x89b1a00) at menubar.cxx:35
#7 0x0823c845 in FGBinding::fire (this=0xd1b2820) at input.cxx:132
#8 0x0823cd2c in FGInput::doKey (this=0xc1b1cb0, k=27, modifiers=6, x=631,
y=-13) at input.cxx:258
#9 0x0823b23d in keyHandler (key=27, keymod=6, mousex=631, mousey=-13)
at input.cxx:1120
#10 0x080888c4 in callKeyHandler (k=27, mods=6, x=631, y=-13) at fg_os.cxx:73
#11 0xb7db0c4b in processEventsAndTimeouts () at glut_event.c:546
#12 0xb7db10a5 in glutMainLoop () at glut_event.c:954
#13 0x0805aca2 in fgMainInit (argc=3, argv=0xbff962e4) at main.cxx:1007
#14 0x0805a489 in main (argc=3, argv=0xbff962e4) at bootstrap.cxx:193
i haven't had time to really look at it though, but it seems to happen
only with jsb planes. anybody else sees this? i have the carrier
patches applied to the jsb fdm.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
_______
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear vs. Reality
kitts wrote: The videos are really cool! Just one question... Did you have to do a lot of adjustment for the synthetic and reality to match? Except fr maybe the FOV and the angle in the synthetic view. We haven't spent much time calibrating the two. My brother did the video editing and I think he slid things around just a bit to get them to line up a little closer ... that could be avoided if we spent 10 minutes calibrating the synthetic view to the camera. I am particularly interested in the timing (Latency etc.). Did the two appear similarly in real time during flight? The do appear similarly in real time ... however, our real time data link has some issues where it drops packets. So in real time the synthetic view is somewhat jerky, even though it averages 20fps seconds ... these come in bursts. When replaying the data for video purposes, we can interpolate through the gaps and make the video much smoother. That's sort of cheating I guess (well except that we readily admit to it.) :-) I am curious to know what hardware you use. A newer version of the onboard hardware i am working on is currently out for PCB fabrication. This UAV business is so exciting! ;-) We have a MIDG-II IMU/INS/GPS which we hope to replace soon with an xbow integrated gps/imu/ins/autopilot. Our wireless serial connection is with aerocomm radio modems which we are currently unhappy with. Video is done with Black Widow AV equipment. Aircraft is a Rascal 110 (110" wing span.) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear vs. Reality
On Monday 19 December 2005 06:43 IST, Curtis L. Olson wrote: > So here are the video links: > > http://www.flightgear.org/~curt/Models/Special/Rascal110_2/Movies/chapt1- >divx6.avi > http://www.flightgear.org/~curt/Models/Special/Rascal110_2/Movies/chapt3- >divx6.avi > > They are about 8-9 minutes each. Â Oh and for all the info I have > available on this project, you can visit my 'unofficial' project page > here: > > http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ > > Finally, Lee is building a FlightGear version of this same aircraft so > hopefully before too long it will be flyable in FlightGear (using one of > FG's built in flight dynamics engines.) Â We have a programmable > autopilot purchased for this airplane (but not yet installed/running.) Â > We are hoping to port FlightGear's PID algorithm to our flight computer > and hopefully then we can use FG to tune our PID loops (and if we don't > immediately crash we will definitely be bragging about it.) :-) The videos are really cool! Just one question... Did you have to do a lot of adjustment for the synthetic and reality to match? Except fr maybe the FOV and the angle in the synthetic view. I am particularly interested in the timing (Latency etc.). Did the two appear similarly in real time during flight? I am curious to know what hardware you use. A newer version of the onboard hardware i am working on is currently out for PCB fabrication. This UAV business is so exciting! ;-) -- Cheers! kitts _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Sim Reset
Hi, On Monday 19 December 2005 14:10, Jon S. Berndt wrote: > When a sim reset is selected from the menu, what is the calling sequence to > the FDMs that follows? That is, which FGInterface functions are called (and > > >from where)? I thought that might be done from main.cxx, but I can't find > > it > > at the moment. The Interface is deleted and a new one is created. That is a bit crude, but it works ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 2d magnetic compass bugfix, sort of
The magnetic compass in the defailt 2d panel has been broken for some time.
(worked in 0.9.8) This is the built-in magnetic compass defined in
Cockpit/panel.*xx and Cockpit/built_in/FGMagRibbon.cxx
I've got it back in operation, allthough I don't quite understand why.
Putting back the non-const getTexture() alias in panel.hxx which was
removed in a cleanup patch some time ago; panel.hxx line 470: virtual
FGCroppedTexture &getTexture () { return _texture; }
and changing back Cockpit/built_in/FGMagRibbon.cxx, line 68, to:
FGCroppedTexture &t = getTexture();
...got the compass back alright. But the finer details of C++ storage must
elude me here, because I honestly can't see what was wrong with the current
code. (The current "FGCroppedTexture t = getTexture();" should yield a new
perfectly writable FGCroppedTexture in "t", shouldn't it?)
The texture in question is altered in the following line (setting the
cropping limits) so it has to be writable.
___________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Sim Reset
When a sim reset is selected from the menu, what is the calling sequence to the FDMs that follows? That is, which FGInterface functions are called (and from where)? I thought that might be done from main.cxx, but I can't find it at the moment. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] simgear+flightgear warning cleanup
Vassilii Khachaturov wrote: Attached are 2 patches for cleaning up some build warnings, in both simgear and flightgear. Caught with gcc-4.0. Thanks Vassilli, it's been committed. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Slashdot: Seasons Givings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: > "Curtis L. Olson" wrote: > > >>P.S. I can still photoshop out most of my gray hair ... :-) > > > Being an OpenSource advocate I hope that you 'GIMP' our those grey > hairs that accidentially might happen to be where you didn't expect > them ;-) That wasn't grey hair. That was just the specular reflection of an light... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDpoJ3lhWtxOxWNFcRAqb/AJ9mGZ8YVSoQXv2Egni9VbAx0VMY6wCeNlLw ZlcOQjg+XRputVjvKYXJ158= =tDgE -END PGP SIGNATURE- _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] C310 Update
--- Joacim Persson <[EMAIL PROTECTED]> wrote: > > There are also numbers for the two pilot's seats, and luggage, in the > type > certificate. Since the sets are all located aft of the CG, the empty CG > should probably be the most fwd measure. (unless the c310 has a storage > in > the nose also) The real c310 does have a nose baggage compartment (also used for WX radar, oxygen, de-ice), but it's not included in our version. As part of my changes, I removed the rear-most passengers to move the CG forwards a bit, as I found the C310 very tail heavy. Thinking about it a bit more, I think most of the JSB Sim aircraft have a quite aft CG - I seem to remember the C182 can easily end up on its tail if you switch off the engine. I'm still working on the C310 model based on the feedback I've received, so if anyone has further comments, let me know. Regards, -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Vivian Meazza -- Monday 19 December 2005 09:55:
> > (C) tween method: this isn't implemented in fgfs yet, but plib offers
> > an ssgTweenController ("A morph controller") class.
> There might well be other applications for this animation: I'm thinking
> of pilot animation in particular.
I had already started. Just have to finish now. :-)
m.
___________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Slashdot: Seasons Givings
"Curtis L. Olson" wrote: > P.S. I can still photoshop out most of my gray hair ... :-) Being an OpenSource advocate I hope that you 'GIMP' our those grey hairs that accidentially might happen to be where you didn't expect them ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Wing motion
Melchior FRANZ
> * Jon S. Berndt -- Monday 19 December 2005 05:04:
> > Would it be possible to change the visual appearance of wing flex during
> > flight?
>
> As Curt and Joacim have mentioned already, there are ways to do it:
>
> (A) ornithopter method: several instances of the wing. This has the
> disadvantage that you'd need a lot of them for smooth transitions.
> No problem for the fast moving ornithopter, but one would probably
> need a *lot* of such instances for a glider wing.
>
> (B) bo105 method: wing/blade made of smaller parts that are each
> animated with smaller rotations. Smooth movements, but the hinges
> between them can look quite ugly. Not a big problem for the bo105,
> because the blade is dull and black. Wouldn't work well for a shiny
> white wing.
>
> (C) tween method: this isn't implemented in fgfs yet, but plib offers
> an ssgTweenController ("A morph controller") class. Maybe "we" should
> make it available in fgfs for wings/blades. It interpolates between
> two or more objects with the same number of vertices&faces, so one
> would only need two instances of the wing and could smoothly
> interpolate. Would probably work better than either (A) or (B).
> (see http://plib.sourceforge.net/ssg/branches.html and the
> test application: $PLIB/examples/src/ssg/tween_test/tween_test.cxx)
>
The tween method would be the way to go. There might well be other
applications for this animation: I'm thinking of pilot animation in
particular. So the effort involved could be well worth it.
Vivian
_______
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Jon S. Berndt -- Monday 19 December 2005 05:04:
> Would it be possible to change the visual appearance of wing flex during
> flight?
As Curt and Joacim have mentioned already, there are ways to do it:
(A) ornithopter method: several instances of the wing. This has the
disadvantage that you'd need a lot of them for smooth transitions.
No problem for the fast moving ornithopter, but one would probably
need a *lot* of such instances for a glider wing.
(B) bo105 method: wing/blade made of smaller parts that are each
animated with smaller rotations. Smooth movements, but the hinges
between them can look quite ugly. Not a big problem for the bo105,
because the blade is dull and black. Wouldn't work well for a shiny
white wing.
(C) tween method: this isn't implemented in fgfs yet, but plib offers
an ssgTweenController ("A morph controller") class. Maybe "we" should
make it available in fgfs for wings/blades. It interpolates between
two or more objects with the same number of vertices&faces, so one
would only need two instances of the wing and could smoothly
interpolate. Would probably work better than either (A) or (B).
(see http://plib.sourceforge.net/ssg/branches.html and the
test application: $PLIB/examples/src/ssg/tween_test/tween_test.cxx)
m.
_______________
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] C310 Update
On Sun, 18 Dec 2005, Jon S. Berndt wrote: The TCDS suggests the CG should be in the range, 37-42 inches (assuming our datum is the same). I think the datum is the same. (p33 in the type cert.): "Datum Forward face of fuselage bulkhead forward of rudder pedals." And from 310.xml: The XYZorigin for measurements is the bottom centre of the firewall in front of the rudder pedals; the estimates here take the bottom of the airframe directly below the bottom of the sloping front windshield, since the 3-views available are external only. There are also numbers for the two pilot's seats, and luggage, in the type certificate. Since the sets are all located aft of the CG, the empty CG should probably be the most fwd measure. (unless the c310 has a storage in the nose also) But where should AC_AERORP be placed? It's not quite at the mid point on the (mean geometrical) chord, is it? (Could it be taken from airfoil data?) _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] C310 Update
> Move the CG forward a bit, at least a 10--15". (the correct CG location > should be taken from the type certificate, which I haven't been able to > find on a quick google) The plane flies a lot better then. (better > stability and cruise alpha, when it's not flying on the stabiliser) This > also puts a little more weight on the nose gear, so it steers better while > taxiing. As it is now, the CG is actually aft of the lift. > (AC_CGLOC is, if > I understand it correctly, the CG location without the > AC_POINTMASSes, i.e. > empty plane?) A blind guess on the CG limits would be something around > 15--35% of MGC perhaps? Good suggestion, Joacim: [Make sure link appears on one line] http://www.airweb.faa.gov/Regulatory_and_Guidance_Library/rgMakeModel.nsf/0/ F7F7762D8AD84F2A86257013005A9A68/$FILE/3A10.pdf The TCDS suggests the CG should be in the range, 37-42 inches (assuming our datum is the same). Jon ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Wing motion
Jon S. Berndt wrote: Here's one I'm throwing out simply for discussion, and because it's occurred to me several times in the past: Would it be possible to change the visual appearance of wing flex during flight? I thought it might be interesting to give the wing an amount of flex dependent on load factor and wing stiffness, etc. I've got some simple equations in my old aeroelasticity textbook that might provide a simple enough algorithm. Just a thought... Check out the ornithopter in action. The basic ideas is you draw a couple different versions of the wing and then use the FG animation system to pick the appropriate one that corresponds to the current load. Or you could hinge the wing sections and animate it that way. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Wing motion
On Sun, 18 Dec 2005, Jon S. Berndt wrote: Would it be possible to change the visual appearance of wing flex during flight? Look at the rotor animations for the bo105. (when rotor is slowing down/speeding up) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
Nothing to do with Stuart's work on the c310, but a tip on the fdm (jsbsim version): Move the CG forward a bit, at least a 10--15". (the correct CG location should be taken from the type certificate, which I haven't been able to find on a quick google) The plane flies a lot better then. (better stability and cruise alpha, when it's not flying on the stabiliser) This also puts a little more weight on the nose gear, so it steers better while taxiing. As it is now, the CG is actually aft of the lift. (AC_CGLOC is, if I understand it correctly, the CG location without the AC_POINTMASSes, i.e. empty plane?) A blind guess on the CG limits would be something around 15--35% of MGC perhaps? Outside the scope of the lift and drag definitions (due to alpha) tables -- as when stalled aggressively -- the plane behaves strangely, of course. But it's not certified for acrobatics. ;) _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Wing motion
Here's one I'm throwing out simply for discussion, and because it's occurred to me several times in the past: Would it be possible to change the visual appearance of wing flex during flight? I thought it might be interesting to give the wing an amount of flex dependent on load factor and wing stiffness, etc. I've got some simple equations in my old aeroelasticity textbook that might provide a simple enough algorithm. Just a thought... Jon _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Slashdot: Seasons Givings
There is an article on slashdot this evening called "Season's Givings". http://ask.slashdot.org/askslashdot/05/12/18/1453256.shtml?tid=105&tid=95&tid=4 I feel I must respond because I know that many (if not all?) of you read slashdot, and in this season of new hope and giving you might see this article and be overwhelmingly tempted to donate something to the FlightGear project. :-) FlightGear is itself a gift from the flightgear developers, so instead of giving to the givers, I encourage you all to set your sites on the needier and worthier causes (not just now, but throughout the year.) We all watch the news and are aware of the many different issues around the world where there are people in desperate need of even the simplest basic things to survive. But I (and I suspect many others) get so caught up in our day to day stress and struggles that it is really easy to lose sight of anything beyond our own little scope of reality. So here's a little reminder and encouragement to those that care about the world, to maybe take stock of what you've given in the past year, and think about what you might give in this next year, and where you might give it most effectively. Seasons greetings from the Olsons. :-) http://www.flightgear.org/~curt/images/xmas-2005.jpg P.S. I can still photoshop out most of my gray hair ... :-) Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear vs. Reality
Buchanan, Stuart wrote: It is a wonderful project - amazing that you can get paid to do it ! ;) Well unfortunately I only get paid a very small amount of my time to do it, but maybe in the future if we can get more funding that percentage might increase ... I'm sure this has been asked before, but is the I/O fast enough that you can pilot the aircraft using the FG instruments and synthetic view? Right now the answer is no, but we suspect that we have some problems with our radio modem link. But given the limited time I (and others) have to work on the project, we haven't had a chance to dig into that particular issue. No idea if it would be useful, bit it would be cool. It definitely would be cool to be able to remotely pilot the aircraft without direct visual contact. At least if done with all the appropriate safety precautions and authorizations. It's something we hope to try in the future. With the synthetic view you can include things like restricted airspace, waypoint goals, artificially enhanced obstacles, etc. You could setup a 'virtual ils' for a perfect approach every time. We have added code to CVS (Thanks Mathias!!!) to return the lon, lat, elev of a scenery point if you click on it. In the future this point could be then fed into some external database to lookup a street address for instance. There are a lot of variations you could think of. If you did a frame grab of the video and inserted it into FG, you could click on the video and get back the lon/lat of the point you clicked on which could be useful if you spot an accident or some other incident that requires deploying some sort of emergency response. For instance, you spot an odd plume of smoke, you could fly over, try to determine if its intentinional or accidental and deploy the fire dept. accordingly. Think civilian police, fire, disaster mgmt, traffic management type applications here ... It reminds me of a quote I heard from the test pilot of the A380 (or whatever the latest huge Airbus is) when asked about his first flight in the plane - "It flew just like the simulator". Apparently the fly-by-wire system was identical Well we are pretty close to having it look the same in the flight simulator. We haven't started to make it fly the same just yet, but that will be a really interesting process I hope because we have real flight test data to contend with. We also have a student thinking about doing some wind tunnel tests on the airframe. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] FlightGear vs. Reality
>From Curt: > Subject: [Flightgear-devel] FlightGear vs. Reality > > > I've posted a few little blurbs about the UAV project I'm involved in, > so here's another one. > > First a word of explanation. > > We have an R/C plane with a camera looking 45 degrees down. The > airplane also has an expensive sensor that spits out location (lon, lat, > elevation) and attitude (pitch, roll, yaw). We have a radio modem > (wireless serial link) to feed the location/attitude data to the ground > in real time. ...snip... > My other brother then converted them > to DivX6 for me. DivX6 can by played by many open-source movie players > such as mplayer or xine. Or there is a free windows media player plugin > available here: http://www.free-codecs.com/download/DivX6.htm ...snip... > So here are the video links: > > http://www.flightgear.org/~curt/Models/Special/Rascal110_2/Movies/ > chapt1-divx6.avi > http://www.flightgear.org/~curt/Models/Special/Rascal110_2/Movies/ > chapt3-divx6.avi > > They are about 8-9 minutes each. Oh and for all the info I have > available on this project, you can visit my 'unofficial' project > page here: > > http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ > ...snip... Nice work Curt! Looks great! The EULA on the codec d/l from your link is disappointingly restrictive, though. A Rascal model in FGFS will be awesome! Regards, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear vs. Reality
--- "Curtis L. Olson" <> wrote: > I've posted a few little blurbs about the UAV project I'm involved in, > so here's another one. > > First a word of explanation. > > We have an R/C plane with a camera looking 45 degrees down. The > airplane also has an expensive sensor that spits out location (lon, lat, > > elevation) and attitude (pitch, roll, yaw). We have a radio modem > (wireless serial link) to feed the location/attitude data to the ground > in real time. We had a coworker build a photoreal 3d model of our small > > flying area. Armed with all that we can use FlightGear to show a live > synthetic view of the UAV. Hi Curt, It is a wonderful project - amazing that you can get paid to do it ! ;) I'm sure this has been asked before, but is the I/O fast enough that you can pilot the aircraft using the FG instruments and synthetic view? No idea if it would be useful, bit it would be cool. It reminds me of a quote I heard from the test pilot of the A380 (or whatever the latest huge Airbus is) when asked about his first flight in the plane - "It flew just like the simulator". Apparently the fly-by-wire system was identical. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear vs. Reality
I've posted a few little blurbs about the UAV project I'm involved in, so here's another one. First a word of explanation. We have an R/C plane with a camera looking 45 degrees down. The airplane also has an expensive sensor that spits out location (lon, lat, elevation) and attitude (pitch, roll, yaw). We have a radio modem (wireless serial link) to feed the location/attitude data to the ground in real time. We had a coworker build a photoreal 3d model of our small flying area. Armed with all that we can use FlightGear to show a live synthetic view of the UAV. We can configure the flightgear camera view to closely match the real live video camera view. We have also have a video transmitter onboard so we can play the live video + the live synthetic view side by side in real time on the ground. I can't exactly show you that, but we do have recordings of both streams that my brother edited together into 'web' movies. My other brother then converted them to DivX6 for me. DivX6 can by played by many open-source movie players such as mplayer or xine. Or there is a free windows media player plugin available here: http://www.free-codecs.com/download/DivX6.htm The two movies are 50Mb each so they are kind of large. The first movie shows the two views side by side. The second movie has the real view overlayed on top of the synthetic view, blended together. The second movie is my favorite of the two. One more bit of explanation. The accuracy of the synthetic view is obviously very dependent on the accuracy of our location/attitude sensor. The yaw estimate of our sensor at the beginning of the movie is many degrees off, but after a minute or two, it locks on pretty closely. (Note that it eventually gives accurate aircraft heading independent of wind or ground track.) Also you can see places where our ground based antenna aimer got lazy and the video fuzzes out, but in those cases you still have the synthetic view to fly from. So here are the video links: http://www.flightgear.org/~curt/Models/Special/Rascal110_2/Movies/chapt1-divx6.avi http://www.flightgear.org/~curt/Models/Special/Rascal110_2/Movies/chapt3-divx6.avi They are about 8-9 minutes each. Oh and for all the info I have available on this project, you can visit my 'unofficial' project page here: http://www.flightgear.org/~curt/Models/Special/Rascal110_2/ Finally, Lee is building a FlightGear version of this same aircraft so hopefully before too long it will be flyable in FlightGear (using one of FG's built in flight dynamics engines.) We have a programmable autopilot purchased for this airplane (but not yet installed/running.) We are hoping to port FlightGear's PID algorithm to our flight computer and hopefully then we can use FG to tune our PID loops (and if we don't immediately crash we will definitely be bragging about it.) :-) Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
Buchanan, Stuart schrieb: Hi Torsten, Hi Stuart, as Torsten reported more than I could find out when flying the plane, I just have to say that due to your work this nice plane now got back into my hangar. Thank you for your work! Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Even more Scenery Objects
Martin, thank you for the hint, it is a phantastic work! I post it into the German FlightGear forum. Regards Georg Martin Spott schrieb: http://document.ihg.uni-duisburg.de/bitmap/FGFS/EDDI_01.jpg ... Everything on: http://fgfsdb.stockill.org/models.php Cheers, Martin. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Even more Scenery Objects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Spott schrieb: > http://document.ihg.uni-duisburg.de/bitmap/FGFS/EDDI_01.jpg > > It's not that easy to create a screnshot of this large building without > losing major detail Watch it at night ! Yes, the version on http://fgfsdb.stockill.org/modelthumb.php?id=121 is great! CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDpeTSlhWtxOxWNFcRAvDRAJ9Cw23kY03palJpZKI29ODoyN4X4gCfbrbq B+VDTaUFlIM4HDYuiXt2p94= =rEMq -END PGP SIGNATURE- _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: C310 Update
--- Melchior FRANZ <> wrote: > * Buchanan, Stuart -- Sunday 18 December 2005 21:50: > > In particular a number of the surfaces are one-sided which causes > > problems when combined with transparent surfaces like the windows. > > No. That's normally caused by wrong object order in the *.ac file. > You can either re-order the objects there, or in the animation *.xml > file by listing the objects in correct order in a type-less : > > > foo > bar > I wonder if that is what is causing my issue with the panel as well... Does the above snippet order foo above bar then? -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Even more Scenery Objects
Hello, I'm glad I can tell you about recent additions to our FlightGear Scenery Objects database. The Berlin Tempelhof airport building is not only the most famous airport building I am aware of, but the model by Jens Toerring is also probably the most sophisticated Scenery Object we currently have in our collection. http://document.ihg.uni-duisburg.de/bitmap/FGFS/EDDI_01.jpg It's not that easy to create a screnshot of this large building without losing major detail Watch it at night ! Additionally I'm happy to inform you of some buildings that Mircea Lutic placed in the vincinity of the Romanian capital Bucharest, a country within the borders of geographical Europe that very few people know anything about. Everything on: http://fgfsdb.stockill.org/models.php Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: C310 Update
* Buchanan, Stuart -- Sunday 18 December 2005 21:50: > In particular a number of the surfaces are one-sided which causes > problems when combined with transparent surfaces like the windows. No. That's normally caused by wrong object order in the *.ac file. You can either re-order the objects there, or in the animation *.xml file by listing the objects in correct order in a type-less : foo bar m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
--- Torsten Dreyer <> wrote: > And there is a hole on the upper side of each wing where the upper > surface > connects to the wingtip. It looks like you "optimized" one vertex to > much. > > Oh and one more funny view is when you look from the outside at the > plane's > roof, you can see thru the windows and the bottom of the plane to the > ground. > Could be a bit scary for the passengers :-) Hi Torsten, Thanks for the feedback. There are quite a few issues with the model which is basically unchanged from the previous release ( and nothing to do with me - excuses, excuses ... ). In particular a number of the surfaces are one-sided which causes problems when combined with transparent surfaces like the windows. I think it'll take a while before I'm really au-fait with modeling and manage to fix them all. Of course mixing up the mixture levers is completely my fault for not testing thoroughly enough... -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
One more... The mixture levers are crossed: the left mixture controls the right engine and vice versa ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
Buchanan, Stuart schrieb: Hi Georg, Directory listings were switched off, though I think the files were accessible directly. I've enabled directory listings - should work OK now. -Stuart Thank you, Stuart! Downloaded the files and will give feedback as soon as I tested it (in some hours). Regards Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
> There are a number of minor issues remaining: > - For some reason I have minor alpha problems with the panel where the > outside world can be seen through the bottom edge of some instruments. I > haven't been able to get to the bottom of this. I'm not sure whether this > is an issue with my graphics card or not. I don't see the same issue with > the c182, which I used the same panel approach on. Same here with a radeon9600. And there is a hole on the upper side of each wing where the upper surface connects to the wingtip. It looks like you "optimized" one vertex to much. Oh and one more funny view is when you look from the outside at the plane's roof, you can see thru the windows and the bottom of the plane to the ground. Could be a bit scary for the passengers :-) Will now go and fly some patterns... Cheers, Torsten ___________ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
--- Georg Vollnhals wrote: > > Hi Stuart, > I can see the nice screenshot but cannot download the files, anything > seems to be broken with the link. > Would you please check it? Hi Georg, Directory listings were switched off, though I think the files were accessible directly. I've enabled directory listings - should work OK now. -Stuart ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C310 Update
Hi Stuart, I can see the nice screenshot but cannot download the files, anything seems to be broken with the link. Would you please check it? Thank you Georg EDDW Buchanan, Stuart schrieb: Patch files are available from http://www.nanjika.co.uk/flightgear/c310/ .. Feedback is greatly appreciated. Regards, Stuart Buchanan _ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG version CVS: Bug in --config command line parameter handling and preferences.xml
On Sun, 2005-12-18 at 15:26 +0100, Frederic Bouvier wrote: > George Patterson wrote : > > >On Sun, 2005-12-18 at 14:51 +0100, Frederic Bouvier wrote: > > > > > >>George Patterson wrote : > >> > >> > >> > >>>Hi all, > >>> > >>>I have found a bug in the parsing of the --config command line > >>>parameter. Starting Flightgear, I noticed that the menu bar is using the > >>>default(blue) menu bar rather than the alternative black one. Which > >>>indicated that my preferences.xml isn't being loaded, rendering options > >>>was "reset" to the default. > >>> > >>>Also probably related is when exiting from fgfs, the error "Error > >>>creating directory: home/gpatterson/.fgfs". .fgfs is my home direxctor > >>>already exists with appropriate permissions. It looks like the leading > >>>slash is being dropped. > >>> > >>>Version: CVS > >>>command: fgfs --aircraft=b1900d > >>> > >>>I will send a strace if required. > >>> > >>> > >>> > >>> > >>Does this patch improve things ? > >>http://frbouvi.free.fr/flightsim/sg_path.patch > >> > >>-Fred > >> > >> > > > >Fred, > > > >I have applied the patch and rebuilt Simgear and Flightgear.. > > > ># patch sg_path.cxx sg_path.patch > >patching file sg_path.cxx > >Hunk #1 succeeded at 213 with fuzz 1. > > > >However, I am now getting this error instead (double slashes) > >Error creating directory: //home/gpatterson/.fgfs > > > >Why would Simgear be trying to create a directoy that already exists? > > > > > > Not sure you have the latest CVS. Your sg_path.cxx file should be > revision 1.17. Is it the case ? > > Reload the patch as I made updates to remove the // at the beginning, > and retrieve last version of the file from CVS so the patch will apply > cleanly. > > -Fred Fred, Problem solved.. I was somehow stuck on sg_path.cxx revision 1.16. Deleted it, ran cvs update, applied patch. Patch works.. Now I just have to fix my preferences.xml file :-) George ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG version CVS: Bug in --config command line parameter handling and preferences.xml
On Sun, 2005-12-18 at 15:26 +0100, Frederic Bouvier wrote: > George Patterson wrote : > > >On Sun, 2005-12-18 at 14:51 +0100, Frederic Bouvier wrote: > > > > > >>George Patterson wrote : > >> > >>> > >>Does this patch improve things ? > >>http://frbouvi.free.fr/flightsim/sg_path.patch > >> > >>-Fred > >> > >> > > > >Fred, > > > >I have applied the patch and rebuilt Simgear and Flightgear.. > > > ># patch sg_path.cxx sg_path.patch > >patching file sg_path.cxx > >Hunk #1 succeeded at 213 with fuzz 1. > > > >However, I am now getting this error instead (double slashes) > >Error creating directory: //home/gpatterson/.fgfs > > > >Why would Simgear be trying to create a directoy that already exists? > > > > > > Not sure you have the latest CVS. Your sg_path.cxx file should be > revision 1.17. Is it the case ? > > Reload the patch as I made updates to remove the // at the beginning, > and retrieve last version of the file from CVS so the patch will apply > cleanly. > > -Fred > Umm. no.. I had version 1.16 of that file. Compiling simgear/flightgear now. Regards George ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG version CVS: Bug in --config command line parameter handling and preferences.xml
George Patterson wrote : On Sun, 2005-12-18 at 14:51 +0100, Frederic Bouvier wrote: George Patterson wrote : Hi all, I have found a bug in the parsing of the --config command line parameter. Starting Flightgear, I noticed that the menu bar is using the default(blue) menu bar rather than the alternative black one. Which indicated that my preferences.xml isn't being loaded, rendering options was "reset" to the default. Also probably related is when exiting from fgfs, the error "Error creating directory: home/gpatterson/.fgfs". .fgfs is my home direxctor already exists with appropriate permissions. It looks like the leading slash is being dropped. Version: CVS command: fgfs --aircraft=b1900d I will send a strace if required. Does this patch improve things ? http://frbouvi.free.fr/flightsim/sg_path.patch -Fred Fred, I have applied the patch and rebuilt Simgear and Flightgear.. # patch sg_path.cxx sg_path.patch patching file sg_path.cxx Hunk #1 succeeded at 213 with fuzz 1. However, I am now getting this error instead (double slashes) Error creating directory: //home/gpatterson/.fgfs Why would Simgear be trying to create a directoy that already exists? Not sure you have the latest CVS. Your sg_path.cxx file should be revision 1.17. Is it the case ? Reload the patch as I made updates to remove the // at the beginning, and retrieve last version of the file from CVS so the patch will apply cleanly. -Fred _______ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG version CVS: Bug in --config command line parameter handling and preferences.xml
On Sun, 2005-12-18 at 14:51 +0100, Frederic Bouvier wrote: > George Patterson wrote : > > >Hi all, > > > >I have found a bug in the parsing of the --config command line > >parameter. Starting Flightgear, I noticed that the menu bar is using the > >default(blue) menu bar rather than the alternative black one. Which > >indicated that my preferences.xml isn't being loaded, rendering options > >was "reset" to the default. > > > >Also probably related is when exiting from fgfs, the error "Error > >creating directory: home/gpatterson/.fgfs". .fgfs is my home direxctor > >already exists with appropriate permissions. It looks like the leading > >slash is being dropped. > > > >Version: CVS > >command: fgfs --aircraft=b1900d > > > >I will send a strace if required. > > > > > > Does this patch improve things ? > http://frbouvi.free.fr/flightsim/sg_path.patch > > -Fred Fred, I have applied the patch and rebuilt Simgear and Flightgear.. # patch sg_path.cxx sg_path.patch patching file sg_path.cxx Hunk #1 succeeded at 213 with fuzz 1. However, I am now getting this error instead (double slashes) Error creating directory: //home/gpatterson/.fgfs Why would Simgear be trying to create a directoy that already exists? George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
