Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Vassilii Khachaturov wrote: I wonder if the openal library, when being paused by simgear as a consequence of the sound mute request, can somehow be made to close the sound device? (I.e., is it possible to have simgear init openal in a different way for this to happen, or does it need a change in openal?) In theory this might be possible, but what would we gain by this? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Further Solaris incompatibilities
Andy Ross wrote: But the simplest solution is to use the standard fmod() (which returns a double) instead of fmodf() (which returns a float) by casting the result to a float. I'm currently experimenting with a change like this and so far I don't experience any drawbacks: --- shadanim.cxx.original 2005-10-08 13:52:48.0 +0200 +++ shadanim.cxx2005-10-13 10:37:34.0 +0200 @@ -175,7 +175,7 @@ // noise texture, tex coord from the model translated by a time factor glActiveTexturePtr( GL_TEXTURE0_ARB ); glEnable(GL_TEXTURE_2D); -const float noiseDist = fmodf(- totalTime * my_shader-_factor * my_shader-_speed, 4.0f); +const double noiseDist = fmod(- totalTime * my_shader-_factor * my_shader-_speed, 4.0f); glMatrixMode(GL_TEXTURE); glLoadIdentity(); glTranslatef( noiseDist, 0.0f, 0.0f ); Could this be an approach that people would call tolerable (as I'm no C++ programmer at all) ? Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Further Solaris incompatibilities
Martin Spott wrote: --- shadanim.cxx.original 2005-10-08 13:52:48.0 +0200 +++ shadanim.cxx 2005-10-13 10:37:34.0 +0200 Well, for better understanding please replace shadanim.cxx by SimGear/simgear/scene/model/shadanim.cxx, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] mice.xml: fix the view recentering
If one does current view translation (dragging with the middle button in the 2nd (view adjustment) mode), then, upon the left click, only the pitch offsets are recentered, and not the x/y/z offsets. The patch below fixes that. Please apply... Index: ../data/mice.xml === RCS file: /var/cvs/FlightGear-0.9/data/mice.xml,v retrieving revision 1.17 diff -u -p -r1.17 mice.xml --- ../data/mice.xml28 Jan 2005 15:17:30 - 1.17 +++ ../data/mice.xml13 Oct 2005 10:46:28 - @@ -174,7 +174,22 @@ current mode for each mouse is held in t binding commandproperty-assign/command property/sim/current-view/goal-pitch-offset-deg/property - property/sim/current-view/config/pitch-offset-deg/property + property/sim/view/config/pitch-offset-deg/property +/binding +binding + commandproperty-assign/command + property/sim/current-view/x-offset-m/property + property/sim/view/config/x-offset-m/property +/binding +binding + commandproperty-assign/command + property/sim/current-view/y-offset-m/property + property/sim/view/config/y-offset-m/property +/binding +binding + commandproperty-assign/command + property/sim/current-view/z-offset-m/property + property/sim/view/config/z-offset-m/property /binding /button ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] mice.xml: fix the view recentering
* Vassilii Khachaturov -- Thursday 13 October 2005 12:49: If one does current view translation (dragging with the middle button in the 2nd (view adjustment) mode), then, upon the left click, only the pitch offsets are recentered, and not the x/y/z offsets. The patch below fixes that. Please apply... I'd rather not apply that. This middle mouse button feature is useful for adjusting the view (seat up/down), and for changing over to the copilot seat (b29!). View centering shouldn't abruptly move me back from the copilot seat or change the seat position. After all I adjusted that explicitly. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [BUG] key descr vs actual mapping disagree in Hunter
In the CVS hunter-set.xml, for some reason, the seat adjustment has been changed from l/L/CTRL-L to u/U/CTRL-U. Nevertheless, in the help section, it remains the old way. First of all, is there a reason to move it from L to U? If no, I think it would be great to have it back at L. Second, why the data duplication? can't the HELP section map to the keyboard mapping entries via the ID/IDREF mechanism in XML instead? this way the present bug would not have occured. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [PATCH] mice.xml: fix the view recentering
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Melchior FRANZ Sent: 13 October 2005 12:02 To: FlightGear developers discussions Subject: [Flightgear-devel] Re: [PATCH] mice.xml: fix the view recentering * Vassilii Khachaturov -- Thursday 13 October 2005 12:49: If one does current view translation (dragging with the middle button in the 2nd (view adjustment) mode), then, upon the left click, only the pitch offsets are recentered, and not the x/y/z offsets. The patch below fixes that. Please apply... I'd rather not apply that. This middle mouse button feature is useful for adjusting the view (seat up/down), and for changing over to the copilot seat (b29!). View centering shouldn't abruptly move me back from the copilot seat or change the seat position. After all I adjusted that explicitly. m. Can the patch be modified so that clicking the middle and left buttons simultaneously recentres the offset? Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] key descr vs actual mapping disagree in Hunter
* Vassilii Khachaturov -- Thursday 13 October 2005 13:09: is there a reason to move it from L to U? If no, I think it would be great to have it back at L. Yes, there is. Shift-L is currently reserved for carrier operations (Launch-bar engage, see $FG_ROOT/Input/Keyboard/carrier-bindings.xml). Second, why the data duplication? can't the HELP section map to the keyboard mapping entries via the ID/IDREF mechanism in XML instead? Then we would have extra entries for g ... gear up and G ... gear down instead of just g/G ... gear up/down. That's much too verbose and difficult to find. Combining these automatically isn't easy for letters, and really hard for cases like ,/. ... brake left/right. You'd have to add a lot of extra information to the key entries, which would make the whole idea error prone again. And then, you don't want all key definitions used automatically. Some aircraft redefine the flaps keys '[' and ']' to call their own nasal functions. But the meaning remains the same, as listed in the common aircraft keys already. The redefinition doesn't necessarily make these keys 'aircraft specific'. We have much more control with the current solution. And mistakes can happen in either case. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
I wonder if the openal library, when being paused by simgear as a consequence of the sound mute request, can somehow be made to close the sound device? (I.e., is it possible to have simgear init openal in a different way for this to happen, or does it need a change in openal?) In theory this might be possible, but what would we gain by this? People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] mice.xml: fix the view recentering
I'd rather not apply that. This middle mouse button feature is useful for adjusting the view (seat up/down), and for changing over to the copilot seat (b29!). View centering shouldn't abruptly move me back from the copilot seat or change the seat position. After all I adjusted that explicitly. It depends on what one uses the mid-button for. I do it for preflight walkaround, for example. For the co-pilot seat, if that's a permanent thing one needs in a particular aircraft for a required crew station, why not define a permanent view (see Concorde for example). If a lot of people, however, tend to use it like you and not like me, we should make it shift-left-button in the view adjustment mode to have the view origin reset. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [PATCH] mice.xml: fix the view recentering
Can the patch be modified so that clicking the middle and left buttons simultaneously recentres the offset? that's even more logical than my shift proposal. I'll whip it up now. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[PATCH] Re: [Flightgear-devel] [BUG] key descr vs actual mapping disagree in Hunter
Agreed on both counts. In that case, here's a patch to fix the obsolete help text entry: Index: ../data/Aircraft/Hunter/hunter-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Hunter/hunter-set.xml,v retrieving revision 1.10 diff -u -p -r1.10 hunter-set.xml --- ../data/Aircraft/Hunter/hunter-set.xml 19 Apr 2005 13:49:48 - 1.10 +++ ../data/Aircraft/Hunter/hunter-set.xml 13 Oct 2005 13:24:16 - @@ -70,11 +70,11 @@ raise/lower, emergency flap lowering, an desccanopy open/close/desc /key key -namel/L/name +nameu/U/name descseat down/up/desc /key key -nameCtrl-L/name +nameCtrl-U/name descseat default/desc /key key ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] mice.xml: fix the view recentering
On Thursday 13 October 2005 12:12, Richard Bytheway wrote: Can the patch be modified so that clicking the middle and left buttons simultaneously recentres the offset? Might make things a bit tricky for those of us whose middle button is actually a mini-joystick or other non-clickable scrolling device (or simply have a two-button mouse) and therefore must emulate the middle click with the other two buttons... I must admit I don't use the view offset adjustment myself, only the direction mode... AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [PATCH] Re: [Flightgear-devel] [BUG] key descr vs actual mapping disagree in Hunter
Vassilii Khachaturov wrote: Agreed on both counts. In that case, here's a patch to fix the obsolete help text entry: Ir's committed. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] mice.xml: fix the view recentering
As promised, a new version that jumps back only when the mid-button is pressed on the left-click. Index: ../data/mice.xml === RCS file: /var/cvs/FlightGear-0.9/data/mice.xml,v retrieving revision 1.17 diff -u -p -r1.17 mice.xml --- ../data/mice.xml28 Jan 2005 15:17:30 - 1.17 +++ ../data/mice.xml13 Oct 2005 13:37:43 - @@ -174,7 +174,31 @@ current mode for each mouse is held in t binding commandproperty-assign/command property/sim/current-view/goal-pitch-offset-deg/property - property/sim/current-view/config/pitch-offset-deg/property + property/sim/view/config/pitch-offset-deg/property +/binding +binding + condition +property/devices/status/mice/mouse[0]/button[1]/property + /condition + commandproperty-assign/command + property/sim/current-view/x-offset-m/property + property/sim/view/config/x-offset-m/property +/binding +binding + condition +property/devices/status/mice/mouse[0]/button[1]/property + /condition + commandproperty-assign/command + property/sim/current-view/y-offset-m/property + property/sim/view/config/y-offset-m/property +/binding +binding + condition +property/devices/status/mice/mouse[0]/button[1]/property + /condition + commandproperty-assign/command + property/sim/current-view/z-offset-m/property + property/sim/view/config/z-offset-m/property /binding /button ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] mice.xml: fix the view recentering
Vassilii Khachaturov wrote: If a lot of people, however, tend to use it like you and not like me, we should make it shift-left-button in the view adjustment mode to have the view origin reset. After you've finished your discussion, could one of the involved people post a short summary of the result ? Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Am Thursday 13 October 2005 15:29 schrieb Erik Hofman: Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Vassilii Khachaturov wrote: Sure. Here comes a new version, with an explicit further reading. Thanks Vassilii, I've committed it to CVS. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Oliver Schroeder wrote: Am Thursday 13 October 2005 15:29 schrieb Erik Hofman: Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. I know it's a minor inconvenience if you are on a long flightgear flight and would like to fire up your mp3 player in the background (and find that you can't) but this is going to be a problem for any application that uses sound and I don't really like the idea of overly complicating the flightgear audio code just for this. This isn't a problem on most newer audio hardware which happily knows how to share/mix between multiple audio applications. Personally I think that this problem is outside of the scope of FlightGear and we shouldn't worry about it. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
On Thursday 13 October 2005 14:42, Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. Not as far as I'm aware - with ALSA, one should use /dev/adsp which is nonblocking IIRC, but of course ALSA is only on Linux. No idea what the options are for a cross-platform solution.. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. I think something like this is badly needed - trying to fly with any degree of coordination with other people is practically impossible using any system which involves typing. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Oliver Schroeder wrote: Am Thursday 13 October 2005 15:29 schrieb Erik Hofman: Vassilii Khachaturov wrote: People like me with a lousy single-dsp on-board sound chips would be able to pause the simulation sound while debugging some flight things, and releasing the sound for other uses. So, you're really more interested in getting real sound disabling code rather than sound muting as it is now. Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. It looks like that isn't such a wise idea: http://opensource.creative.com/pipermail/openal-devel/2004-June/000346.html Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. esd or artsd would allow you to share the device. I suspect you'd need to start the sound daemon, then your comms s/w (which would need to use the device read/write), then flightgear (write only). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
This isn't a problem on most newer audio hardware which happily knows how to share/mix between multiple audio applications. Personally I think that this problem is outside of the scope of FlightGear and we shouldn't worry about it. Curt. Fair enough. I was just hoping for a simple openal-level solution known --- I agree it's not worth deep complications. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] mice.xml: fix the view recentering
Can the patch be modified so that clicking the middle and left buttons simultaneously recentres the offset? Might make things a bit tricky for those of us whose middle button is actually a mini-joystick or other non-clickable scrolling device (or simply have a two-button mouse) and therefore must emulate the middle click with the other two buttons... I must admit I don't use the view offset adjustment myself, only the direction mode... If anybody wants, I can add an OR clause into the condition, allowing for either the middle button or the SHIFT key pressed when the view is being recentered, to enable the view origin re-translation. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
AJ MacLeod wrote: On Thursday 13 October 2005 14:42, Oliver Schroeder wrote: I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. I think something like this is badly needed - trying to fly with any degree of coordination with other people is practically impossible using any system which involves typing. I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. This would allow for one conference channel per 'frequency' in use. On the other end this would require someone to wire a useful VoIP client library into FlightGear - like IAXClient, which is my favourite: http://iaxclient.sourceforge.net/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. This would allow for one conference channel per 'frequency' in use. On the other end this would require someone to wire a useful VoIP client library into FlightGear - like IAXClient, which is my favourite: http://iaxclient.sourceforge.net/ This could be setup as a completely separate application. If FlightGear was running with the telnet interface enabled, the remote audio communication application could easily fetch the currently tuned com frequencies from FlightGear. A separate application would keep the core of Flightgear simpler and wouldn't add additional prerequisites to building/installing FG. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Am Thursday 13 October 2005 16:03 schrieb Curtis L. Olson: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. I hope we don't need to change anything code-wise I know it's a minor inconvenience if you are on a long flightgear flight and would like to fire up your mp3 player in the background (and find that you can't) but this is going to be a problem for any application that uses sound and I don't really like the idea of overly complicating the flightgear audio code just for this. Actually I was thinking about VoiP applications which can be used as real comms. I'm not familiar with multimeadia things and thought /dev/dsp is used directly without any wrapper which then blocks other applications. However, I will try to use some sound daemons. But does it work on all supported plattforms? regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Hi, Jon Stockill schrieb: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? I want to start a second application which uses /dev/dsp while flightgear is running. I was investigating several applications which can serve as a radio for multiplayermode and noticed that it is not possible. esd or artsd would allow you to share the device. I suspect you'd need to start the sound daemon, then your comms s/w (which would need to use the device read/write), then flightgear (write only). I'm starting FlightGear on Linux as esddsp fgfs which essentially detours access from /dev/dsp to the sound daemon. There is a delay in audio of about 1/2s (try the flaps), but otherwise it's fine. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] a new doc file to document the realtime wx update
I suggest to name it data/Docs/README.Real-WX Real-world Weather Update = Launch fgfs with the following two command-line switches in addition to whatever else you put there: $ fgfs --prop:/environment/params/real-world-weather-fetch=true --prop:/environment/params/control-fdm-atmosphere=true (Unfortunately, if you try to turn these properties on after the program has started, it doesn't work.) Alternatively, you can add the two switches to your $HOME/.fgfsrc, or change the corresponding properties in $FG_ROOT/preferences.xml This will allow you to enjoy real-world weather as reported on the NOAA site, currently at http://weather.noaa.gov/weather/metar.shtml You can also use the metar(1) program, coming with flightgear, to query the NOAA site from the command line in text format. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Am Thursday 13 October 2005 16:33 schrieb Martin Spott: I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. This would allow for one conference channel per 'frequency' in use. On the other end this would require someone to wire a useful VoIP client library into FlightGear - like IAXClient, which is my favourite: which would be a good start. So we have voice ready to use now, even if we currently have to set up frequencies (channels) manually. I was planning (and therefor testing) to use a point-to-point VoiP client, sending data to fg_server, which knows about a players position and can know players frequencies, so it can send VoiP-data to all clients in reach. But, as said, this needs more thoughts and testing. Meanwhile I think, that your approach is more suitable (and usable!) now. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: FlightGear 0.9.9
Sorry if it's been known mentioned already --- among the 0.9.9 features I think it's would be great to get back the high-res IFR version of a c172 aircraft (c172-610x-null). (BTW, is it not there in the CVS version because of the new electrical c172 system approach?) Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] a new doc file to document the realtime wx update
Hi, Vassilii Khachaturov schrieb: I suggest to name it data/Docs/README.Real-WX Real-world Weather Update = Launch fgfs with the following two command-line switches in addition to whatever else you put there: $ fgfs --prop:/environment/params/real-world-weather-fetch=true --prop:/environment/params/control-fdm-atmosphere=true Why not --enable-real-weather-fetch? Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: Martin Spott wrote: I herewith repeat my offer to run a server that replicates audio channels using Voice-over-IP protocols using Asterisk with a conference setup. [...] This could be setup as a completely separate application. Oh, no - please ! :-)) [...] If FlightGear was running with the telnet interface enabled, the remote audio communication application could easily fetch the currently tuned com frequencies from FlightGear. It's not just about comm _frequencies_, it's not only about automated ATC messages. I'm talking about the ability to transport sim pilot's blather over the net. I heavily object against running this as a separate application after I've seen M$FS pilots running into heavy trouble while connecting multiple add-on applications to their sim. Over the time we'll run into version imcompatibilities and sort of that stuff. This is why I'd prefer to have such an interface built into FlightGear. IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: Oh, no - please ! :-)) It's not just about comm _frequencies_, it's not only about automated ATC messages. I'm talking about the ability to transport sim pilot's blather over the net. I heavily object against running this as a separate application after I've seen M$FS pilots running into heavy trouble while connecting multiple add-on applications to their sim. Over the time we'll run into version imcompatibilities and sort of that stuff. This is why I'd prefer to have such an interface built into FlightGear. IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) The counter argument though is: 1. I'm adverse to adding another somewhat large dependency to FlightGear. 2. FlightGear and MSFS have entirely different interfacing mechanisms. People may have trouble with FlightGear, but I don't think that you can say that trouble with MSFS's external interface mechanism implies similar trouble with FlightGear's ... different trouble, maybe, but not similar trouble. 3. Using the property system minimizes version incompatibility problems since property names don't change all that often. Perhaps I could propose that we start by developing this as a separate application and then if it works really well and there is a strong consensus, we could merge it in with the FlightGear code directly. It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Only 4.5 Mb ... in terms of source code, I don't think I would could call that small. I don't know what this would come out as when it's compressed, but it could easily double the size of the FlightGear source tarball. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient IAX is also NAT friendly (it runs a single udp port at each end, unlike SIP for example). -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Oliver Schroeder wrote: Meanwhile I think, that your approach is more suitable (and usable!) now. I would not spent effort into that if I weren't convinced that this approach is very much foresighted. Is there a better solution than using standard OpenSource tools and protocols for such a job !? ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: Perhaps I could propose that we start by developing this as a separate application and then if it works really well and there is a strong consensus, we could merge it in with the FlightGear code directly. Hey, as in most cases your ideas are not that bad ;-)) quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Only 4.5 Mb ... in terms of source code, I don't think I would could call that small. We are intersted only in the lib/ directory, and only in parts of it. For example all sorts of conversion routines could be dropped and the focus set to one or two codecs only. Additionally everything that has to do with video stuff would be dropped and the Microsoft Developer Studio Project files don't count either :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Just my $0.02 John W. Curtis L. Olson wrote: Martin Spott wrote: Oh, no - please ! :-)) It's not just about comm _frequencies_, it's not only about automated ATC messages. I'm talking about the ability to transport sim pilot's blather over the net. I heavily object against running this as a separate application after I've seen M$FS pilots running into heavy trouble while connecting multiple add-on applications to their sim. Over the time we'll run into version imcompatibilities and sort of that stuff. This is why I'd prefer to have such an interface built into FlightGear. IAXClient focuses on portability and I've already managed to build it on AIX, IRIX, Solaris8, FreeBSD and Linux - with neglectible programming skills ;-) The counter argument though is: 1. I'm adverse to adding another somewhat large dependency to FlightGear. 2. FlightGear and MSFS have entirely different interfacing mechanisms. People may have trouble with FlightGear, but I don't think that you can say that trouble with MSFS's external interface mechanism implies similar trouble with FlightGear's ... different trouble, maybe, but not similar trouble. 3. Using the property system minimizes version incompatibility problems since property names don't change all that often. Perhaps I could propose that we start by developing this as a separate application and then if it works really well and there is a strong consensus, we could merge it in with the FlightGear code directly. It's very small and think it is worth being incorporated into FlightGear: quickstep: 18:00:28 ~/CVS/Asterisk/iaxclient du -ks * 28 COPYING.LIB 16 CVS 12 README 3180lib 1548simpleclient Only 4.5 Mb ... in terms of source code, I don't think I would could call that small. I don't know what this would come out as when it's compressed, but it could easily double the size of the FlightGear source tarball. Regards, Curt. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
John Wojnaroski wrote: Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Here's my take on that. I would think that people would voluntarily setup ATC voip servers on their own hardware. At the moment I don't think there would be resources to setup a dedicated FG ATC voip server, but if we get a system that works well and it made sense to centralize it, we could discuss that. So in terms of people setting up servers, I would suspect that some servers would be managed more professionally than others. If a particluar server degenerates into a voip 'chat' room and the server maintainer doesn't care, then so be it. But I would assume that at least a few voip servers would be held to pretty rigorous standards and people abusing the airwaves or not taking the 'game' seriously could be booted off and sent to a less serious server. I think this could be controlled pretty well with social/cultural pressure, especially if there was some ultimate enforcement mechanism (which might be as simple as adding an entry to a /etc/hosts.deny file on the server if someone persists in breaking the rules ...) or perhaps we need a virtual airforce with guns and missles to keep the airwaves pristine ... :-) Back to serioiusness, I think since most FlightGear participants are not active licensed pilots, there would be some need for flexibility and education on the proper procedures ... just like in real life, but obviously without real lives directly at stake so we can afford to allow more mistakes and more active learning. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
On Thursday 13 October 2005 18:11, Curtis L. Olson wrote: Back to serioiusness, I think since most FlightGear participants are not active licensed pilots, there would be some need for flexibility and education on the proper procedures ... just like in real life, but obviously without real lives directly at stake so we can afford to allow more mistakes and more active learning. Phew, a sense of proportion, and much more coherent than my intended reply :-) Like you say, most FG users are not pilots IRL, and speaking personally, the new MP capability has increased my knowledge and understanding of basic airfield operations in a way that just reading a book could not. I currently know practically _nothing_ about ATC procedures, but if the facility was in place in conjunction with the MP servers, I (and plenty others) would obviously have the chance to learn and practice the basics... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: John Wojnaroski wrote: Having a voice capability for flightgear is a good idea, however irrespective of the actual mechanisms to implement the technology, we should consider the intent and purpose To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. I don't think FG needs to be in the business of building another VoIP phone system. Here's my take on that. I would think that people would voluntarily setup ATC voip servers on their own hardware. At the moment I don't think there would be resources to setup a dedicated FG ATC voip server, but if we get a system that works well and it made sense to centralize it, we could discuss that. So in terms of people setting up servers, I would suspect that some servers would be managed more professionally than others. If a particluar server degenerates into a voip 'chat' room and the server maintainer doesn't care, then so be it. But I would assume that at least a few voip servers would be held to pretty rigorous standards and people abusing the airwaves or not taking the 'game' seriously could be booted off and sent to a less serious server. I think this could be controlled pretty well with social/cultural pressure, especially if there was some ultimate enforcement mechanism (which might be as simple as adding an entry to a /etc/hosts.deny file on the server if someone persists in breaking the rules ...) or perhaps we need a virtual airforce with guns and missles to keep the airwaves pristine ... :-) Back to serioiusness, I think since most FlightGear participants are not active licensed pilots, there would be some need for flexibility and education on the proper procedures ... just like in real life, but obviously without real lives directly at stake so we can afford to allow more mistakes and more active learning. You' re reading my mind :-). It would be a great tool for training and teaching. Some of the MS ATC systems have a mentoring and training program for newbies and I suppose some sort of certification before one is allowed to go live. Again, a lot of work and dedication required Seems the only reason to include such a capability inside FlightGear would be for a centralized controller and a desire to operate in compliance with the appropriate rules. Otherwise let folks set up servers on their own, set the rules for participation, and press go and no need to engage FG. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. I think we should focus on text-based ATC first. With text, it would be much more easier to create an automatic ATC. We can always expand it to include some sort of speech-to-text engine later on. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] a new doc file to document the realtime wx update
$ fgfs --prop:/environment/params/real-world-weather-fetch=true --prop:/environment/params/control-fdm-atmosphere=true Why not --enable-real-weather-fetch? Because I didn't know about the shorthand option :-) BTW, the second property is not affected by this switch still; is that because I am mistaken here as well and it is not needed for the real wx fetch? I don't actually know what it is doing precisely, just guessing by its name... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways information
On October 11, 2005 09:42 am, Vassilii Khachaturov wrote: 1) by some kind of image processing following the Ghostview output. Of course, since the internal graphics is vector, it might be possible to infer more from various rendered resolutions. 2) Other approach would be to reverse engineer the original PS, if any, from the PDF --- I'm afraid it's not very gratifying... Why would there be needs of reverse engineering? The purpose of reading the PDF file is only to extract the taxiways' outline. 3) Yet another approach would be to ask the FAA for the data source feed --- after all, this is U.S. government work that is in public domain. And, of course, this is only a US-related solution... I have seen airport diagrams in PDF format for airports in countries other than the US. For example: http://www.sia.aviation-civile.gouv.fr/aip/enligne/metropole/aip/VAC/T/VAC AD 2.LFBO.pdf Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] a new doc file to document the realtime wx update
Hi, Vassilii Khachaturov schrieb: $ fgfs --prop:/environment/params/real-world-weather-fetch=true --prop:/environment/params/control-fdm-atmosphere=true Why not --enable-real-weather-fetch? Because I didn't know about the shorthand option :-) :-) BTW, the second property is not affected by this switch still; Hm, this is interesting. As far as I see the switch controls whether temperature, pressure and air density are passed on to the FDM - which _I_ didn't know about. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Wed, 12 Oct 2005 02:27:08 +0200 (IST), Vassilii wrote in message [EMAIL PROTECTED]: + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 ..this works ok with X in lan's? (X uses port 6000 too.) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. The primary purpose of ATC is *separation* of planes. Not navigation assistance, not terrain avoidance, not weather advisories. These are secondary functions. Until we have collision detection between planes, the *need* for ATC is nil --- the planes fly through each other w/o creating a collision hazard :-) With the current pigeon's map in place, even I could play tower and approach occasionally and juggle up to 4 *VFR* planes :-) separation-wise. Incorporating SID/STAR/IAP knowledge would be much more difficult task, but VATSIM et al show that once the framework is in place, a lot of people step forward to help, and there are ways to peer- certify people capable of doing it, as well as tutoring newcomers. There is one caveat: the VATSIM services are not completely free in the FSF sense --- one has to accept some license that allows them to terminate services and has them get one's agreement not to abuse. I wouldn't mind accepting such, but I don;t know if it's OK with the GNU spirit of the Flightgear project. IMO, as long as the software is free, it's fine, but actually logging on to some such network that the FG project endorses could be guarded by smth like the VATSIM approach. I think we should focus on text-based ATC first. With text, it would be much more easier to create an automatic ATC. We can always expand it to include some sort of speech-to-text engine later on. You meant text-to-speech, didn't you? If you are talking about automatic tower/plane comms, then fine. Otherwise, it's pretty useless during actual flying low and slow (i.e. around the airport) since it would require alternating typing with flying. Unless we can include some sort of speech-to-text capabilities :-) V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways
Ampere K. Hardraade wrote: I have seen airport diagrams in PDF format for airports in countries other than the US. For example: http://www.sia.aviation-civile.gouv.fr/[...] This is correct, the French approach is very progressive, as is the Danish (http://www.slv.dk/Dokumenter/dscgi/ds.py/View/Collection-618), but we have to face the fact that most countries don't offer this service. Anyway nobody prevents you to convert these charts and load the resulting bitmaps into TaxiDraw as a background image. It is no problem at all to convert a PDF into any other vector format but I've found it very difficult to define charcteristics that automagically can tell between runways, taxiways and other objects that happen to be part of the chart. You always have to spend significant manual effort to separate the data we need. On the other hand it might be worthwhile to spend this effort once we have a means to reliably convert airport layouts back and forth between vector layout and X-Plane format. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
+ +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 I'm confused. The CVS had my patch accepted, I updated from the CVS, and I see no occurence of the number 6000 in README.multiplayer now. ..this works ok with X in lan's? (X uses port 6000 too.) Apparently not. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS version/terrasync DB problem with UG25, LL62: crash(bo105)/strange(ufo)
BTW, what is the official FG way to report a bug for later consideration? Was my email subj good enough to make sure it becomes a moderate eyesore on someone's todo list, or will it roll into oblivion as the web archive goes on into the next month? I have seen a seemingly dead bug (judging by the last changes dates) tracker at http://sourceforge.net/tracker/?group_id=583 and found no specific instructions on bug reporting at the official site http://www.flightgear.org/ Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Curtis L. Olson wrote: So in terms of people setting up servers, I would suspect that some servers would be managed more professionally than others. If a particluar server degenerates into a voip 'chat' room and the server maintainer doesn't care, then so be it. But I would assume that at least a few voip servers would be held to pretty rigorous standards and people abusing the airwaves or not taking the 'game' seriously could be booted off and sent to a less serious server. John Wojnaroski wrote: To set up an ATC system requires a lot of work and a cadre of dedicated individuals. In the absence of such a system or standards to adhere to proper ATC phraseology and protocols, it will degenerate into a chat room. If people want to blather it might be best to use some other method or separate medium. Well, I'm holding a so called General Flight Radiotelephone Operator's Certificate, which - at least in theory - entitles you to operate the radio from the co-pilot's seat in an airliner. You might expect that I know what I'm talking about when I call this blather :-) I realize very well that we are at risk to see 'misuse' on such a voice channel and I'd suggest to open such a channel to registered users only - as other ATC simulation networks do as well. This doesn't prevent us from offering an 'open' channel, similar to common air-to-air frequencies, as an addition to other 'frequencies' where we expect people to comply with the usual phraseology. My long-term goal would be to erect a network of voice-communication servers among several people around the world. I know that we don't necessarily need voice communication just to transmit some ATC instructions into sim cockpits but on the other hand I think that without such a feature we'll never attract a single person willing to provide 'life' ATC service to FlightGear users. I not only consider this to be a thrilling idea, I happen to see in real life that there are _lots_ of people on the world to run such networks - it's just that they use the 'wrong' sim with proprietary protocols ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Ampere K. Hardraade wrote: Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. The other way 'round nobody would think of playing ATC for FlightGear users as long as the software simply lacks the required features. I know, this could lead into an endless discussion but I think you at least have to admit that there's more than a single valid view on the topic. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Martin Spott wrote: Ampere K. Hardraade wrote: Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. The other way 'round nobody would think of playing ATC for FlightGear users as long as the software simply lacks the required features. I know, this could lead into an endless discussion but I think you at least have to admit that there's more than a single valid view on the topic. There's no harm in someone working on this, especially if it's done as an external app initially. We all have our individual priorities ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
Vassilii Khachaturov wrote: There is one caveat: the VATSIM services are not completely free in the FSF sense --- one has to accept some license that allows them to terminate services and has them get one's agreement not to abuse. [...] Well, obviously the network is attractive enough for users to let people agree to these rules. Personally I would not object to setting up such rules: If people want to have a private communication channel, then, why not - everyone is allowed to set up such a voice communication service. If somebody really wishes to practice correct praseology then it's unlikely that he'll object to rules that allow him to actually _get_ that practice. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways
Martin Spott wrote: ... It is no problem at all to convert a PDF into any other vector format but I've found it very difficult to define charcteristics that automagically can tell between runways, taxiways and other objects that happen to be part of the chart. You always have to spend significant manual effort to separate the data we need. On the other hand it might be worthwhile to spend this effort once we have a means to reliably convert airport layouts back and forth between vector layout and X-Plane format. Cheers, Martin. Except that the X-Plane format is just a bad hack todays and has reach its limitation. This file format does not handle taxiways or curves, or ground traffic or docking systems or usual airport buildings. It's just a soup of rectangles (except of course the runways and frequency informations). Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause
On Thursday 13 October 2005 01:13 pm, Ampere K. Hardraade wrote: Is it a priority to have a voice comm at the moment? A voice comm would serve no purpose if there is no one being the ATC. I think we should focus on text-based ATC first. With text, it would be much more easier to create an automatic ATC. We can always expand it to include some sort of speech-to-text engine later on. This sounds good to me. Voice-ATC in the real world is a dying technology anyway. In a few years it will be gone and replaced by data-link, at least for commercial flying. I do think, however, that plane-2-plane comm at the multiplayer arena is a good idea. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Pigeon's map improvements suggestion
I'm amazed at the map as it is already, and it has replaced Atlas for me almost completely (mostly because Atlas is too heavy on my humble 32Mb gfx card when fg is also running). However, since suggestions are solicited, here they are: 1) It would be great to have the vertical trend showing up on the label (rounded off to the nearest 100fps, with a + or - and/or color coding it depending on the sign). 2) the frame (menu bar of the browser, the right nav pane, and the lower controls) eat a lot of screen when fg is running on it, too. Could you please add a mode where it reduces itself to a web pop-up, with just the picture? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A question regarding accurate taxiways
Harald JOHNSEN wrote: Except that the X-Plane format is just a bad hack todays and has reach its limitation. [...] I know the file format very well as I've done lots of manual changes with my favourite text editor - but what are you aiming at ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Thu, 13 Oct 2005 22:36:43 +0200 (IST), Vassilii wrote in message [EMAIL PROTECTED]: + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 I'm confused. The CVS had my patch accepted, I updated from the CVS, and I see no occurence of the number 6000 in README.multiplayer now. ..this works ok with X in lan's? (X uses port 6000 too.) Apparently not. ..aouch. Ok, the first X session on any box will use port 6000, the next 6001 etc, similarly 5900, 5901 upwards for vnc etc. ..how about putting the server on 5500 like we have done, and commandeer 5501 upwards for all clients? (Assuming they're vacant? Excluding non-FG app ports, I suspect METAR fetches has an established procedure, with ports and all.) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] DME range
Does anyone know if the DME calculation to a VORTAC is based on slant range? Noticed when flying over a fix say at FL350, the range goes down to zero at station passage. It should be the AGLvalue of the aircraft over the station. OTH a waypoint based on radial intersections or GPS would go to zero. Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Curtis L. Olson wrote: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. [...] This isn't a problem on most newer audio hardware which happily knows how to share/mix between multiple audio applications. Hardware mixing is, of course, the best solution, but note also that OpenAL can be built with any of a zillion back ends, among them the various sounds servers (esd, arts) which do their own mixing. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DME range
Does anyone know if the DME calculation to a VORTAC is based on slant range? Noticed when flying over a fix say at FL350, the range goes down to zero at station passage. It should be the AGLvalue of the aircraft over the station. OTH a waypoint based on radial intersections or GPS would go to zero. I get slant range here. What property are you looking at? The DME in the 737 model uses the property: property/instrumentation/dme/indicated-distance-nm/property Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Wed, 2005-10-12 at 20:22 +0200, Vassilii Khachaturov wrote: Sure. Here comes a new version, with an explicit further reading. Index: ../data/Docs/README.multiplayer === RCS file: /var/cvs/FlightGear-0.9/data/Docs/README.multiplayer,v retrieving revision 1.1 diff -u -p -r1.1 README.multiplayer --- ../data/Docs/README.multiplayer 21 Aug 2004 08:57:29 - 1.1 +++ ../data/Docs/README.multiplayer 12 Oct 2005 18:19:50 - @@ -54,19 +54,72 @@ is the sort of implementation that we ar visual simulator. -For use with a server (when one is created): - +For use with a server: +-- +Oliver Schroeder has created a server for multiplayer flightgear use. +The server acts as a packet forwarding mechanism. When it +receives a packet, it sends it to all other active players. +Future versions might be more scalable, only forwarding information +on the planes in the receiving player's vicinity. Gawd, I don't belive that I am commenting on a patch. I'm fairly certain that the selective positioin forwarding based on the players' position is already in the logic of the FG server. This was fixed in 0.0.6 of FG server. Apart from that the rest looks good. George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On Thu, 2005-10-13 at 23:30 +0200, Arnt Karlsen wrote: On Thu, 13 Oct 2005 22:36:43 +0200 (IST), Vassilii wrote in message [EMAIL PROTECTED]: + +Options needed to enable multiplayer game with a server: Player1: ---multiplay=out,10,serveraddress,6000 --multiplay=in,10,myaddress,5500 I'm confused. The CVS had my patch accepted, I updated from the CVS, and I see no occurence of the number 6000 in README.multiplayer now. ..this works ok with X in lan's? (X uses port 6000 too.) Apparently not. ..aouch. Ok, the first X session on any box will use port 6000, the next 6001 etc, similarly 5900, 5901 upwards for vnc etc. ..how about putting the server on 5500 like we have done, and commandeer 5501 upwards for all clients? (Assuming they're vacant? Excluding non-FG app ports, I suspect METAR fetches has an established procedure, with ports and all.) Better would be server on 5000, with the telnet admin port on 5001. I'm not sure of the benefit of each client having it's own port. (Perhaps i have misread something) George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
