Re: [Flightgear-devel] Warrior changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I prefer starting with engine off (and not at threshold) so why not add support for starting somewhere else than end of runway? Starting at the gate for example (makes sense for 787 but not for the warrior) or in a hangar (if such exist at that airport). /AnMaster Hans Fugal wrote: This isn't the only plane that starts in cold configuration. I think it would be best to be consistent - either leave it up to the plane designer in every case (I believe in this case at least it was a conscious decision on the part of the designer), or decide on a policy that every aircraft should start hot and try to make that consistent throughout. On 10/11/07, David Megginson [EMAIL PROTECTED] wrote: As I mentioned earlier, the Warrior model is looking great. However, because it was starting with the engine and fuel off and the brakes on, it took a while to get started (and wasn't realistic sitting on the threshold with the engine off), and I don't think it was possible to do an in-air start, e.g. fgfs --aircraft=pa28-161 --altitude=5000 --vc=100 There were some places that the Nasal scripts were overriding startup preferences. I started cleaning those up and made a few more changes, so that the Warrior now starts up just like the Cessna 172 or J3 Cub, ready to take off. Please let me know if you find any problems. All the best, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHDx1cWmK6ng/aMNkRCsVXAJ4rsHZ8m0XxGMsDOQwj6nVNcfSIvQCbB6TD l8Jk+rZ3V0wORXEIxqFl5Tk= =R0Gn -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Addition of true comms in multiplayer
Friday, October 12, 2007.
Hi Holger,
I have progressed with my WIN32 port of FGCOM, but now a problem with the
910.00 'echo' ...
1. svn checkout svn://svn.dfn.de:/fgcom
This continues to fail - a timeout. Can others checkout this source? I
eventually downloaded and used fgcom-1.0.1.tar.gz ...
2. XMLRPC-C
I had some initial trouble with the xmlrpc-c library. It was NOT formatting a
double correctly in WIN32, but now that has been fixed. I passed these changes,
and lots of others to build in WIN32, to Bryan Henderson
(http://xmlrpc-c.sourceforge.net/techsupp.php), and he has added some changes
to his SVN trunk source. Maybe more to come ...
The simple client/server samples in the XMLRPC-C source all function perfectly
... as does his rpctest suite ...
3. FGCOM 910.00 echo
Server: http://fgcom1.parasitstudio.de:12345/RPC2
I have been trying to do this 'echo' test, to see if my WIN32 aixclient, speex,
etc, is compiled and running correctly, but on 'login' I get back the following
ERROR stuff :-
XML-RPC: InternetReadFileEx( h, buffer=[Sz=40, Next=, Buf=013B3200,
len=889, tot=1301] ... )
XML-RPC: InternetReadFileEx=[TRUE] buffer=[Sz=40, Next=, Buf=013B3200,
len=889, tot=1301]
DATA[?xml version=1.0?
methodResponse
fault
valuestruct
membernamefaultString/namevaluestringerror executing RPC `login'.
Do not know how to thaw data with code `' at /usr/share/perl5/FreezeThaw.pm
line 542
FreezeThaw::thawScalar(0) called at /usr/share/perl5/FreezeThaw.pm line
679
FreezeThaw::thaw('') called at /home/fgregister/fgcom/server/fgreg.pl
line 490
main::_session_check_value('user', 'guest') called at
/home/fgregister/fgcom/server/fgreg.pl line 686
Register::login('guest', 'guest', 'iax', 0, 910) calle...]
XML-RPC: InternetReadFileEx( h, buffer=[Sz=40, Next=, Buf=013B3579,
len=412, tot=1301] ... )
XML-RPC: InternetReadFileEx=[TRUE] buffer=[Sz=40, Next=, Buf=013B3579,
len=412, tot=1301]
DATA[tier/Daemon/ForkingBasicAuth.pm line 70
Frontier::Daemon::ForkingBasicAuth::new('Frontier::Daemon::ForkingBasicAuth',
'methods', 'HASH(0x85bb23c)', 'AuthFile', '/home/fgregister/.fgreg/auth.conf',
'LocalPort', 12345) called at /home/fgregister/fgcom/server/fgreg.pl line 89
/string/value/member
membernamefaultCode/namevaluei44/i4/value/member
/struct/value
/fault
/methodResp]
This is the output from some DEBUG code I added to the xmlrpc-c library, since
I was continually getting 'no connection' ... the DATA[...] is the actual data
received, in two blocks, but a small amount may have been missed.
It seems I am getting a 'connection', but the 'server' bombs executing the
'login' ...
Are others seeing this? It does not seem I can do anything at this client end?
Any help appreciated.
Regards,
Geoff.
EOF - fgcom-03.doc
_
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] changed runway selection behavior
* Thomas Förster -- Friday 12 October 2007: Using the proposed change it is possible to get the original behaviour of the method (FGRunwayList::search) with a weight set of (0,0,0,1). The idea was to hard-code the weights once we are happy with the results, which is why I didn't consider this possibility at all. But then again, we have so many configuration options that four more won't hurt either, especially since they are very rarely read and thus have not the least effect on the frame rate. And in this new scenario your propsal makes sense. Just need to find a permanent place for the values in the tree. m. :-) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] changed runway selection behavior
Am Donnerstag 04 Oktober 2007 schrieb Melchior FRANZ: The last point is done with weighting factors, which are for now configurable in the property tree and might need some more adjustment. Please check problem cases and report any unwanted behavior. I'd prefer the evaluation formula changed to: good = 1e-20 + LENWGT*... The reason is that in if all 3 runway weights (len, width, surface) were zero, the heading hint would be completely ignored because runway quality will always be zero thus picking the first runway. Forcing all weights to nonzero always takes length/width/... into account, which might not be wanted in certain situations. Using the proposed change it is possible to get the original behaviour of the method (FGRunwayList::search) with a weight set of (0,0,0,1). Thomas - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hangar start
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 David Megginson wrote: On 12/10/2007, AnMaster [EMAIL PROTECTED] wrote: I prefer starting with engine off (and not at threshold) so why not add support for starting somewhere else than end of runway? Starting at the gate for example (makes sense for 787 but not for the warrior) or in a hangar (if such exist at that airport). You probably wouldn't want to start in a hangar unless you wanted to animate a little pilot with a sore back pulling the plane out onto the apron -- it's extremely rare to start the prop when the plane is indoors. In front of a hangar might make sense, but with the nose angled away so that the prop blast doesn't blow back into the hangar. Maybe add tow truck to flightgear? I wouldn't want to pull an English Electric Lightning for example (would it even be possible?) /AnMaster Seriously, I think we should make it easy to start the way you want, but there's a lot of work involved. The original aircraft config system was designed to make it easy for users to override default settings at runtime, but I notice now that lots of people use Nasal scripts (etc.) to forcibly override default properties, so you're pretty-much stuck with whatever the designer decided until we have time to clean up all the config files. All the best, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHD6ngWmK6ng/aMNkRCiaXAJ9bHthmtolIcQTMmYDDBHMBSSFw3ACfQnjZ 70E1Gs1YKfTXAVY67/yNsY0= =PeL1 -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
On ven 12 octobre 2007, David Megginson wrote: On 12/10/2007, Vivian Meazza [EMAIL PROTECTED] wrote: You can have your aircraft any way you want, but don't force it on other designers without some real thought. Start the Spitfire and forget to zero the throttle, you will start on your nose. That doesn't give a good impression to newcomers. I'm actually suggesting the opposite -- instead of having each designer decide, let the users start the aircraft any way *they* want. I think the default should be with the engine on and idling, but that's a separate discussion. The first step is to agree on a global property and start modifying aircraft configs to honour it; then we can debate what the default value of that property should be. All the best, David Only one generic property switch is necessary. We must only, all together decide which name and where (/sim/ ??) With it it the designer can control the model aircraft conditions (property) which are necessary according to the user wishes. With FDM Yasim Aircraft, it can be done easily solve with Nasal script With FDM Jsbsim Aircraft that switch may activate any property which are necessary to have the aircraft in hot configuration. For instance looking at one of my model to have the right flying conditions, i need: Canopy = Down Wing-folds = Off Wing-incidence = Down Electric-power = On Cut-off = Off Engine= running Throttle = 0.6 Landing-gear = Up All these property could be switched according to that Cold/Hot property Cheers -- Gérard http://perso.orange.fr/GRTux/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
On 12/10/2007, drew [EMAIL PROTECTED] wrote: I have my .fgfsrc file set up so I start on the run-up area just off the main runway at KSFO: --lat=37.612451 --lon=-122.357858 --heading=026 so I have the time to do pre-flight checks (and explore the cockpit and README's of new and unfamiliar a/c) without clogging up the threshold. If you want to be even more realistic, you can start on the GA apron off taxiway C north of firehall #2. From the following diagram, it looks like longitude 122 23.0 W (-122.38) and latitude 37 37.7 N (37.638333) should do the trick, with a heading of around 150 deg T so that you're parked sideways to the FBO: http://flightaware.com/resources/airport/SFO/APD/AIRPORT+DIAGRAM/pdf You can read about the actual Signature FBO here: http://www.airnav.com/airport/KSFO/SIGNATURE All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
For what it's worth, I think it's great to have a choice, at start-up, between a cold and hot start (as with the c150). More than half the fun of a sim, as opposed to a game, is the realism of exploring the cockpit for the necessary switches and knobs to get the bloody thing going and airborne. The an2 is one of my favourites - for this very reason. I have my .fgfsrc file set up so I start on the run-up area just off the main runway at KSFO: --lat=37.612451 --lon=-122.357858 --heading=026 so I have the time to do pre-flight checks (and explore the cockpit and README's of new and unfamiliar a/c) without clogging up the threshold. Blue skies, Drew On Saturday 13 October 2007 00:58:09 David Megginson wrote: On 12/10/2007, Vivian Meazza [EMAIL PROTECTED] wrote: You can have your aircraft any way you want, but don't force it on other designers without some real thought. Start the Spitfire and forget to zero the throttle, you will start on your nose. That doesn't give a good impression to newcomers. I'm actually suggesting the opposite -- instead of having each designer decide, let the users start the aircraft any way *they* want. I think the default should be with the engine on and idling, but that's a separate discussion. The first step is to agree on a global property and start modifying aircraft configs to honour it; then we can debate what the default value of that property should be. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Warrior changes
Am Freitag, den 12.10.2007, 07:53 -0400 schrieb David Megginson: On 11/10/2007, Hans Fugal [EMAIL PROTECTED] wrote: This isn't the only plane that starts in cold configuration. I think it would be best to be consistent - either leave it up to the plane designer in every case (I believe in this case at least it was a conscious decision on the part of the designer), or decide on a policy that every aircraft should start hot and try to make that consistent throughout. I was the aircraft designer, though others have done a lot of excellent work on the Warrior since. One problem with starting in cold configuration by default is that in-air starts won't work. For example, if you use FlightGear to practice IFR approaches (like I do), you want to start in the air about 10 miles from the runway, not in the tie-down area. There was no way to do that using command-line options with the previous version of the config files. That is not necessarily so. The default bf109 starts cold too, but you can set a property (either on the commandline or -set.xml) to have the engine running at startup. For Newbies I've provided a menu entry to magically start the engine. I recommend that we start all aircraft running and ready to roll, but provide an easy way for advanced users to start cold if they want to. I know that aircraft designers work hard on the switches and systems and want to show them off, but forcing people to use them every time might not be the best choice, especially for new users (and when the default start is on a runway threshold, where the engine should be running). All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Greetings -- Detlef Faber http://www.sol2500.net/flightgear - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
David Megginson Sent: 12 October 2007 15:11 To: FlightGear developers discussions Subject: [Flightgear-devel] Consistent aircraft states On 12/10/2007, dave perry [EMAIL PROTECTED] wrote: Welcome back. I am the one that made all the changes to the Warrior. Starting directions and keyboard switch equivalents are under the help menu-Aircraft help, just like with the pa24-250. It was after you had commented on how you liked what I had done on the pa24 that you sent me your pictures and asked if I wanted to continue developing the Warrior, so I used the pa24 nasal work as a starting point for implementing the Warrior electrical system and switches. You did a great job on it -- I'm very impressed. I still consider the Warrior your aircraft and had communicated to you off list in mid August that I had made updates and changes. I asked for feedback in that note. I assume that you did not disable or bypass the nasal implemented switches with the above change. No, but I did migrate some of the property settings out of the Nasal script and into the XML settings file. I am clearly one that prefers to start with the brakes set and all switches off as that is the way every real flight starts. (An aside: In my experience, it's rare that the parking brake is on when a real light plane is parked, because line staff wouldn't be able to move it around without gaining inside access -- in fact, when I get out of the plane at a remote airport, the first question from line staff is usually not do you need fuel? but is the brake off?. Normally, a plane on an apron is chocked, while a plane in longer-term parking is tied down.) But I also see the advantage of having an easy option to start in the air with switches and fuel valve set for an approach. Perhaps with a little more effort, there is a way to accomplish both. Here are a few usability guidelines that might help: 1. Consistency - all aircraft should start in same default state as far as possible (obviously, a glider doesn't have an engine), so that a user isn't surprised when switching aircraft types. 2. Configurability - it should be not only possible but very easy for a user to override the default state without editing XML or Nasal files. 3. Simplicity - the default state should be the easiest one for new users. Experienced users will have an easier time changing the default. I suggest that we introduce a new global property, such as /sim/start-state, which can be set to (say) parked, in-air, or idling. The configuration files for every aircraft could respect that property, so that if you set it to parked, *every* aircraft (even the default 172) would start parked, etc. (we could even put it on the apron instead of the runway if we add parking coordinates to the airports file). I think idling should be the default the first time someone runs FlightGear, since it's standard with all flight sims and by far the easiest for new users, but one menu selection should be able to switch to parked for people (like you) who prefer to go through the startup and taxiing routine every time. All the best, You can have your aircraft any way you want, but don't force it on other designers without some real thought. Start the Spitfire and forget to zero the throttle, you will start on your nose. That doesn't give a good impression to newcomers. On the other hand, there are quite a number of ac which seem to need some tlc. Several JSBSim ac want to start on their backs here post recent updates. Vivian - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Warrior changes
David Megginson wrote: As I mentioned earlier, the Warrior model is looking great. Hi David, Welcome back. I am the one that made all the changes to the Warrior. Starting directions and keyboard switch equivalents are under the help menu-Aircraft help, just like with the pa24-250. It was after you had commented on how you liked what I had done on the pa24 that you sent me your pictures and asked if I wanted to continue developing the Warrior, so I used the pa24 nasal work as a starting point for implementing the Warrior electrical system and switches. However, because it was starting with the engine and fuel off and the brakes on, it took a while to get started (and wasn't realistic sitting on the threshold with the engine off), and I don't think it was possible to do an in-air start, e.g. fgfs --aircraft=pa28-161 --altitude=5000 --vc=100 There were some places that the Nasal scripts were overriding startup preferences. I started cleaning those up and made a few more changes, so that the Warrior now starts up just like the Cessna 172 or J3 Cub, ready to take off. Please let me know if you find any problems. I have not yet updated the warrior to your changes but I just used the command line above to do a mid air start. All it takes to have whatever power you have set from you throttle setting is to hit f and then s. Then you need to switch on whatever else you want on such as pannel lights, strobes, fuel pump, etc. It seems to me that anyone experienced enough to desire starting in the air to practice instrument approaches should be able to figure out which keys are needed to get the engine on in 2 seconds especially since those keys are in the help menu. I still consider the Warrior your aircraft and had communicated to you off list in mid August that I had made updates and changes. I asked for feedback in that note. I assume that you did not disable or bypass the nasal implemented switches with the above change. I will update the Warrior from cvs this evening and then give feedback. I am clearly one that prefers to start with the brakes set and all switches off as that is the way every real flight starts. But I also see the advantage of having an easy option to start in the air with switches and fuel valve set for an approach. Perhaps with a little more effort, there is a way to accomplish both. Side comment. There are some AC in fgfs that start with the engine off, but no hot spots or help to point to how to get the AC started. This definitely is bad. AC designers need to include starting help. Really great to have you back! All the best, Dave Perry - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Consistent aircraft states
On 12/10/2007, dave perry [EMAIL PROTECTED] wrote: Welcome back. I am the one that made all the changes to the Warrior. Starting directions and keyboard switch equivalents are under the help menu-Aircraft help, just like with the pa24-250. It was after you had commented on how you liked what I had done on the pa24 that you sent me your pictures and asked if I wanted to continue developing the Warrior, so I used the pa24 nasal work as a starting point for implementing the Warrior electrical system and switches. You did a great job on it -- I'm very impressed. I still consider the Warrior your aircraft and had communicated to you off list in mid August that I had made updates and changes. I asked for feedback in that note. I assume that you did not disable or bypass the nasal implemented switches with the above change. No, but I did migrate some of the property settings out of the Nasal script and into the XML settings file. I am clearly one that prefers to start with the brakes set and all switches off as that is the way every real flight starts. (An aside: In my experience, it's rare that the parking brake is on when a real light plane is parked, because line staff wouldn't be able to move it around without gaining inside access -- in fact, when I get out of the plane at a remote airport, the first question from line staff is usually not do you need fuel? but is the brake off?. Normally, a plane on an apron is chocked, while a plane in longer-term parking is tied down.) But I also see the advantage of having an easy option to start in the air with switches and fuel valve set for an approach. Perhaps with a little more effort, there is a way to accomplish both. Here are a few usability guidelines that might help: 1. Consistency - all aircraft should start in same default state as far as possible (obviously, a glider doesn't have an engine), so that a user isn't surprised when switching aircraft types. 2. Configurability - it should be not only possible but very easy for a user to override the default state without editing XML or Nasal files. 3. Simplicity - the default state should be the easiest one for new users. Experienced users will have an easier time changing the default. I suggest that we introduce a new global property, such as /sim/start-state, which can be set to (say) parked, in-air, or idling. The configuration files for every aircraft could respect that property, so that if you set it to parked, *every* aircraft (even the default 172) would start parked, etc. (we could even put it on the apron instead of the runway if we add parking coordinates to the airports file). I think idling should be the default the first time someone runs FlightGear, since it's standard with all flight sims and by far the easiest for new users, but one menu selection should be able to switch to parked for people (like you) who prefer to go through the startup and taxiing routine every time. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
On 12/10/2007, gerard robin [EMAIL PROTECTED] wrote: Only one generic property switch is necessary. We must only, all together decide which name and where (/sim/ ??) [snip] For instance looking at one of my model to have the right flying conditions, i need: Canopy = Down Wing-folds = Off Wing-incidence = Down Electric-power = On Cut-off = Off Engine= running Throttle = 0.6 Landing-gear = Up All these property could be switched according to that Cold/Hot property The sim can also decide where/how to place the aircraft (if not otherwise specified) based on the value. For example, by default, we could place the aircraft 1,000 ft above the airport at cruise speed if the value were in-air, on the runway threshold (as now) if the value were idling, and on the apron (assuming we have coordinates) if the value were parked. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Hangar start
On 12/10/2007, AnMaster [EMAIL PROTECTED] wrote: I prefer starting with engine off (and not at threshold) so why not add support for starting somewhere else than end of runway? Starting at the gate for example (makes sense for 787 but not for the warrior) or in a hangar (if such exist at that airport). You probably wouldn't want to start in a hangar unless you wanted to animate a little pilot with a sore back pulling the plane out onto the apron -- it's extremely rare to start the prop when the plane is indoors. In front of a hangar might make sense, but with the nose angled away so that the prop blast doesn't blow back into the hangar. Seriously, I think we should make it easy to start the way you want, but there's a lot of work involved. The original aircraft config system was designed to make it easy for users to override default settings at runtime, but I notice now that lots of people use Nasal scripts (etc.) to forcibly override default properties, so you're pretty-much stuck with whatever the designer decided until we have time to clean up all the config files. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Warrior changes
On 11/10/2007, Hans Fugal [EMAIL PROTECTED] wrote: This isn't the only plane that starts in cold configuration. I think it would be best to be consistent - either leave it up to the plane designer in every case (I believe in this case at least it was a conscious decision on the part of the designer), or decide on a policy that every aircraft should start hot and try to make that consistent throughout. I was the aircraft designer, though others have done a lot of excellent work on the Warrior since. One problem with starting in cold configuration by default is that in-air starts won't work. For example, if you use FlightGear to practice IFR approaches (like I do), you want to start in the air about 10 miles from the runway, not in the tie-down area. There was no way to do that using command-line options with the previous version of the config files. I recommend that we start all aircraft running and ready to roll, but provide an easy way for advanced users to start cold if they want to. I know that aircraft designers work hard on the switches and systems and want to show them off, but forcing people to use them every time might not be the best choice, especially for new users (and when the default start is on a runway threshold, where the engine should be running). All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Hangar start
On 12/10/2007, AnMaster [EMAIL PROTECTED] wrote: Maybe add tow truck to flightgear? I wouldn't want to pull an English Electric Lightning for example (would it even be possible?) It's fun to see the variety of tow vehicles at airports. For airliners, of course, there are the white tugs that we all recognize, but for smaller planes, I've seen old pickup trucks, converted riding mowers, and even a little dune buggy -- the only thing they have in common is that they're usually even noisier and harder to start than the airplanes. Some pilots also use powered towbars for smaller aircraft. Basically, anything up to the size of a Navajo or Cessna Caravan can (and will) get pushed around by hand, and it's a sort-of unwritten rule that you run over to help whenever you see someone starting to move a plane around; in fact, I do know a commercial Navajo pilot who can push her plane back into a spot with no assistance, though I sometimes have trouble even with my Warrior when the tires are soft and there's snow on the ground. All the best, David - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Consistent aircraft states
I am clearly one that prefers to start with the brakes set and all switches off as that is the way every real flight starts. (An aside: In my experience, it's rare that the parking brake is on when a real light plane is parked, because line staff wouldn't be able to move it around without gaining inside access -- in fact, when I get out of the plane at a remote airport, the first question from line staff is usually not do you need fuel? but is the brake off?. Normally, a plane on an apron is chocked, while a plane in longer-term parking is tied down.) Also, if the brakes were applied for long periods of time, they might fuse to the discs, requiring replacement of both. (just my $0.05 worth, with inflation and tax) Bill - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Addition of true comms in multiplayer
Yep Im afraid this times out for me -- thanks for confirming it wasn't just
my n00bness wirth SVN :-)
AFAIK Holger is away until the end of next week so Im not expecting any change
till then.
On linux the stable version fails for me with
[EMAIL PROTECTED]:/fgfs/fgfs/fgcom/src$ make
gcc -O2 -D'SVN_REV=exported' -c fgcom.c
fgcom.c: In function ‘main’:
fgcom.c:109: error: too few arguments to function ‘iaxc_initialize’
make: *** [fgcom.o] Error 1
AFAICT I have all the necessary packages so thats not the problem -- I can see
only one parameter being passed to iaxc_initializebut Im no C
programmer -- quite possibly Im missing something obvious..
---
Best Regards
Willie Fleming
[EMAIL PROTECTED] Friday 12 October 2007 18:04:23 Geoff Air wrote:
Friday, October 12, 2007.
Hi Holger,
I have progressed with my WIN32 port of FGCOM, but now a problem with the
910.00 'echo' ...
1. svn checkout svn://svn.dfn.de:/fgcom
This continues to fail - a timeout. Can others checkout this source? I
eventually downloaded and used fgcom-1.0.1.tar.gz ...
2. XMLRPC-C
I had some initial trouble with the xmlrpc-c library. It was NOT formatting
a double correctly in WIN32, but now that has been fixed. I passed these
changes, and lots of others to build in WIN32, to Bryan Henderson
(http://xmlrpc-c.sourceforge.net/techsupp.php), and he has added some
changes to his SVN trunk source. Maybe more to come ...
The simple client/server samples in the XMLRPC-C source all function
perfectly ... as does his rpctest suite ...
3. FGCOM 910.00 echo
Server: http://fgcom1.parasitstudio.de:12345/RPC2
I have been trying to do this 'echo' test, to see if my WIN32 aixclient,
speex, etc, is compiled and running correctly, but on 'login' I get back
the following ERROR stuff :-
XML-RPC: InternetReadFileEx( h, buffer=[Sz=40, Next=, Buf=013B3200,
len=889, tot=1301] ... ) XML-RPC: InternetReadFileEx=[TRUE] buffer=[Sz=40,
Next=, Buf=013B3200, len=889, tot=1301] DATA[?xml version=1.0?
methodResponse
fault
valuestruct
membernamefaultString/namevaluestringerror executing RPC `login'.
Do not know how to thaw data with code `' at /usr/share/perl5/FreezeThaw.pm
line 542 FreezeThaw::thawScalar(0) called at /usr/share/perl5/FreezeThaw.pm
line 679 FreezeThaw::thaw('') called at
/home/fgregister/fgcom/server/fgreg.pl line 490
main::_session_check_value('user', 'guest') called at
/home/fgregister/fgcom/server/fgreg.pl line 686 Register::login('guest',
'guest', 'iax', 0, 910) calle...]
XML-RPC: InternetReadFileEx( h, buffer=[Sz=40, Next=, Buf=013B3579,
len=412, tot=1301] ... ) XML-RPC: InternetReadFileEx=[TRUE] buffer=[Sz=40,
Next=, Buf=013B3579, len=412, tot=1301]
DATA[tier/Daemon/ForkingBasicAuth.pm line 70
Frontier::Daemon::ForkingBasicAuth::new('Frontier::Daemon::ForkingBasicAuth
', 'methods', 'HASH(0x85bb23c)', 'AuthFile',
'/home/fgregister/.fgreg/auth.conf', 'LocalPort', 12345) called at
/home/fgregister/fgcom/server/fgreg.pl line 89 /string/value/member
membernamefaultCode/namevaluei44/i4/value/member
/struct/value
/fault
/methodResp]
This is the output from some DEBUG code I added to the xmlrpc-c library,
since I was continually getting 'no connection' ... the DATA[...] is the
actual data received, in two blocks, but a small amount may have been
missed.
It seems I am getting a 'connection', but the 'server' bombs executing the
'login' ...
Are others seeing this? It does not seem I can do anything at this client
end? Any help appreciated.
Regards,
Geoff.
EOF - fgcom-03.doc
_
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] optimized generic_pylons and .osg models
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In the course of investigating some of the recent complaints about stuttering and low frame rates I noticed that generic_pylons_01.ac and generic_pylons_02.ac are terrible in terms of OSG performance. They are based on lines, which the .ac format does not support well. The upshot is that 140 displaylists, each containing one or two lines, are created for a single pylon. And then due to some other weirdness, these were being copied for each pylon... Anyway, I wrote a program using .osg to create optimized versions of these models as .osg files. In order to use them I've added a feature to SimGear that substitutes a model with a .osg extension for other models (not .xml) when it exists. This seems to be a bit controversial and I'm willing to discuss other ways of achieving the same thing -- for example, looking in a different path for .osg models -- but first I'd like folks with OSG performance problems to try these latest changes and see if they make any difference. Thanks, Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHD/uaeDhWHdXrDRURArEqAKCoepnNffbORKN3R3Zh0FdpojEsKwCfX+4Q W3BLR8Tv8yC/Lqfnlncuzq0= =hAQP -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] optimized generic_pylons and .osg models
* Tim Moore -- Saturday 13 October 2007: I've added a feature to SimGear that substitutes a model with a .osg extension for other models (not .xml) when it exists. This seems to be a bit controversial [...] That's quite an understatement. You asked on IRC about that and got *only* objections. You were the only one who liked the idea, IIRC. I find it quite disturbing that you ignore the opinions that you *asked* for, and do it anyway. I'd prefer that explicitly stated paths are respected and are not replaced behind the scenes. Now, if an XML file only demanded a pathfoo/path without extension, then it would be ok to first try foo.osg and then foo.ac. But we told you yesterday ... m. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] YASim gear friction
Hi, This is a revival of the old thread small bug in YASim-gears. I'm trying to improve the static gear friction using the damped spring (1 cm length) around a stuck point method cited by Andy Ross. The patch is already in the works and somewhat functional, but I could use some help in the following special cases: - The carrier is the bigger problem, I don't know how to make the stuck point follow the carrier movement. Can I get the carrier position and orientation from the ground cache? - The brake needs to be improved as well. Should I consider that the brake never locks the wheel? In the current patch, the wheel locks when the brake is bigger than the static friction (both are in 0-1 range, right?) what is a crude simplification. This would make necessary some change to the brake when its bound to a button or braking will get very challenging :) - Are the fields _ground_loadCapacity and _ground_loadResistance of the Gear class relevant to the gear friction? How should I interpret them? Regards, Diogo. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] optimized generic_pylons and .osg models
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Melchior FRANZ wrote: * Tim Moore -- Saturday 13 October 2007: I've added a feature to SimGear that substitutes a model with a .osg extension for other models (not .xml) when it exists. This seems to be a bit controversial [...] That's quite an understatement. You asked on IRC about that and got *only* objections. You were the only one who liked the idea, IIRC. I find it quite disturbing that you ignore the opinions that you *asked* for, and do it anyway. If I had received only objections, I wouldn't have checked it in. My characterization of the discussion, including discussion today, is fair. This is IMHO an important performance enhancement that I feel is important to get out there. Like I said, I'm willing to change the mechanics of it. I'd prefer that explicitly stated paths are respected and are not replaced behind the scenes. Now, if an XML file only demanded a pathfoo/path without extension, then it would be ok to first try foo.osg and then foo.ac. But we told you yesterday ... m. My objective is to be able to override model file paths that seem to be hard to change, like those in the scenery files. Perhaps it's easier than I think to update those? How often is the scenery rebuilt? Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHEBP4eDhWHdXrDRURAprgAKCtYvP29spAVneBaPJFtDz5l3HnlwCeOluZ O44uOf8O5s1Ho6HC3/NRbkg= =MR36 -END PGP SIGNATURE- - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Flightgear Promotion Video - Oleg's Adventures
Anyone that want's to help promote Oleg's (flightgear) adventures here is some code you can use on your websites http://www.book-stores.com/olegs-adventures.txt It is a standard YouTube video window square with blue border. YouTube is flagging a bit make's me wonder if I should even bother sometimes :( Aerotro Online FlightGear Simulator Tracker Page. http://mpserver04.flightgear.org http://www.flightgear.org- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
