Re: [Flightgear-devel] Seneca II updated
Thanks, I've been looking for a good DATCOM+ example to help me understand the program. Yep, datcom is not really self explanatory :-( I learned a lot by using the examples from Bill's page http://www.holycows.net/datcom/ together with the users's manual USAF_DATCOM_UM.pdf, also linked on Bill's page. Torsten ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
On Sunday 04 June 2006 04:24, Josh Babcock wrote: Hmm, rather than force everyone to start with the P-brake engaged, why don't you just set it in your preferences.xml file? This is the sort of thing that really has nothing to to with the aircraft, and everything to do with the procedures that an individual pilot likes to follow. Of course I can set this for myself (I have quite a few changes locally on the Harrier model) but when something is as uneccesarily annoying as this I'd prefer others without that knowhow didn't have to suffer it. I completely fail to see how anyone benefits from a mad scramble for control of the aircraft on FG startup... particularly since on the carrier it's often over the side by then. This aircraft has a parking brake IRL unless I'm very much mistaken - surely it's sensible to use it here? How many pilots IRL have to jump into the cockpit of a moving aircraft and immediately hunt around for the brakes to avoid a crash? Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
AJ MacLeod wrote: I completely fail to see how anyone benefits from a mad scramble for control of the aircraft on FG startup... particularly since on the carrier it's often over the side by then. This aircraft has a parking brake IRL unless I'm very much mistaken - surely it's sensible to use it here? How many pilots IRL have to jump into the cockpit of a moving aircraft and immediately hunt around for the brakes to avoid a crash? :-)) I guess in real life the aircraft is supposed to be fixed at their location using chocks. As you are very much by yourself because FlightGear doesn't provide a ground crew that could remove the chocks for you I think the parking brake is a pretty good choice for a work-alike. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
My penny's worth...I agree... no experience IRL ...it's one of the first things I do in FG is engage the P-brake while I set up the radio/AP ...I'm working through my hanger to set this as default for all AC. :-D ene From: Martin Spott [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED],FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Harrier checkin Date: Mon, 5 Jun 2006 09:31:16 + (UTC) AJ MacLeod wrote: I completely fail to see how anyone benefits from a mad scramble for control of the aircraft on FG startup... particularly since on the carrier it's often over the side by then. This aircraft has a parking brake IRL unless I'm very much mistaken - surely it's sensible to use it here? How many pilots IRL have to jump into the cockpit of a moving aircraft and immediately hunt around for the brakes to avoid a crash? :-)) I guess in real life the aircraft is supposed to be fixed at their location using chocks. As you are very much by yourself because FlightGear doesn't provide a ground crew that could remove the chocks for you I think the parking brake is a pretty good choice for a work-alike. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
On Monday 05 June 2006 10:31, Martin Spott wrote: location using chocks. As you are very much by yourself because FlightGear doesn't provide a ground crew that could remove the chocks for you I think the parking brake is a pretty good choice for a work-alike. Oh good, someone else agrees with me :-) The email maybe sounded a bit more harsh than I intended but runaway a/c is something I have never got used to in FG (read, annoys me intensely every time!) I suppose checking that I'd closed the throttle on the JS would help when starting up, but on the carrier that's still not enough. Regarding the ground crew, I actually had thoughts about a simulated ground crew for the Camel, mostly for startup (obviously the Camel had no starter mechanism). I wouldn't like to attempt to animate 3d models of the crew, but the conversation (which after all is the important part) could be fairly easily done I think, maybe with the tutorial stuff. All I need now is some spare time, but I'm getting less of it rather than more at the moment :-| Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Winter Textures - screenshot
Martin Spott wrote: Oliver C. wrote: Does VMAP0 data has different data for salt water and freshwater? I'll investigate if the VMAP0 contains this information in principle, but I doubt. [...] Sorry, I've totally forgotten about that. No, VMAP0 doesn't know about salt/fresh water, such attribute has to be added manually (or probably by AI :-) if we like to see the difference in the FligthGear Scenery. On the other hand there are a couple of other land coverages, especially different vegetation, in VMAP0 that might make sense to be represented in the Scenery with appropriate textures like hedge rows (line data), rice fields, bamboo/cane, oasis, orchard, rubber, bananas, cotton, coffee, palms, cranberry (!), mangrove, eucalyptus and several others. I know it's difficult to create tons of vegetation textures that really make the differences noticeable, I'm just trying to point at the variety of landcover designation that will be available in the future. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Browser: old dog, new tricks
* Josh Babcock -- Sunday 04 June 2006 20:54: Melchior FRANZ wrote: It would be on my TODO list right after buying a scroll wheel mouse, if that was on my TODO list. Which it isn't. :-] Do you accept small gifts? I don't have a scroll mouse, because I don't like them. The middle button is too important on Unix to put a disturbing wheel there. Fortunately, there are other developers who could do this. All you need is a lot of patience, as getting plib patches committed isn't the easiest thing. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Browser: old dog, new tricks
Melchior FRANZ a écrit : * Josh Babcock -- Sunday 04 June 2006 20:54: Melchior FRANZ wrote: It would be on my TODO list right after buying a scroll wheel mouse, if that was on my TODO list. Which it isn't. :-] Do you accept small gifts? I don't have a scroll mouse, because I don't like them. The middle button is too important on Unix to put a disturbing wheel there. Fortunately, there are other developers who could do this. All you need is a lot of patience, as getting plib patches committed isn't the easiest thing. Did you apply for becoming a plib developer ? Hopefully, you can become the 25th ;-) Who knows ? -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Browser: old dog, new tricks
* Frederic Bouvier -- Monday 05 June 2006 14:02: Melchior FRANZ a écrit : All you need is a lot of patience, as getting plib patches committed isn't the easiest thing. Did you apply for becoming a plib developer ? No. I fear that the apathy among plib developers is infectious. :-} Seriously, I don't feel familiar with that code base yet. And the reasons why some patches are lingering on the list would still be applicable if I had access: The pending svn migration (that for some reason isn't done), the fact that there seem to be really only two pui maintainers who need to approve. I have two more patches on my disk that I don't submit because the other three are still not applied ... m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
AJ MacLeod wrote: On Sunday 04 June 2006 04:24, Josh Babcock wrote: Hmm, rather than force everyone to start with the P-brake engaged, why don't you just set it in your preferences.xml file? This is the sort of thing that really has nothing to to with the aircraft, and everything to do with the procedures that an individual pilot likes to follow. Of course I can set this for myself (I have quite a few changes locally on the Harrier model) but when something is as uneccesarily annoying as this I'd prefer others without that knowhow didn't have to suffer it. I completely fail to see how anyone benefits from a mad scramble for control of the aircraft on FG startup... particularly since on the carrier it's often over the side by then. This aircraft has a parking brake IRL unless I'm very much mistaken - surely it's sensible to use it here? How many pilots IRL have to jump into the cockpit of a moving aircraft and immediately hunt around for the brakes to avoid a crash? Cheers, AJ How many pilots still have their parking brakes set at the runway threshold? Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
Josh Babcock schrieb: dene maxwell wrote: My penny's worth...I agree... no experience IRL ...it's one of the first things I do in FG is engage the P-brake while I set up the radio/AP ...I'm working through my hanger to set this as default for all AC. :-D ene My point though, is that you only have to change one file - preferences.xml. If this is such a big deal for everyone, then it should be changed in CVS as well. Having planes override people's personal preferences is *not* the answer. Brake settings in a flight *simulator* are a personal preference, not part of an aircraft. They belong in the preferences file, not the aircraft file. Not everyone is going to agree on whether brakes should be applied at startup. If you put this in the AC file then you are guaranteed to annoy someone no matter what setting you choose. If you leave it for preferences.xml and educate people how to use their preferences file (which is really not that hard) then everyone can be satisfied. Josh Hi Josh, although I can't understand why someone would like to start a flightsim session with programmed trouble (=aircraft not in a stable position) I accept the argument that the status of the aircraft should be set up separately, ie in the preferences file. But then, please for the sake of all new FlightGear users, let us set it as parking brake ON. I assume that the majority of users would prefer this default set-up. Regards Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ..terrorgear in /opt: ./configure --no-see-plib --never-ever --basta!
Hi, ..same box, new disk, same plan, terrorgear in /opt, Plib, SimGear and TerraGear from cvs, OpenAL, FreeAlut, gpc-2.32 from source, in /opt, Debian libgts-dev, libnewmat10-dev, libalut-dev, libopenal-dev in /usr like deb's should to avoid hassle, and saying so (AFAIKI) in the cli. ./configure --no-see-plib --never-ever --basta! -like output in http://80.239.32.252/terrorgear.configure.fails . ..yes, I lost the command line history in that disk crash. No, I don't see _what_ I'm doing wrong here or in the TerraGear Howto, only that I _am_ doing something basic, wrong. Clue whacks, please. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
Am Montag, den 05.06.2006, 14:56 +0100 schrieb AJ MacLeod: On Monday 05 June 2006 13:43, Josh Babcock wrote: How many pilots still have their parking brakes set at the runway threshold? These same pilots will (hopefully :-) have been in control of the plane for a good while leading up to this point. In FG, we're suddenly dumped there, with the plane running and, in many cases, simply out of control, veering off in some unpredictable direction. ... just an idea, why not provide a starting point general aviation parking or hangar? There we can put the plane with engine off and parking brakes on. One can practice taxiing and choose a runway by wind direction. Greetings Detlef http://www.sol2500.net/flightgear I'm not claiming having the parking brake set at this point is the height of realism, just that it's slightly less bad than the alternative. I've still not heard a convincing reason why FG starting up with out of control runaway aircraft is a good idea... AJ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Browser: old dog, new tricks
Melchior FRANZ wrote: I don't have a scroll mouse, because I don't like them. The middle button is too important on Unix to put a disturbing wheel there. Fortunately, there are other developers who could do this. All you need is a lot of patience, as getting plib patches committed isn't the easiest thing. I have a Logitech MX 300. It has a wheel and a small button right above it, which does not seem intended for, but works as middle button. So I have a scroll wheel, which is quite useful sometimes and a good working middle button. Nine ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Object without texture issue
I am newbie, so excuse my ignorance :) With Blender I create an object, add texture (.rgb). Blender renders the object, texture is drawn etc. Then I export my object to an '.ac' file and copy it into proper FG scenery directory along with the texture file. When running FG my object exists, but it isn't textured (it is painted with solid red color instead). I have similar effect when exporting to '.3ds', '.obj' and other files. Does anyone have any idea if it is a problem with texture file or export operation, or something else? Regards, Kuba$ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object without texture issue
* Jakub Skibiński -- Monday 05 June 2006 21:25: With Blender I create an object, add texture (.rgb). Blender renders the object, texture is drawn etc. Then I export my object to an '.ac' file and copy it into proper FG scenery directory along with the texture file. When running FG my object exists, but it isn't textured (it is painted with solid red color instead). No error messages from plib in the terminal window? The texture is really an SGI image (and not a GIF with RBG extension, or something)? If this isn't secret stuff, then you could offer the files for download, so that we can have a look. If Blender shows the object textured, then I can only imagine that fgfs/plib doesn't find the texture. But this is not a common problem with a FAQ answer. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Wiki updates
Hello, The port from the old seedwiki to the new mediawiki (http://wiki.flightgear.org) has been completed. All links and content should be restored - if you find something missing or incorrect then let me know. Wiki backups (sql+images) can be found here : http://hellosimon.org/backups/ If anyone wants to automate transfer let me know and I can set something up. The wiki is really starting to shape up and I'd like to thank everyone who has contributed! There's definitely issues with crossover between existing documentation (FAQ, User Manual, docs-mini) and what's on or will be on the wiki. I don't think everything belongs on the wiki due to current conversion limitations (ie. wiki - pdf) and perhaps even control issues, but I do hope that most documentation finds its way to the wiki so everyone can contribute and content doesn't stagnate. Simon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
AJ MacLeod wrote: I'm not claiming having the parking brake set at this point is the height of realism, just that it's slightly less bad than the alternative. I've still not heard a convincing reason why FG starting up with out of control runaway aircraft is a good idea... I don't have a problem with it either, so long as it is done in a way that people can turn off. That's why I am saying that it should be in preferences.xml, and not all of the -set.xml files. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
True...point taken :-D ene From: Josh Babcock [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Harrier checkin Date: Mon, 05 Jun 2006 08:51:00 -0400 dene maxwell wrote: My penny's worth...I agree... no experience IRL ...it's one of the first things I do in FG is engage the P-brake while I set up the radio/AP ...I'm working through my hanger to set this as default for all AC. :-D ene My point though, is that you only have to change one file - preferences.xml. If this is such a big deal for everyone, then it should be changed in CVS as well. Having planes override people's personal preferences is *not* the answer. Brake settings in a flight *simulator* are a personal preference, not part of an aircraft. They belong in the preferences file, not the aircraft file. Not everyone is going to agree on whether brakes should be applied at startup. If you put this in the AC file then you are guaranteed to annoy someone no matter what setting you choose. If you leave it for preferences.xml and educate people how to use their preferences file (which is really not that hard) then everyone can be satisfied. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Shop til you drop at XtraMSN Shopping http://shopping.xtramsn.co.nz/home/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
Georg Vollnhals wrote: Hi Josh, although I can't understand why someone would like to start a flightsim session with programmed trouble (=aircraft not in a stable position) I accept the argument that the status of the aircraft should be set up separately, ie in the preferences file. But then, please for the sake of all new FlightGear users, let us set it as parking brake ON. I assume that the majority of users would prefer this default set-up. I agree, it should be set on in the preferences file. I know that I am in the minority being someone who sets it to off in my own. Mostly I am interested in keeping people thinking about the ramifications of some of the stuff that they put in -set.xml files. Sometimes things seem like a good idea if you don't consider all the ramifications. Just so long as everyone remembers that it isn't a preference setting unless people can set it to their own personal preference and still have it respected by the program. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
I hace always liked this idea, I know that Start-Up positions can be specified in TaxiDraw and are used in X-Plane (refer http://x-plane.org/home/robinp/apt840.htm ). It would be an added touch of realisism IMHO :-D ene From: Detlef Faber [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Harrier checkin Date: Mon, 05 Jun 2006 20:25:03 +0200 Am Montag, den 05.06.2006, 14:56 +0100 schrieb AJ MacLeod: On Monday 05 June 2006 13:43, Josh Babcock wrote: How many pilots still have their parking brakes set at the runway threshold? These same pilots will (hopefully :-) have been in control of the plane for a good while leading up to this point. In FG, we're suddenly dumped there, with the plane running and, in many cases, simply out of control, veering off in some unpredictable direction. ... just an idea, why not provide a starting point general aviation parking or hangar? There we can put the plane with engine off and parking brakes on. One can practice taxiing and choose a runway by wind direction. Greetings Detlef http://www.sol2500.net/flightgear I'm not claiming having the parking brake set at this point is the height of realism, just that it's slightly less bad than the alternative. I've still not heard a convincing reason why FG starting up with out of control runaway aircraft is a good idea... AJ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Check out the latest video @ http://xtra.co.nz/streaming ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object without texture issue
On Monday 05 June 2006 20:25, Jakub Skibiński wrote: I am newbie, so excuse my ignorance :) We are all ignorant about something. Some of us are very ignorant about most things :-) Then I export my object to an '.ac' file and copy it into proper FG scenery directory along with the texture file. When running FG my object exists, but it isn't textured (it is painted with solid red color instead). I have similar effect when exporting to '.3ds', '.obj' and other files. Does anyone have any idea if it is a problem with texture file or export operation, or something else? The texture file must be a power of two in size (i.e. 64x64 pixels, 32x256 or whatever). There will be an error message generated to warn if this is what's wrong... If that's not the problem, can you open the .ac file in a text editor and check the path to the texture file? Unless you specify a specific texture-path in XML, your texture file should be in the same directory as the model (.ac) file IIRC. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
* dene maxwell -- Monday 05 June 2006 22:32: I hace always liked this idea, I know that Start-Up positions can be specified in TaxiDraw and [...] It would be an added touch of realisism IMHO I use ac_state.nas[1], which puts the aircraft where you left it last time. This is even more realistic. :-) m. [1] http://members.aon.at/mfranz/flightgear/ac_state.nas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object without texture issue
On Monday 05 June 2006 21:25, Jakub Skibiński wrote: I am newbie, so excuse my ignorance :) With Blender I create an object, add texture (.rgb). Blender renders the object, texture is drawn etc. Then I export my object to an '.ac' file and copy it into proper FG scenery directory along with the texture file. When running FG my object exists, but it isn't textured (it is painted with solid red color instead). I have similar effect when exporting to '.3ds', '.obj' and other files. Does anyone have any idea if it is a problem with texture file or export operation, or something else? Regards, Kuba$ Are you UV mapping the object in Blender or using Blender's native image mapping as part of a material? It's possible to texture objects in Blender without explicitly creating a UV map (Blender will do the UV mapping in the backround) in which case you won't get any UV co-ordinates exported in the ac3d file. Regards Paul ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup Position ..was ..Harrier checkin
Is this specified on a per airport basis ie if I park up at NZWN then next-time start at NZPP where will I be? And if you leave the lights on does the battery go flat? ;-) :-D ene From: Melchior FRANZ [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Harrier checkin Date: Mon, 5 Jun 2006 22:44:18 +0200 * dene maxwell -- Monday 05 June 2006 22:32: I hace always liked this idea, I know that Start-Up positions can be specified in TaxiDraw and [...] It would be an added touch of realisism IMHO I use ac_state.nas[1], which puts the aircraft where you left it last time. This is even more realistic. :-) m. [1] http://members.aon.at/mfranz/flightgear/ac_state.nas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Object without texture issue
Jakub Skibiński schrieb: I am newbie, so excuse my ignorance :) With Blender I create an object, add texture (.rgb). Blender renders the object, texture is drawn etc. Then I export my object to an '.ac' file and copy it into proper FG scenery directory along with the texture file. When running FG my object exists, but it isn't textured (it is painted with solid red color instead). I have similar effect when exporting to '.3ds', '.obj' and other files. Does anyone have any idea if it is a problem with texture file or export operation, or something else? Regards, Kuba$ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Hi Jakub, might be your texture-size isn't a multiple of 2, ie 32x64, 128x128, 256x512, .. Regards Georg HeliFlyer EDDW ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup Position ..was ..Harrier checkin
* dene maxwell -- Monday 05 June 2006 23:18: [http://members.aon.at/mfranz/flightgear/ac_state.nas] Is this specified on a per airport basis ie if I park up at NZWN then next-time start at NZPP where will I be? At NZWN, of course. How could the aircraft suddenly be at NZPP when you left it in NZWN. But you can still override the saved state with --prop:state=0 And if you leave the lights on does the battery go flat? ;-) No. But most states will be preserved, such as trimming, parking brakes, lighting switches, etc. This is all on a per-aircraft basis. Teaches you to leave the aircraft on a sane place in a sane state. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Startup Position ..was ..Harrier checkin
* dene maxwell -- Monday 05 June 2006 23:34: And this is the question when I generally get flamed ;-] ..is the nasal script able to be used in 098a? Yes. If not, then it's only the missing definition of props.copy(). You can safely copy that from the cvs version of $FG_ROOT/Nasal/props.nas right into ac_state.nas, and replace all props.copy with copy. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki updates
simon wrote: There's definitely issues with crossover between existing documentation (FAQ, User Manual, docs-mini) and what's on or will be on the wiki. I don't think everything belongs on the wiki due to current conversion limitations (ie. wiki - pdf) and perhaps even control issues, but I do hope that most documentation finds its way to the wiki [...] This is _your_ opinion, other opinions may differ, mine for example. Indeed, documentation is a weak point in the history of FlightGear development. Guess why ? Because writing documentation that you can rely on and which comes in a presentable outfit is unpleasant work, you don't get fancy features out of it and feedback from the readers is very little as is support from developers in case you found something that seriously looks like a bug (while testing a features that some developer claims to be functional). If your documentation is wrong, then users will shoot you, if your documentation is correct then people take it as a matter of course. The whole thing doesn't change with the medium you use to publish the documentation - I'm playing the game for several years now, simply trust me. People had the chance to improve existing documentation for years now, everyone knew there's a manual that needs continuous maintenance but, except from very few noticeable exceptions, nobody cared. Did _you_ take at least _one_ single attempt to contribute _anything_ to the existing manual ? No, you didn't. Period. Now you set up this wonderful Wiki, (really well done, hat off), grab some information from here and there and try to make everyone believe that you created the Holy Grail of FlightGear documentation. In case your primary concern _really_ is serious and extensive documentation for FlightGear, why then didn't you add _anything_ to our manual ? Do I smell some Not Invented Here attitude ?!? The Wiki is great for collecting spreaded documentation in a central repository, although after a while you'll notice that a collection of half-baken HOWTO's, things picked from various places put together in a nice link-list doesn't make a replacement for a handbook - that you try to fight so much. I realize very well that you're attempting to censor my advertising for The Manual by the threat of deletion (which you already did twice). Don't you think censorship should be history nowadays ? In your threat you write we don't want stagnation, so why don't you do anything against it by actually contributing _content_ ? Maybe because this is much more unpleasant than creating something fancy new even if the content is old ? Maybe you should read The Manual at least once, it contains more valid information than you'd expect. If it makes you happy, you may delete the phrases that I submitted to the Wiki, this is an open platform, and, as Erik noted expressis verbis, there is no owner. Be assured that I'll re-submit those parts the next time I visit the Wiki because I _know_ they are valid. _But_, if you really have in mind censoring other people's additions, then please be honest and call this Wiki your private playground and don't propagate it as the official FlightGear Wiki. I still support your idea of having this Wiki as place of refuge for spreaded comments, README's, HOWTO's and such. Please stick to the goals you verbalised yourself. Martin. (The only single situation when you got into contact with me was one and a half years ago. These days you called me an a$$hole because I told you I was running FlightGear with a Radeon9200 using DRI drivers and you didn't manage to ge a similar setup running - on the other hand you were not willing to share details about your setup. Read the thread crease for ac3d files and speedup if you like.) -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lee Elliot-CompterSwift
On Sunday 04 June 2006 09:46, dene maxwell wrote: Hi Lee, I have some questions regarding the ComperSwift; I would like to use it in the FGLive-KOSH CD being put together by Arnt... i know under GPL I don't have to ask for permission but would like your comment... particularly as I'm missing one important figure - cruise speed :-)... I don't really have time to download/install and get : familiar with the aircraft as it will be used in an AI scenario and just need to know the basic flight parameters/performance figures I have the J3, 172P C28-161 as low speed(90knt comfortable)aircraft for the standard NOTAM approaches and there are heaps of 140knt+ aircraft to choose from (AIR New Zealand 737 ;-)...but need 5 low speed civilian aircraft. The Rascal110 also looks a good candidate to fill the fifth spot :...similar figures would be required for that too... if you would prefer to take this off list please feel free to mail be direct.. TIA :-D ene Hi Dene, I'll check the figures for you in the next couple of days but iirc cruise speed was 100 mph @ 3000 (eng) rpm, max speed 130 mph @ 3300 (eng) rpm - eng rpm quoted because the prop was geared. Actually, I've flown it quite recently, to do a bit of virtual geology over the Channelled Scab Lands in Washington state (worth a look in FG) and it seems to be flying pretty close to the right numbers, engine included. Not so sure about the handling though - it should be tail-heavy and inclined to loop if you let go of the stick, which doesn't happen in FG. Like I said though, I'll check the numbers and get back to you in the next few days. You make a good point re it being GPL'd - it is and what is in FG isn't mine. However, I think it's probably a good idea to try to talk to any people who created or subsequently developed the work because they will have done a lot of research on it and could save you a lot of time. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Harrier checkin
On Sunday 04 June 2006 08:40, Georg Vollnhals wrote: Josh Babcock schrieb: AJ MacLeod wrote: My only request at this stage is an easy one - that the aircraft starts off with the parking brake engaged. There are few things more irritating than having the fg screen fade in only to find yourself pitching off the carrier deck or into the nearest windsock! Hmm, rather than force everyone to start with the P-brake engaged, why don't you just set it in your preferences.xml file? This is the sort of thing that really has nothing to to with the aircraft, and everything to do with the procedures that an individual pilot likes to follow. I always find it irritating when an aircraft designer thinks that they know better how I want to operate in my little world than I do. josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-deve l Hi, I really did a lot of Harrier flights as I am a vertical flight fan. And so I have to state that AJ is right as you *always* have some horizontal forces when starting FG/Harrier and it is *very* annoying to move off your position if space is somehow limited (ship, special terrain) *although* I am with my fingers on SHIFT/b immediately and fast (I think at least). Ok, I solved this *for me* with starting FG with --prop:controls/gear/brake-parking[0]=1 but this is not a good general solution for other FG users not familiar with the property system. I started setting the parking brake to on for the same reason. The Harrier in this stage of development is a nice add-on but very difficult and strange to handle due to the actual flightmodel, that is a pity. But it is as difficult to develop like the helicopter flightmodel, I think. The newer versions of the Harrier have an artificial stability system which makes it a lot more easier to fly the aircraft in low speed procedures - may be the force is with us and we'll see something like that in FG some day :-) Regards Georg HeliFlyer EDDW Actually, I believe that the Harrier flight model is pretty good and is quite faithful to the real-life handling of the early Harriers. Because we can't feel the accelerations through our backsides it's almost impossible to transition and hover 'slickly' but if you're careful and steady it works. Or at least it did when I last tried it a few years ago:) LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki updates
On Mon, 5 Jun 2006 21:58:28 + (UTC), Martin wrote in message [EMAIL PROTECTED]: ... by actually contributing _content_ ? ..in precisely that process, building a new GVAC Cape Verde out of your VMap1 data and then KOSH, I am trying to get TerraGear built: http://80.239.32.252/terrorgear.configure.fails , and post with message-id: [EMAIL PROTECTED]. ..btw, how much disk space can I expect to need on this build job? (Vague idea will do) ..and it appears you left a wee annoyance bait in your Reply-to: setting again. ;o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Lee Elliot-ComperSwift
On Sunday 04 June 2006 09:46, dene maxwell wrote: Hi Lee, I have some questions regarding the ComperSwift; I would like to use it in the FGLive-KOSH CD being put together by Arnt... i know under GPL I don't have to ask for permission but would like your comment... particularly as I'm missing one important figure - cruise speed :-)... I don't really have time to download/install and get : familiar with the aircraft as it will be used in an AI scenario and just need to know the basic flight parameters/performance figures I have the J3, 172P C28-161 as low speed(90knt comfortable)aircraft for the standard NOTAM approaches and there are heaps of 140knt+ aircraft to choose from (AIR New Zealand 737 ;-)...but need 5 low speed civilian aircraft. The Rascal110 also looks a good candidate to fill the fifth spot :...similar figures would be required for that too... if you would prefer to take this off list please feel free to mail be direct.. TIA :-D ene Hi Dene, I'll check the figures for you in the next couple of days but iirc cruise speed was 100 mph @ 3000 (eng) rpm, max speed 130 mph @ 3300 (eng) rpm - eng rpm quoted because the prop was geared. Actually, I've flown it quite recently, to do a bit of virtual geology over the Channelled Scab Lands in Washington state (worth a look in FG) and it seems to be flying pretty close to the right numbers, engine included. Not so sure about the handling though - it should be tail-heavy and inclined to loop if you let go of the stick, which doesn't happen in FG. Like I said though, I'll check the numbers and get back to you in the next few days. Thank-you Lee I've managed to google 172P, PA28-161, J3 Cub, C310, Spitfire IIa and get the figures; Max Speed, Cruise Speed, Stall Speed I tried with the ComperSwift but there is precious little info apart from history type stuff. You make a good point re it being GPL'd - it is and what is in FG isn't mine. However, I think it's probably a good idea to try to talk to any people who created or subsequently developed the work because they will have done a lot of research on it and could save you a lot of time. Look forward to hearing from you. Dene _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki updates
On Monday 05 June 2006 03:16 pm, simon wrote: The port from the old seedwiki to the new mediawiki (http://wiki.flightgear.org) has been completed. Thanks Simon, The old wiki wouldn't display my XML code snippets right, and this one does so I consider it a vast improvement. Dave ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Tides in FlightGear?
Curtis L. Olson wrote: Martin Doege wrote: However, calculating the tide for a given coordinate is probably the lesser problem here (one can use xtide's output for reference, etc.) My main issue is whether the visualization of the tidal effects can somehow be done with e.g. a Nasal script (good) or by extensively modifying the FG engine itself (not so good, since the FG/SimGear source code is pretty abstract and not very well-commented IMHO) You would almost have to redo the scenery in the areas with ocean coverage to include the ocean floor elevation, then draw the ocean as a seperate layer that can be moved up and down exposing more or less of the terrain. The trick maybe to find a good sea floor elevation database that is reasonably compatible with SRTM, and mesh the two data sets seamlessly. Curt. This would have a nice side effect of autmatically creating beaches. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] JSBSim Wiki
Well, SourceForge seems to have temporarily lost the ability to post to the JSBSim mailing list, so, if I may, here's one that I'd like to publicize: [Inspired by the new FlightGear Wiki] I have set up a Wiki for JSBSim. This should help in creating a living, online, reference for JSBSim. You can find the Wiki at http://www.jsbsim.org/wiki. It's a little sparse, at the moment. Suggestions welcome. Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Wiki updates
Martin Spott wrote: simon wrote: There's definitely issues with crossover between existing documentation (FAQ, User Manual, docs-mini) and what's on or will be on the wiki. I don't think everything belongs on the wiki due to current conversion limitations (ie. wiki - pdf) and perhaps even control issues, but I do hope that most documentation finds its way to the wiki [...] This is _your_ opinion, other opinions may differ, mine for example. Indeed, documentation is a weak point in the history of FlightGear development. Guess why ? Because writing documentation that you can rely on and which comes in a presentable outfit is unpleasant work, you don't get fancy features out of it and feedback from the readers is very little as is support from developers in case you found something that seriously looks like a bug (while testing a features that some developer claims to be functional). If your documentation is wrong, then users will shoot you, if your documentation is correct then people take it as a matter of course. The whole thing doesn't change with the medium you use to publish the documentation - I'm playing the game for several years now, simply trust me. People had the chance to improve existing documentation for years now, everyone knew there's a manual that needs continuous maintenance but, except from very few noticeable exceptions, nobody cared. Did _you_ take at least _one_ single attempt to contribute _anything_ to the existing manual ? No, you didn't. Period. Now you set up this wonderful Wiki, (really well done, hat off), grab some information from here and there and try to make everyone believe that you created the Holy Grail of FlightGear documentation. In case your primary concern _really_ is serious and extensive documentation for FlightGear, why then didn't you add _anything_ to our manual ? Do I smell some Not Invented Here attitude ?!? The Wiki is great for collecting spreaded documentation in a central repository, although after a while you'll notice that a collection of half-baken HOWTO's, things picked from various places put together in a nice link-list doesn't make a replacement for a handbook - that you try to fight so much. I realize very well that you're attempting to censor my advertising for The Manual by the threat of deletion (which you already did twice). Don't you think censorship should be history nowadays ? In your threat you write we don't want stagnation, so why don't you do anything against it by actually contributing _content_ ? Maybe because this is much more unpleasant than creating something fancy new even if the content is old ? Maybe you should read The Manual at least once, it contains more valid information than you'd expect. If it makes you happy, you may delete the phrases that I submitted to the Wiki, this is an open platform, and, as Erik noted expressis verbis, there is no owner. Be assured that I'll re-submit those parts the next time I visit the Wiki because I _know_ they are valid. _But_, if you really have in mind censoring other people's additions, then please be honest and call this Wiki your private playground and don't propagate it as the official FlightGear Wiki. I still support your idea of having this Wiki as place of refuge for spreaded comments, README's, HOWTO's and such. Please stick to the goals you verbalised yourself. Martin. Martin, Let me just say that I think the Flightgear Manual is an excellent work (yes, I've read it), and I hope to be able to contribute to it. I'm not trying to steal the show or create a holy grail of documentation. I have no such delusions of grandeur. I am, however, trying to help create a resource where users and developers can pool information. I felt your paragraph on the main page of the wiki, concerning the FlightGear Manual and the bleeding edge user documentation, was out of place and disrupted the flow of the front page as I noted in my comment to you, Please move your comments to another page, off of the main page. I have no desire nor ability to censor you. After all, it is a wiki and the history and ability to edit is available to all. I'll leave it up to others to do as they see fit in this case. (The only single situation when you got into contact with me was one and a half years ago. These days you called me an a$$hole because I told you I was running FlightGear with a Radeon9200 using DRI drivers and you didn't manage to ge a similar setup running - on the other hand you were not willing to share details about your setup. Read the thread crease for ac3d files and speedup if you like.) While I don't agree with your summary, I do apologize for going off the handle and getting defensive in this case. Thanks for your efforts and comments and I'm glad you still support the wiki. Simon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
