[Flightgear-devel] Re: Autopilot GUI
On Wed, 07 Dec 2005 12:00:22 -0600, you wrote: What should be disabled? Only the Autopilot settings entry, or the whole Autopilot menu? I wouldn't add this to the KAP140, though, but rather to gui.nas' INIT function. (Currently we operate with full property paths, and when someone inserts a menu entry, the full paths might not address the same menu entry. Better have everything in the same place if possible. At least for now. I think about adding name tags to menu entries that are to be disabled/enabled for safe access.) What if the Autopilot menu entry was bound to a function in gui.nas that looks at a property for the location of the autopilot dialog. The default could point to the existing one, but an aircraft could specify the location for the autopilot it was using. I am not sure this is possible with the existing way configuration files work. The existing Autopilot settings menu could be seen as applying to the default autopilot now, and could be replaced for each autopilot. The configuration file could even be moved to the generic instruments folder or somewhere. You could have a null autopilot for when an aircraft does not define one. It asks a lot of non-technical users to modify the menubar.xml to add the dialog for an autopilot. I am happy supporting enabling/disabling a menu item, but an item still must be added to the menu bar manually, unless I am missing something. -sek ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: gui menu disable/enable diff
On Tue, 06 Dec 2005 12:41:02 -0600, you wrote: * Melchior FRANZ -- Tuesday 06 December 2005 17:50: http://members.aon.at/mfranz/menu_disable.diff [5 kB] Committed. And I forgot to mention in the cvs log message: OK'ed by Erik. :-) Oops, I missed this. Will update my cvs. -sek ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 32, Issue 19
On Tue, 06 Dec 2005 12:00:24 -0600, you wrote: * Melchior FRANZ -- Tuesday 06 December 2005 15:20: the attached patch adds an fgCommand that allows to disable/enable menu entries This should better be hooked into the property tree, so that one can directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and get the menu disabled. Working on that. Comments still welcomed, though. m. This is excellent. Yes, please do. This will at least open up access to the menu system and let the various developers of aircraft and menus make the choice of how to interact with the menu. My only caution would be possible malicious disabling of essential menus. I think the author would be exposed pretty quickly, so the benefit outweighs the risk. I suppose one could do the same with Firefox... -sek ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Autopilot Interface
On Thu, 01 Dec 2005 09:14:11 -0600, you wrote: wrong, as with the Cessna autopilot where the dialog box is invisibly disconnected from the real autopilot. Reading the digest, I am a little slow on keeping up with this thread. The built-in autopilot is not the real autopilot. In MSFS, there is one autopilot and any aircraft panel autopilots are just front ends to this. In FlightGear, there is the opportunity to completely replace the autpilot with a NASAL scripted version. This is pretty much what the KAP140 does. It does not use any features of the built-in autopilot. FlightGear enables users to define process controllers to move control surfaces. One can construct an autopilot by scripting that activates and provides data to controllers. The autopilot I NASAL scripted, does not even pay attention to the built-in autopilot. The traditional autopilot it models does not even come close to being usable. The Digitrak is a completely GPS driven autopilot using ground track and ground speed data and drives the control surfaces in a completely different way than any traditional autopilot (well, maybe a few recent digital ones are catching up). NASAL script monitors the GPS and drives process controllers to maintain GPS track. As a result, _it could not be modeled correctly in MSFS_. Only FG provided the ability to model it correctly. I could even model the three dimensional gyroscope and magnetometer it uses in heading hold mode if I were willing to write some C. Please don't think I'm being picky, this is a significant point for someone modeling offbeat technology. The confusion comes from the way FlightGear developed, first there was one built-in autopilot and a dialog was created for it. Then a process controller system was contributed. This made it possible to create a multiplicity of autopilots, which gave rise to the confusion. The problem is a technical one, of how to rework the interface so it reflects what is available in the system, which I think is the direction you're heading. -sek ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Autopilot GUI
I decided to look more closely at autopilot behavior after hearing that one could direct the Wright Flyer on autopilot. Here is the results, with a discussion afterward about the Autopilot GUI dialog. * Wright Flyer does follow the default autopilot if settings are made on the Autopilot dialog. The config (-set.xml) file does not specify settings for the default autopilot or even a SYSTEMS container. The FDM is 'larcsim' * J3Cub also follows the default autopilot if settings are made through the Autopilot dialog. The config file does specify an autopilot element and several settings are defined. However, it does not specify an autopilot in the SYSTEMS container. The FDM is 'yasim' * Cessna 172p does not follow any settings made through the Autopilot dialog. The config file specifies a SYSTEMS container. The FDM is 'jsb' Looking at the contents: J3Cub: systems electrical pathAircraft/j3cub/cub-electrical.xml/path /electrical /systems Cessna: systems autopilot pathAircraft/c172p/Systems/KAP140.xml/path /autopilot electrical !-- null electrical system path here so we can use a nasal based -- !-- model defined later in the nasal section of this file. -- path/path /electrical /systems From this, I conclude * An aircraft that does not specify autopilot as a system uses the default autopilot. * An aircraft that specifies an autopilot uses the specified autopilot in place of the default autopilot. These rules explain the behavior of the Cessna. Because it specifies an autopilot, the default autopilot is either overridden or never loaded. The NASAL scripted autopilot is loaded. Therefore, the Autopilot dialog has no effect on the aircraft. Looking at the gui code for the Autopilot dialog (autopilot.nas and autopilot.xml), they both modify properties belonging to the default autopilot: /autopilot/* As far as I know, the C code that used to be default autopilot has been completely replaced by a PID controller configuration. Given the presence of 'generic-autopilot.xml' in the Generic folder under Aircraft, my guess is that when the SYSTEM does not specify an AUTOPILOT, this is loaded instead. This is where you specify a PID controller part of the autopilot system (the panel interface and scripts are other files). One might be tempted to say that all autopilots should use the same standard autopilot properties. On the other hand, there always seem to be features that are not covered by a set of generic autopilot settings. I am unsure if there is any chance for confusion if one did try to use the same properties, given that it seems only one autopilot can be loaded at one time. It may be best if each autopilots defines its own internal property space. That leaves the Autopilot dialog. The simplest way for a Autopilot dialog to work is if the properties are standard and shared by all autopilots. There would need to be some sort of flag property to tell if an aircraft has an autopilot, but other than that the dialog would be the same. On the other hand, if autopilots come with a variety of settings not found in the generic dialog, then it would be preferable to have some system where the autopilot can replace the Autopilot dialog with one of its own or add its own dialog in. I suppose one way to look at the existing autopilot as if it were the same as an add on like the KAP140, only it just is there by default. It has a config file and its own gui dialog, just as say, the Digitrak I built does, and could be built for the KAP140. The only difference is that the Autopilot dialog is _always displayed_. I suppose it comes down to saying there will only be one autopilot dialog and forcing all autopilot code to interface to it, or someway of specifying a dialog for each autopilot. If no autopilot is specified on the aircraft, the dialog should not display at all, not even the default. As has been suggested, another solution is to create a NULL autopilot for aircraft that do not need one. This would be an autopilot config file, I suppose, with PID controllers that do nothing or just empty? Not sure. That still leaves the question of the autopilot dialog open. It would still be there and mysteriously not do anything. There needs to be a way of telling the GUI that autopilot is not supported on this aircraft, so don't display it. It is relatively simple to determine whether to show the Fuel and Payload dialog. It appears only one FDM supports fuel and payload 'yasim', which if not found, an unsupported message is displayed. However, we do not want to prohibit an aircraft from having an autopilot merely because one might think it improbable. It used to be true that fitting an autopilot to very small aircraft like the J3Cub was impossible, but with digital systems like the Digitrak, the mechanism is much less complicated and the control much more capable, so even a J3Cub might be retrofitted with an autopilot. I'd even give the Wright Flyer half
[Flightgear-devel] Re: GPS/Autopilot
On Wed, 30 Nov 2005 21:27:15 -0600, you wrote: aircraft (like GPS in MSFS). Given that the wiring can be potentially different with each aircraft, the autopilot code may need customizing each time it is placed on a panel. Ideally the instruments will be as multi-usable as possible, and nasal is probably ideal to do the plumbing. But the more complex the systems we are modelling, inevitably the more complex the sim integration will become. Let me know what you need exported from the GPS and I'll try to oblige (but bear in mind I sometimes can't get online for a few days at a time). BTW, can you remind me again where I can download your autopilot from. http://www.city-gallery.com/vpilot/flightgear/ I've stopped work on it until I learn the new electrical system. I do not need any code from the GPS. I need to know the properties it uses. The digitrak can accept a GPS data signal. It can even work off a Garmin 35, which is a GPS built in to an antenna that just provides ground track and speed. I do not pretend to know how they communicate, but there is no equivalent to a data connection in FlightGear GPS, I have to watch properties in the GPS. If you look at digitrak.nas, it uses properties from /instrumentation/gps/ to maintain GPS track. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Autopilot
On Wed, 30 Nov 2005 11:29:12 -0600, you wrote: It'll still be the same. The C172 doesn't use the generic autopilot code - it has a KAP140 autopilot model - which is controlled by clicking the buttons on the device in the cockpit. This confusion will raise its head every time a person comes to FlightGear for the first time. They will start with the Cessna and reach for the Autopilot dialog on the toolbar and wonder why it does not work. How could they know it is not hooked up for the particular aircraft and that it has a better autopilot in the virtual cockpit? One solution, I proposed, was to create a sub-menu for autopilot dialogs. There could be one for each type of autopilot, each author could create a simple dialog for settings, a default dialog would be labeled Built in-autopilot or something. It might be possible, as with the fuel dialog, to make the display conditional. If an aircraft has its own autopilot, the default dialog does not come up, but if it does not specify an autopilot, the default dialog comes up. There is a lot of confusion, because some aircraft have 2D cockpits and some have virtual cockpits with different expectations about how to interface with controls. If the aircraft has a virtual cockpit one expects to twist the knobs in the cockpit. But if it doesn't, one expects to go to the 2D panel or a dialog on the menu for radio and autopilot. Sometimes the device in the cockpit is difficult to read or adjust and the dialog is vital. My $0.02 Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wiki
On Wed, 30 Nov 2005 00:49:14 -0600, you wrote: Of course - which is where the Wiki comes in as I see it. Up to date information that's very easily kept that way... Not a replacement for the conventional docs, but I do feel the link on the FG website could be slightly more prominent - even folk who were actively looking for it have failed to find it. The wiki would be very useful place for users to find up to date, if incomplete, help with issues that are too recent or changing to make it into official documentation. If the content stays relevant long enough, the wiki can become the basis for the official documents, as in this case. It would be helpful if common ways of working with FlightGear and ways of resolving issues were posted to the wiki, even in incomplete form, they would be a big help to those new to FlightGear. A good example is the autopilot confusion. If I have time, I can add something on that today. Or for example, that it is okay to use the 0.9.8 scenery with the 0.9.9 release---something that can take much longer to update on the official website than a wiki page. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: GPS
On Wed, 30 Nov 2005 00:49:14 -0600, you wrote: I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt). Briefly, since it's late, it's only included on the c172p 2D panel (--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768 since the fonts are at 1:1 pixellation at that resolution. Now that we are seeing a choice of GPS units, it beings to raise a similar question to the autopilot. There will be confusion over the waypoint and gps dialogs on the FG toolbar. It may be necessary to do something similar as I proposed with autopilot. The approach I took to integrating GPS into my autopilot was to rely on the existing built-in GPS. I assume this is a C coded model of a generic GPS unit. It raises the issue of should instrument autopilots (that ones that appear in the cockpit) all use the same model and put a different face on them or should there be any number of gps units available? If there are many gps units coded in C, it might be wise to remove the generic one. However, then those who might want to build a GPS model based on the generic gps using NASAL might be out of luck (I'm not sure if it is possible or reasonable to implement a moving map GPS display in NASAL and instrument XML, however, a simple text display might be feasible). The autopilot I modeled is tightly integrated with a GPS unit. It needs to access GPS properties. However, this means that if there are more than one gps unit available in FG, the autopilot code must be changed to use the properties of the particular autopilot. That may not be too great an issue if instruments are supplied with particular aircraft as opposed to something generic that can be placed in any aircraft (like GPS in MSFS). Given that the wiring can be potentially different with each aircraft, the autopilot code may need customizing each time it is placed on a panel. It is nice to have a true gps unit and I have intended all along to wire my autopilot into the first good model that came along. The built-in gps is fairly primitive with no panel representation. This is just to air these issues, I do not have any conclusions. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NASAL Scripted Pushback
On Tue, 29 Nov 2005 05:57:53 -0600, you wrote: or just haven't gotten around to. Wiring up property/command interfaces for C++ subsystems is generally pretty easy. Andy Is there a list of all properties or commands available or how do I find the appropriate functions? I allready found the readme.properties, but looking at Steve's autopilot.nas I can see some more properties that are not listed in the readme. Setting a property that does not exist in the property tree creates it. This gives you the ability to create your own properties in the FlightGear property tree just by bringing them into existence in your NASAL script. I created some properties for internal use by the autopilot. The idea cane from looking at KAP140 autopilot code. You may want to look at that, which mine is partly based on. The reason for creating my own properties was to isolate properties that are special to the particular autopilot and to keep the properties organized. I did have some trouble finding out what properties are available. I looked through every .nas and XML file I could find in the distribution until I had a good idea of the properties I needed. I read the list of properties in the source documentation. I watched some properties in the property viewer (on the File menu). I am unsure if there is a complete and comprehensive list of default FlightGear properties yet. Someone should know on the list. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: NASAL Scripted Pushback
On Mon, 28 Nov 2005 06:42:53 -0600, you wrote: Here are my first questions: 1. Will Nasal scripting give me all options to program the push-back function (incl. playing sound files and checking distances to other planes or to next taxi way)? Or will I have to use c++ (if so, is there anyone who is interessted to give me some beginners support?)? 2. Why does appling a body-u-velocity not work? I am not sure of this, but NASAL can listen for properties and then change properties, so if you can take actions based on a monitored property (for example, I monitor various orientation/navigation properties to implement GPS tracking in my autopilot) and set properties that play the sounds or move the aircraft, it may be possible. I just do not know if you connect to those actions from the script. Maybe if an animation is based on a property, you could change it from script. I believe the property may be read only. Perhaps it just reports the velocity, but setting the velocity does not side effect the aircraft. It would be interesting if features like this could be added to FlightGear by creating custom GUI interfaces and use NASAL to drive the feature. I built a GUI for some features of the autopilot I modeled for which the face plate does not have any controls. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FGSF Gear Animation
On Sat, 26 Nov 2005 05:18:01 -0600, you wrote: I just made up a tutorial about making gear retraction animations run smoothly with complicated landing gears. It's still missing the final Josh, thanks. I need to learn how to animate parts, so your tutorial is welcome. I am just starting out with Blender, moving my models out of GMAX (a chore). I've had to strip off my textures and animations moving to Blender and FlightGear from MSFS/GMAX. I just posted my experiences and some helpful material on the FlightGear wiki under 3D Modeling. They are not quite complete, but should be helpful to someone in my situation and will make a start on an exporting/importing guide. Please consider adding your tutorial to the wiki as well as the FG docs. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compiling CVS on SuSE 10.0
I checked out the CVS base lat night and tried to compile with an older tarball source, which failed. I received advice through FG irc that I should check the latest FG source out from CVS. I did that tonight and the configure seemed to go normally, but the make failed: Making all in ATC make[2]: Entering directory `/usr/local/source/FlightGear-CVS/source/src/ATC' if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X 11R6/include -I/usr/local/include -g -O2 -D_REENTRANT -MT ATC.o -MD -MP -MF .d eps/ATC.Tpo -c -o ATC.o ATC.cxx; \ then mv -f .deps/ATC.Tpo .deps/ATC.Po; else rm -f .deps/ATC.Tpo; exit 1; f i ATC.cxx: In member function ‘void FGATC::Render(std::string, const std::string , bool)’: ATC.cxx:230: error: invalid conversion from ‘unsigned char*’ to ‘const char*’ ATC.cxx:230: error: initializing argument 1 of ‘SGSoundSample::SGSoundSample(c onst char*, const char*, bool)’ ATC.cxx:230: error: invalid conversion from ‘int’ to ‘const char*’ ATC.cxx:230: error: initializing argument 2 of ‘SGSoundSample::SGSoundSample(c onst char*, const char*, bool)’ make[2]: *** [ATC.o] Error 1 make[2]: Leaving directory `/usr/local/source/FlightGear-CVS/source/src/ATC' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/source/FlightGear-CVS/source/src' make: *** [all-recursive] Error 1 linux:/usr/local/source/FlightGear-CVS/source # Advice appreciated. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: freeglut on SuSE 10
Let us know how you get on, or better, if you're still stuck, ask for real-time help on the IRC channel. There has been a steady stream of such, I I've got Flight Gear 0.9.8 running. I can't thank you enough! I downloaded both RPMs from rpmfind, which I may have seen in passing during a google search, but wanted to stay safe with the official sites. It's a great site. I was getting quite a runaround chasing the SuSE docs, repositories and yast. I will try installing the CVS version soon or the prerelease. I may show up on IRC in time. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: freeglut on SuSE 10
I installed the downgrade of freeglut, but I still get a missing header error. I think this header is in the freeglut-devel but did not download that module. I cannot seem to access the 9.3 RPMs in the Yast repositories. Can someone point me in the right direction where to get these files? I can't seem to get into Guru's repository for 9.3 RPMs, it's overloaded and not responding. I also downloaded the 2.2 freeglut from their site, but don't know if I can use that. Perhaps I could pull the header from there. This is getting tiresome. Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Freeglut on SuSE 10.0
On Thu, 10 Nov 2005 02:20:42 -0600, you wrote: You are using a buggy freeglut version (2.4). Upgrade to a current CVS version, or downgrade to 2.2, they work fine. Where and how do I install 2.2 on SuSE? I tried adding a local folder to Yast as a source of RPM packages. It said okay, click here to add as RPM source. But only 2.4 shows up in package list. I tried a suggestion on the SuSE forums to issue an yast -i package.rpm command, but nothing seemed to happen. No error, nothing was added to my Yast config as far as I can tell. I am uncomfortable (prefer to let Yast handle it) issuing an rpm command, but perhaps I should try that? Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
On Wed, 09 Nov 2005 14:55:35 -0600, you wrote: I think, especially in view of the spate of posts a short while ago, it would be wise to only include (by default) aircraft which are quite complete - i.e. with populated cockpits etc. People who know what they want and what they're doing can easily download the others. It would be very helpful, and good public relations for aircraft included by default to be complete and flyable. My first impression of FlightGear on Windows was soured by the first aircraft I choose. It was the Cessna with full IFR panel. The panel was upside down and very strange. It didn't make a good first impression and left me confused. If I had not been persistent I might have gave up on it right there. Moreover, I could not figure out why there were so many Cessna's and what the differences were. An aircraft should be operational, not in a state of development if it is to be included in the official distribution. Aircraft in development can be downloaded individually. Aircraft should not be incomplete, missing panels, incomplete instruments, etc. I realize this is not easy given the open source and experimental nature of Flight Gear development. I agree with the idea of removing the UFO in favor of a more useful and complete aircraft. There are several aircraft in the collection I would prefer being in the default set over the UFO craft. However, there should be some note to developers that this is useful to download for use in scenery development. I may have overlooked it, but as far as I can tell, there is no slew mode available in FG, which makes it difficult to position a normal aircraft so you can check scenery when developing buildings, airports, etc. If the UFO is the only way to emulate slewing, then perhaps it should be retained. I would like to retain the Wright Flyer to represent aviation history. I think everyone new to flight sim wonders what it would be like to fly the Wright Flyer. However, I found it unflyable, so in the end I think it should be replaced by a more flyable aircraft. Aircraft without a 3D model should be avoided in the default distribution (No FDM only). The J3 Cub is attractively modeled and shows off what can be done with Flight Gear aircraft. It is also an easy to fly, good introductory aircraft. I decided I should ask myself, is there an aircraft now in the collection that I would prefer over one in the default? Here's my list. 737 (Boeing 737) --- Keep. A-10 (Fairchild A-10) --- Replace with Spitfire (hate to do it, but makes sense). bo105 (Helicopter) --- Keep. c172 (Cessna) --- Replace with updated Cessna 182. c172p (Cessna) --- Keep. c310 (Cessna 310) --- Replace with B1900D. c310u3a (Cessna 310) --- Keep. Citation (Citation II) --- Keep. f16 (F-16) --- Keep j3cub (J3 Cub) --- Keep. hunter (Hawker Hunter) --- Keep p51d (Mustang P-51D) --- Keep. pa38-161 (Piper Warrior) --- Keep. ufo (developer) --- Replace with PC-7. wright flyer (Wright Flyer) --- Replace with DH Beaver. It is difficult to decide when trying to fill out the categories when the best aircraft do not fall evenly into those categories. Aircraft in one category may be more complete and polished than aircraft in others. One could argue there is a place for at least one glider and one bi-plane in the default collection. If there are no glider specific areas with thermals, then I suggest leaving the glider out until more glider support is available. The only bi-plane is the Sopwith, so perhaps that can wait. Arguably, there should be a representative jet fighter aircraft, one American and one European, but if it takes away room for a general aviation, etc. perhaps only one jet fighter should be represented. And the same might be said for second world war aircraft. The P-51D and Spitfire as easy choices, since they are good models. The F16 is probably the best choice for an American jet fighter. The Hunter seems easy to fly. The same policy could be for commercial airliners. With the Boeing 737 and the Airbus A320 each being represented. At least one helicopter should be available, but if it is unflyable, I'd say replace it with something else. I think it's important to keep the most widely used general aviation craft, like Cessna and Piper and one or two major historic aircraft, such as the Cub, DC3. The Comper Swift is in the same vein as the J3, but in beta status. At least one aircraft from the early era of general aviation should be in the default package. Most users will want a light single engine general aviation aircraft they are familiar with. The Cessna fills this niche and is the most popular. I suggest one classic and one modern Cessna single. The Beaver is one of my favorite aircraft. It is both from the era I find interesting and capable of bush flying. It is slow and fairly easy to fly and can operate on water or land. A good model, if not the most refined, but lacking in hot spots on 3d cockpit controls. The Piper Warrior fills the need for a fast
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 42
On Thu, 10 Nov 2005 19:11:25 -0600, you wrote: Their last recommendation was not what we would like to see and we could say simply ignore it but a *lot* of linux user are reading this magazin and potentially flightsim interested people get the wrong impression by this review. :-( I remember what KDE was like a few years ago. I remember encountering incomplete help files with messages like sorry, have to spend more time with my girlfriend than help files. Understandable, but it is a hazard of Linux, even after all the development. SuSE is vastly improved from that time and I'm loving it, but there is always something. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: howto compile on SuSE 10.0 running gcc
On Tue, 08 Nov 2005 11:26:51 -0600, you wrote: freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutInit'. I installed freeglut, all three packages found in the SuSE library. Restarted and ran ./configure again for FG. It seems to have compiled okay without complaining about glutInit, but I am now getting this error. So I've made progress. ;-) An archive post says that the CVS version does not have this problem. Should I try the CVS version? I installed 0.9.8 because of the previous error, just to see if the version was at fault. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 29
On Tue, 08 Nov 2005 15:39:11 -0600, you wrote: On my wishlist for baltimore: martin state airport, harbor place, bethlehem steel, the hitachi cranes of the dundalk, locust point clinton st. ? marine terminals, maybe the usfg building or md national bank building downtown. One of the largest churches in the us is on a hill in baltimore (an old shopping mall) off cedonia road, Ravens or Oriole stadium, the maryland science center I have lived in Arlington, VA most of my life. Much of my simulated flying is local, so I am interested in populating the Mid-Atlantic area. It's pretty empty now. I tend to do my simulated flying on the Delmarva, but Martin State is my usual destination from the Eastern Shore. Baltimore is such a complicated airport (when flying under ATC in MSFS for example) KMTN is a simple straight in and lines up nicely with KSBY and some of the other local airports. It would be nice to see some improvements for that and for KSBY the airport I depart from the most. I am unsure if I can help, I do hope to convert a model of the Cape May Light I made for MSFS for FG once I understand the tools. I've got to get FG compiled first. ;-) Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL, SuSE and Compiling FlightGear
Okay, I installed from YAST packages for OpenAL audio (BTW was not mentioned in the instructions, but it complained and I looked up the package in YAST online update). Installed all devel packages for MESA OpenGL. plib and simgear compiled okay. I downloaded the CVS tarball, but it would not ./configure apparently does not have a ./configure file. I downloaded 0.9.8 source. When I tried to make, it complained about glut, so I installed all of the Glut development packages. Glut was already installed. When I try to make I get this: linux:/usr/local/source/FlightGear-0.9.8 # make Making all in tests make[1]: Entering directory `/usr/local/source/FlightGear-0.9.8/tests' gcc -g -O2 -D_REENTRANT -L/usr/X11R6/lib -L/usr/local//lib -o gl-info gl-info.o -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm gl-info.o: In function `main': /usr/local/source/FlightGear-0.9.8/tests/gl-info.c:61: undefined reference to `glutInit' /usr/local/source/FlightGear-0.9.8/tests/gl-info.c:62: undefined reference to `glutInitDisplayMode' /usr/local/source/FlightGear-0.9.8/tests/gl-info.c:63: undefined reference to `glutCreateWindow' collect2: ld returned 1 exit status make[1]: *** [gl-info] Error 1 make[1]: Leaving directory `/usr/local/source/FlightGear-0.9.8/tests' make: *** [all-recursive] Error 1 linux:/usr/local/source/FlightGear-0.9.8 # Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compiling FG on Suse
On Sat, 05 Nov 2005 02:22:55 -0600, you wrote: Steve, you seem to have the following missing. - C++ compiler - X delopment libraries and header files are missing - OpenGL libraries and header file Have you compiled something else other than FlightGear? Not on this installation. Everything has been installed through their package manager. I was focused on the GL library missing, but I will see if it has the C++ available. And the X development libraries. Could use a more specific message than missing X I thought it meant I hadn't go X up and running. I thought I had OpenGL support with the ATI drivers, control panel and etc. Maybe that is only direct graphics support, will look for OpenGL. Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] OpenGL on Suse
I am a little confused by the results of various sources.
linux:~ # fglrxinfo
display: :0.0 screen: 0
OpenGL vendor string: ATI Technologies Inc.
OpenGL renderer string: RADEON 9600 XT Generic
OpenGL version string: 1.3.5395 (X4.3.0-8.18.6)
The ATI control panel says the same thing.
But this says
3Ddiag
3Ddiag version 0.728
Verifying 3D configuration:
Using 3dinfo
No 3D capable graphic chipset found!
Checking GL/GLU/glut runtime configuration:
GL/GLU ... done (package xorg-x11-Mesa)
glut ... done (package freeglut)
I can run
glxgears
12656 frames in 5.0 seconds = 2531.200 FPS
watch the gears go round, etc.
I think I installed the ATI drivers correctly, it's been a week, so I
can't remember everything I did, but part of it was fglrxconfig where I
answered some questions. Not sure what they all meant.
I installed gcc-c++ and xorg-x11-devel and now it gets this far
linux:/usr/local/source/plib-1.8.4 # ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
includedir changed to ${prefix}/include/plib libdir is
${exec_prefix}/lib
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C++ preprocessor... g++ -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking build system type... i686-suse-linux
checking host system type... i686-suse-linux
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for pthread_create in -lpthread... yes
checking for glNewList in -lGL... yes
checking for dlclose in -ldl... yes
checking for ALopenport in -laudio... no
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking GL/gl.h usability... no
checking GL/gl.h presence... no
checking for GL/gl.h... no
configure: error: OpenGL header file not found
linux:/usr/local/source/plib-1.8.4 #
xorg-x11-Mesa is installed. I don't know if it should be. I know that
ATI control panel reports ATI OpenGL is in use, at least I read it this
way.
freeglut is installed; but not devel.
Steve
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Compiling Flight Gear
I am trying to compile FG for the first time on Suse Linux 10.0
following the instructions at
http://www.flightgear.org/Docs/InstallGuide/getstartch2.html
I downloaded and unpacked SimGear 0.3.8
plib-1.8.4
I ran the install for the ZLIB package, but could not find the Metakit
package, so skipped it. It was not in the src-libs folder of SimGear.
I then ran without success. I am posting this from Evolution, so I do
have an X windowing system running. I have a Radeon 9600XT. I could not
get BSD to start X using this card, I gave up and installed Suse. Works
fine. It comes with an OpenGL game GL-117, which gave a warning the
first time I tried to run it that it needed the correct library to do 3d
with my card, so I installed the necessary ATI drivers and it works.
linux:/usr/local/source/plib-1.8.4 # ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
includedir changed to ${prefix}/include/plib libdir is
${exec_prefix}/lib
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... no
checking for c++... no
checking for gpp... no
checking for aCC... no
checking for CC... no
checking for cxx... no
checking for cc++... no
checking for cl... no
checking for FCC... no
checking for KCC... no
checking for RCC... no
checking for xlC_r... no
checking for xlC... no
checking whether we are using the GNU C++ compiler... no
checking whether g++ accepts -g... no
checking dependency style of g++... none
checking how to run the C++ preprocessor... /lib/cpp
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking build system type... i686-suse-linux
checking host system type... i686-suse-linux
checking for X... no
checking for pthread_create in -lpthread... no
checking for glNewList in -lGL... no
checking for glNewList in -lMesaGL... no
configure: error: could not find working GL library
linux:/usr/local/source/plib-1.8.4 #
Any ideas what is wrong?
Thanks,
Steve
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 5
On Wed, 02 Nov 2005 12:00:09 -0600, you wrote: the aircraft are in the base package so if you wanted a gage from an aircraft that wasn't in the base package you would have to download the whole aircraft to get maybe one gage. This is the issue I have experienced with downloading aircraft. It would be better if aircraft did not share gauges but either used their own or from a central repository. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 87
On Sun, 30 Oct 2005 06:46:18 -0600, you wrote: That is extremely nifty. Yes, I'm not sure what if anything it's good for, but it's definitely nifty. :-) Flying in weather, at night? If you meant the synthetic view. It is very nifty. It is just fun to see what is possible, to be in on new technology. Of what use is a new born baby? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 88
On Sun, 30 Oct 2005 09:01:50 -0600, you wrote: KDE is a *good* Unix citizen. I wouldn't use it if it couldn't even digest two dots in a file name. If any such problems occur, you can try this: Well Windows isn't. :-) I have trouble all the time with extensionless files like readme and with any file name with more than one dot. Of course, that's not news. Is there some Unix rule against a .txt file extension. I mean there is nothing stopping one from giving text files a .txt extension, except the extra typing. It would help in the Windows distribution if the docs could have that text extension. Unless there is some way to tell Windows to try Notepad first when there is no extension. I did manage to get SuSE OSS Linux installed. So am fully back in the fold now. My hardware was just completely incompatible with FreeBSD, nForce, MS wireless mouse, Radeon 350 series...I could not get X to run and there was little chance of getting any 3d graphics to run, at least not without more work than I was willing to do. I will be installing FG from CVS. So maybe my Windows woes will be over soon. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 28
On Tue, 11 Oct 2005 18:47:00 -0500, you wrote: This is not as obvious as it would first seem. Some weather phenomena have very sharp transitions and some are gradual. So I don't think that interpolating weather is a trivial thing to do. For example a cold front is often a very well defined line with rain right along the front. In that case the weather right nearby is the best indicator and a METAR from 5 miles away could give a completely I believe MSFS and X-Plane do some kind of interpolation or transition between weather stations. I enjoy the challenge of flying in weather and am interested in weather. I've frequently compared the weather in a flight simulator to the local conditions. What I found was there frequently are insufficient reporting stations in many areas to match real weather conditions. There are some vast areas not covered by reporting stations or great distances between them. I have no way of knowing if they just did not get all existing stations, but I suspect this is not the case. I have checked for reporting stations on the NOAA site during hurricanes and have found they are often far apart. It would be good to include some kind of interpolation between stations and also a period update while in flight of real weather data. The interpolation should be as smart as practical, but I do not think it must be so precise as to model the weather in such a detailed manner. There are likely not enough reporting stations to do that anyway. Just blending the stations would useful and a start. The one improvement we could make over existing flight simulators is to avoid abrupt changes when the data updates. What bothers me most about these real weather systems not being able to logically anticipate weather ahead of the flight path. I think this is caused by level of details settings either covering up weather you should be seeing having it popup in front of you out of nowhere. Also, once weather is added, ATC will need to be updated to not accept flight plans from airports that are below minimums. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 27
Subject: [Flightgear-devel] nasal electrical system To: flightgear-devel@flightgear.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Hi Steve ...I found the file in Aircraft/c172/c172-electrical.nas It works the way I wanted 0 volts at the outputs when the switch is off. Hmm...I have downloaded the Windows binary release for 0.9.8, which I am running. I do not see the nas file there. I downloaded the source code and source code base for 0.9.8 and do not see it. I have downloaded the bleeding edge CVS but do not see it. I have downloaded all the C172s from the GF download page but do not see it. Okay, I found it, I had not looked on the CVS page from the FG website. It is in the CVS browser at [FlightGear-0.9] / data / Aircraft / c172 quite a hunt. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 24
On Mon, 10 Oct 2005 07:06:31 -0500, you wrote: Message: 6 Date: Mon, 10 Oct 2005 02:12:09 -0700 From: syd [EMAIL PROTECTED] Subject: [Flightgear-devel] electrical systems To: flightgear-devel@flightgear.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Hi ...thanks for the tip , I hadn't noticed the nasal electrical system before. After playing around with it for an hour or two ,I had a system for the B1900D working great ! I never did get a good grip on classes , etc with my c++ programming , but I still find nasal much more flexible and easier to understand than xml.Thanks again ... I can get at the B1900D again .Cheers Can you point this dummy to where the nasal electical system or documents are? Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 21
On Sun, 09 Oct 2005 06:36:16 -0500, you wrote: In the c172 aircraft, the ambient noise in the cockpit is pretty similar to what one hears w/o any headset. When one turns the radio on and tries to hear the ATIS, it sounds pretty low volume. This was on my todo list of things to mention. I can barely make out ATIS with my head to the speaker. Aside: It would be great if the ambient noise could come from the speakers and the radio traffic heard over headphones. This does not seem possible to me with current PC configurations, but it would be a nice feature. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 21
On Sun, 09 Oct 2005 06:36:16 -0500, you wrote: Syd and Steve, Check out the newer nasal based electrical system for the C172. I just had too much trouble getting the old xml based system to really work the way I was hoping it might. The nasal based approach seemed to work out Thanks Curtis. I think I am missing something. So I decided to download the bleeding edge CVS tarball and take a peek. I am still working on Windows, so that means I am not going to bother compiling anything until I have a BSD machine. I found the new docs for the electrical system. I see the XML based system has been depreciated. Where do I find out about the nasal electrical system or an example C172? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: (electrical) Flightgear-devel Digest, Vol 30, Issue 19
I noticed recently that electrical outputs still show a voltage (frozen)
when a switch is shut off.Is there a reason for this ... or is it a work
in progress?
The reason I ask is that I want to animate lights by the voltage rather
than switch position ... (dimming lights as the battery voltage drops ,
etc...).I just want to know if this is the way it is going to operate ,
and I can change my animations (I'm currently working on the
overhead light switch panel in the B1900D).Thanks in advance, I know how
busy everyone is .Cheers
I am still learning the electrical system model. I like to see all the
electrical devices and switches work as in real life. If the master
avionics switch is off or the battery is dead, the autopilot should
not be displaying anything or operating.
For the autopilot, I set a power-good property (like mainboards have)
and use NASAL to check for sufficient output on the autopilot bus. For
example:
ap_pwr = getprop(/systems/electrical/outputs/autopilot[0]);
if( ap_pwr = 0.3) {
print(Digitrak: Power Good);
setprop(Internal, power-good, on);
} else {
print(Digitrak (Warning): Insufficient power.);
setprop(Internal, power-good, off);
}
This seems to work well. The Digitrak requires 0.3 amp.
On the other hand, I am still confused about some aspects of the
electrical system.
/systems/electrical/volts
/systems/electrical/amps
both seem to be read only properties. I suppose this makes sense, if
these are just monitoring the flow (but at what point?) and the system
is modeled as suppliers and outputs of electricity. Any adjustments
would be made at the supply side.
I can change
/systems/electrical/serviceable
but it appears to do nothing.
However,
/systems/electrical/suppliers/alternator
/systems/electrical/suppliers/battery
/systems/electrical/suppliers/external
are also read only. It appears all the outputs are ready only
/systems/electrical/outputs/*
I am left looking for where the actual source of electrical power is
specified. Looking at the electrical.xml the properties are defined
here.
I can change the initial value of the battery in amps from here (shows
up /systems/electrical/suppliers/battery), but lowering it to 5 amps
did not seem to affect the a/c.
Okay, if I set both battery and alternator to 0.1 amps in the config,
my autopilot fails power good. It appears the turn coordinator also
fails. Flaps still work (this is the Cessna). Radios work. ADF works.
Clock works. Fuel, Temp, Flow gauges all work, the AMPs show zero.
This suggests many instruments do not check the electrical properties.
The a/c engine turns over and works fine without a battery or
alternator (magneto?).
I am unsure how the output properties are affected by switches or if
they can be.
Steve
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 17
On Fri, 07 Oct 2005 05:29:47 -0500, you wrote: The first thing I have to deal with is the way, the XML-Instruments work. Is it possible to use the XML-Instruments in a 3d-Cockpit or do you have to rewrite the whole stuff to animations? I've got my XML instrument on a panel in the Cessna virtual cockpit or 3d cockpit. I would say yes. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: (convert GMAX/MDL file) Flightgear-devel Digest, Vol 29, Issue 52
The FS2000 model converted fine. You can find at the following links the converted model and texture file: http://www.spiderbark.com/fgfs/predator.ac http://www.spiderbark.com/fgfs/tblades.rgb By the time I recalled how to do the conversion I was done: There is a 3dconvert utility included with FlightGear that will read in the .mdl file and produce a .ac file (based on the extensions of the files named in the parameters e.g. 3dconvert filein.mdl fileout.ac). Then the indexed bmp file was loaded into gimp and converted to rgb (sgi) format. Finally I loaded the predator.ac into a text editor and did a global replace of the text tblades.bmp to tblades.rgb. BTW, the only textured portion of the model is the propellor disk, but since the aircraft are all white anyway...it looks fine. You could always add numbers. I have the Windows binary distribution. I do not see a 3dconvert utility. Is there somewhere I can get this? I have Gmax installed again and found my experimental aircraft model for MSFS and want to see if I can export it to FG as a MDL file. Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Digitrak Autopilot 0.1.1
I have a new version of the Digitrak autopilot ready. New is the ability to follow a FlightGear GPS course. If Waypoint0 and Waypoint1 are set in the GPG dialog, the aircraft will intercept and capture the source line. To get this to work, you will need to add a dialog to the GUI. It adds a button to start the intercept. This is necessary because the Digitrak normally would automatically sense a flight plan from the GPS automatically through the communications with the autopilot. It occurred to me that this might be a good way of organizing the Autopilot menu. For each custom autopilot, the developer could supply a dialog box. This would help end the confusion over which autopilot the Autopilot dialog applies to. Download from http://www.city-gallery.com/vpilot/flightgear/digitrak-debug-0.1.1.zip Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Release 0.0.7 of Digitrak Autopilot
To everyone who has helped, thanks. My goal is to model the behaviors and capabilities of the Digitrak with as much accuracy is possible given my ability and the limitations of Flight Gear. I doubt it would be possible or desirable to model the electrical characteristics of the sensors or reverse engineer the actual code. The short term goal is to model the basic behavior of the autopilot, to get the basic modes working, then see what is possible. My long term goal is to model the building blocks, the gyros, the magnetic compass and let those feed into the autopilot's calculations. This will help model the autopilot without depending on any of the other instruments. The ultimate goal would be to model it well enough to use as a training tool. I will continue to use the orientation properties from the flight model as a way of modeling the digital gyro input until I can look into coding my own gyro. Flight Gear has made it possible to do more than put a face on a standard autopilot, for which I am grateful. Although the controller derived from the standard autopilot may not model the actual Digitrak in detail, I think that with the exception of turbulence handling the behavior should be very similar to other autopilots for most normal capabilities. Holding a heading is holding a heading, making standard turn is making a standard turn. The main difference is the GPS intensive nature of the navigation. The latest version is http://www.city-gallery.com/vpilot/flightgear/digitrak-debug-0.0.7.zip which supports the GPS Track and Heading Hold modes (to get the latter you must fail the gps by setting gps-valid to 'off' in properties. The next capability to tackle is following a flight plan. Feel free to comment or make corrections, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Electrical system properties
Are the electrical system properties readable? In NASAL, when I write elec = getprop(/systems/electrical/volts[0]); print(elec:); print(elec); It prints nothing. The same for /systems/electrical/outputs/bus-avionics[0] but when I substitute /consumables/fuel/tank/level-gal_us[0] it reports a correct value. The docs say that my script can monitor the property name associated with an output to decide how to render an instrument. I have checked the spelling and it looks correct to the value I see in the viewer flying the Cessna 172. Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Digitrak and three axis gyro
The Digitrak is described as employing gyroscopic rate sensors are installed so as to sense motion about each of the major axes (roll, yaw and pitch). I assume they mean there is a spinning gryo around which three sensors are arranged, to sense motion in each axis, pitch, roll and yaw. The sensors report how much the aircraft has moved around the gyro for each axis. From what I can see of the various default instruments in FlightGear, the only source of roll angle from an instrument is the attitude indicator or indirectly, the turn coordinator, which the Digitrak does not use. I conclude that to model the Digitrak fully, I would need to create C code to represent this three axis gyro using the gyro.*** code that the attitude indicator depends on. I have a little experience with C, but not much. I nearly understand how the attitude indicator works with the gyro model, but I still have to many questions to comprehend all it is doing. I also assume that using /orientation/roll-angle is the best substitute currently available. I would appreciate any help with this and please correct me if I am wrong in any of this. I think the Digitrak would make an interesting contribution to FlightGear. Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 29, Issue 16
works fine, however, I notice some differences in the numbers reported by the heading and track properties. Are you sure that the Digitrack actually knows the roll angle of the airplane? I am not sure I have the technical background to understand how the Digitrak actually works. It does not use a turn coordinator as a source of roll information. There is an explanation on the website http://www.trutrakflightsystems.com/overview.html which may be new, I do not remember having it when I made the model for MSFS. In the FG generic autopilot, the second stage of the heading bug hold, inputs /orientation/roll-deg into the controller and uses the target roll as the reference. I copied this to get it working. I looked at the KAP140, but it depends on the turn indicator for input to the wing leveler (roll mode). The Digitrak docs clearly state that it does not employ a turn coordinator, so I cannot take this approach. The overview claims it can sense motion about the three axes, apparently through the directional gyro. I assume it uses that to obtain roll angle. The orientation/roll-angle would be a good place to start, being closest to getting the roll information from the digital gyro. Is it possible to use the directional gyro as a source? It seems that I would need to create my own gyro model to do this. The DG/heading indicator only outputs heading. I can only assume from the documents (the PDF manual particularly) that the gyro is periodically corrected for drift using the magnetometer or the GPS. I have not decided how to simulate this. Heading and track are _not_ the same thing. Heading is the direction that the nose of the aircraft is pointing. Track is the direction that the aircraft is You're right. I forgot about wind effects. I have studied this in instructional texts on navigation, but I have become lazy flying PC flight sims by GPS route most of the time. Thanks for clearing that up, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] GPS Track
The Digitrak autopilot project is coming along. I have the first mode running, which captures and holds the GPS track. I get the GPS heading to feed to the autopilot controller from the default GPS instrument. The autopilot is set to reduce the GPS bug error to zero by driving the aileron until the orientation roll equals the target roll. This works fine, however, I notice some differences in the numbers reported by the heading and track properties. /orientation/heading-deg 270 /orientation/heading-magnetic-deg 282 /instrumentation/gps/indicated-track-true-deg 258 /instrumentation/gps/indicated-track_magnetic-deg 269 I noticed that the orientation values do not update continuously as the gps ones do, so I checked this again to make sure the difference was there. I think they must be correct because the autopilot is holding on course 270 with only fractional deviation seen in the GPS track. I may be a dummy, but can anyone explain this? Not the variation between true and magnetic, but between GPS and orientation. Is it GPS error being simulated? Is it simulating the local magnetic deviation between compass and GPS headings? Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 29, Issue 8
combination of altitude + speed holds, as well as auto fly from current location to a specific lat/long waypoint. There has been some discussion in The a/p each aircraft offers is selected by adding an a/p model configuration file to the SYSTEM section in the configuration for the aircraft. The a/p interface you see on the panel is a model of the a/p face. The interface model and the a/p system model must be coordinated so they work together (for example, if the a/p system does not support a controller for ALT hold, a button on the face will do nothing and if the face as no ALT hold button, but the a/p model does support ALT hold, then you have no way of communicating that to the system). The autopilot dialog you see from the main toolbar appears to set standard autopilot properties in the property hierarchy, but some if not all a/p use their own properties, and thus can only be adjusted or set from the face, not from this dialog. Only a/p that use the standard properties can be set from here. At least this is my understanding. One of the bundled F16s appears to support the a/p set through the a/p dialog window. I am having some problem with FG today, can't get anything to straighten up and fly right, so I need to reboot and see what is the matter. As far as I know, there is no GPS interface other than the dialog window. I think the KAP140 can do altitude and v/s speed holds. I had trouble reading the instruments and using the dials to set those, so I can't comment in depth. The a/p model could be adapted to fly GPS waypoints. I am working on a model of the Digitrak a/p, which can fly GPS track and accept a flight plan if a GPS unit feeds it one. It is only a single axis roll mode, though. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 29, Issue 4
I thought about trying to do some birds a while ago and figured that even a simple 3d model was probably unnecessary - a few I think bird hazard to place around airports is a great idea. I lived in Delaware once, and at Dover AFB, flocks of birds would always rise up when one of the galaxies would come over a farm field on approach; up they would go and then just when you thought they might reach the aircraft, they would settle down again. There are eye-candy birds in Star Wars Battlefront for example, which appear to be flat planes with textures that flap. The textures must be transparent to define the birds shape. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 28, Issue 43
Digital autopilot. With help from Roy Vegard Ovesen, I have managed to get the Digitrak autopilot working in a minimal way. It will hold the heading you select using the GPS to drive the autopilot. The files are available at http://www.city-gallery.com/vpilot/flightgear/ download the latest version (0.0.3). Let me know what you think. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 28, Issue 43
input. It's quite different from the traditional designs that use the turn coordinator or the attitude indicator to control the roll axis. What really attracted me to the Digitrak was its simplicity. The interface is about a simple and elegant industrial design. You can't get more simple than a heading display and two buttons. Also, it is kind of revolutionary in that you don't need all the usual expensive and complicated instrumentation of the typical general aviation aircraft to navigate. The minimum requirement is actually a Garmin 35 antenna that has a built in receiver and provides ground track and ground speed. The Digitrak will follow whatever heading you enter into the display using that data. I also like the idea of how simple it becomes when you bring everything into the digital domain and drive the flight controls with stepper motors. It's really fascinating and offers a lot of potential for making autoflight possible on nearly any aircraft (I can think of how it might apply to a Personal Air Vehicle, which has to navigate itself or be very simple for an ordinary person to operate). Also, one of the stated features is that it does not rely on a turn coordinator and as such makes claims of better turbulence handling. This is one of the areas I am hazy on, how it actually works. It was easy to model in MSFS, I just connected the heading display to the heading but and to the GPS autopilot. That's cheating. The Digitrak has a built in DG and a magnetometer, which I believe is used to sync (correct automatically) the DG to the compass heading. It also states the DG is slaved to the GPS, which I take to mean it can make the same correction using the GPS or perhaps it only means it syncs the DG with the selected heading. Apparently, you can fly the heading by DG when there is no GPS signal. The modes are GPS NAV, which keeps a heading with ground track data, a GPS flight plan mode that automatically follows waypoints if the GPS sends a waypoint to it, and the magnetic DG. I would like to model this without using the turn coordinator as input. Again, I am long winded, but there are many oddities about this autopilot that need pointing out. Thanks for the advice. I'll read it and get back to the list. Are you using version 0.9.8 or CVS? I am using the 0.9.8 Windows XP binary. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Digital Autopilot
I am new to Flight Gear and have often thought it would be great to have an open source flight simulator. About three years ago, I began a project to model the Digitrak Autopilot in MSFS, which turned out okay, but not really like I hoped it could be. I was able to graphically imitate the AP and to connect it to the heading bug and existing internal autopilot and have it generally operate. I was able to model some of the special behaviors, such the initialization delay and display. However, it really could not go beyond that because you could not mod the internal autopilot (well, maybe some expert could by modding the code or doing all the calculations in the embedded scripting language, but that was beyond what I was willing to do). I was frustrated by the inability to model the unique characteristics with accuracy. I discovered FlightGear supports XML panels and gauges, so I decided to give the project another chance. That's all very long winded, so I will get down to the matter at hand. The instrument I am trying to port is a model of the Digitrak digital autopilot for experimental aircraft to FlightGear. This is made by a company called TruTrak and you can download the PDF files on the Digitrak here: http://www.trutrakflightsystems.com/ttfsproducts.html#Digitrak I've read all the docs that came with the FG distributions and have made a start on the Digitrak for FlightGear, but the learning curve is steep. I've got the texture created, made a instrument XML file and loaded it onto the Cessna panel. The display works and the two main buttons are clickable. In addition, I have studied the documents on the PID controller and copied over the HDG one from the general autopilot for experimentation. So far, I can see that I will need some help pulling all this together and modeling the controller to get this actually working. Then there are a lot of unique features to model. The Digitrak uses GPS Nav or its own internal DG for directional information. I will probably need to use the nasal script to model the initialization delay at startup. This a/p has a variety of modes and nuanced behaviors that will likely be difficult to model. Although I do not intend to model all of the features, I hope to model the basic functionality. Even now I can see that some would make this a very complicated project given the limitations of FGFS and the amount of work to make many of the modes and display features work as in the manual is too much to consider at this time. It would require nearly every feature to be nasal scripted. This would probably be similar to the nasal scripted buttons/functions of the KAP140 autopilot. My attempts so far have left me with some questions. Is there a complete and comprehensive list of properties that are built-in to the FG system (not those created by a particular instrument)? Do I understand correctly that properties in the instrumentation/ hierarchy are built-in values, that come from the system and are not produced by a custom instrument or script? I do understand that you can bring a property into existence by naming it and it appears that the properties in autopilot/ hierarchy are somehow part of the standard autopilot. I believe this means I should create my own set of properties, such as autopilot/digitrak/settings etc. Is that correct? I tried adapting the controller, the cascading one for Heading Bug, but it will not track. It just spins around. I can see it hit a bump when it equals the setting. The original HDG controller uses the heading bug error as an input. But I need to input the difference between the orientation of the a/c and the GPS track into the controller. I tried making the orientation in roll axis the input and the GPS track the reference, but that does not seem to work. Also, I do not really understand the GPS system in FGFS. I need to take the heading value from the GPS ground track. The Digitrak in its NAV mode follows a GPS track and ground speed from the GPS. That is all it needs to function. It has various other modes as well, but that is the one I want to get working first. I appreciate your help, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Saitek Cyborg Evo
Hello, I just started with FlightGear on Windows XP. I recently purchased a Saitek Cyborg Evo joystick. The rudder control was not working in FlightGear. After some exploring, I discovered (using js_demo) that the stick identifies itself as Joystick 0 is Saitek Cyborg Evo In the Inputs folder there is a joystick configuration file for this stick, which puzzled me at first as to why it didn't work. The name in the file is Saitek Cyborg USB Stick Once I changed this to Saitek Cyborg Evo the rudder and everything else worked fine. Perhaps the distribution could be updated with this information. I don't know if older evo sticks identify this way or they identify this way in Unix based OS, so it may help to supply two configurations with the different names if that is the case. Thanks, Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
