Re: [Flightgear-devel] FGCOM gets a discussion page on the wiki
Willie, On Sun, Nov 25, 2007 at 12:14:28PM +, Willie Fleming wrote: http://wiki.flightgear.org/flightgear_wiki/index.php?title=Talk:FGCOM Ive kicked this off with a request for _simplex_ comms and a wee moan about voice quality. I used squawkBox once a couple of years back - I cant honestly remeber how the Ok, but I see many things that should be solved at the same time. We should create a list og topics to be done and we should try to give them priorities and perhaps name who try to solve these topics. But where to place this list? FG-Wiki? My own Wiki? voice quality sounded. Can anyoine enlighten me? How realistic does it sound? The ATC chatter we have is pretty realistic - obviously recorded by someone with a newish scanner somewhere near Heathrow EGLL - in terms of volume quality and random spurious noises and clicks - note the variations in perceived volume of the different calling stations. These aircraft however are all commercial operations, the radios found in GA aircraft will in some cases sound a bit rougher. I see the following realism problems: 1.) absence of random white noise 2.) the voice channels should be limited with a high cut (at 4 kHz) (or an band pass between 300 Hz and 4 KHz) 3.) as in real life there should be a mechanism for realising crosstalking (e.g. the sender with the maximum of output pushes other senders in the background) 4.) real com radios have an automatic noise limiter (squelch) which makes a little noise after releasing the PTT key. 5.) pilots have engine sounds in the background Here are my ideas: 1.) A daemon in the background ca radomly place short samples of white noise and/or athmospherical noise an used channels. The problem is that crosstalking cannot be recognized from such a daemon (see 4). 2.) Perhaps an EQ in the sound chain. The best place would be iaxclient. But also ALSA would be working - but this is not real protable. 3.) That's a real problem. If this should work something like a complete new conference module for asterisk must be developed __AND___ a mechanism (schedular) for the voice clients (perhaps a simple FIFO). Not as easy as it sounds... 4.) Why not sending a simple short noise sample after muting the mic? This could be placed inside iaxclient. 5.) Again: mixing engine sound inside the mic stream... perhaps also at iaxclient? What I see: Everything is more a sound/VoIP problem rather than a FG problem... Please note -- Im used to hearing ATC chatter in the UK --probably a LOT different in the rest of Europe and the US. I don't know how the ATC chatter we have sounds to the rest of you guys both in terms of content and quality. I tried to follow some web ATC streams and I udnerstand nearly nothing - especially the pilots are very difficult to understand. :-) Regards, Holger -- # ## ## Holger Wirtz Phone : (+49 30) 884299-40 ## ## ## ### ## DFN-Verein Fax : (+49 30) 884299-70 ## ## ## Stresemannstr. 78E-Mail: [EMAIL PROTECTED] ## ## ## ## ### 10963 Berlin # ## ## ## GERMANY WWW : http://www.dfn.de GPG-Fingerprint: ABFA 1F51 DD8D 503C 85DC 0C51 E961 79E2 6685 9BCF - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM gets a discussion page on the wiki
Hello Holger! Holger Wirtz wrote: 3.) as in real life there should be a mechanism for realising crosstalking (e.g. the sender with the maximum of output pushes other senders in the background) crosstalking in real-life more often happens to create interference which punishes those listening for wearing headsets (people tell me these things are there for protecting your ears ;-) Please note -- Im used to hearing ATC chatter in the UK --probably a LOT different in the rest of Europe and the US. I don't know how the ATC chatter we have sounds to the rest of you guys both in terms of content and quality. I tried to follow some web ATC streams and I udnerstand nearly nothing - especially the pilots are very difficult to understand. :-) As a VFR pilot I'm mostly used to German and English VFR chatter and don't typically hang out on radar frequencies or the likes. The FlightGear ATC chatter is almost incomprehensible to me, mainly due to the speed... After all, VFR is typically the domain of leasure time pilots, and most of them don't generally practice their speed or even the coherence of their radio skills daily. For some of them, FGCOM might change this... ;-) Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGCOM gets a discussion page on the wiki
On Monday 26 November 2007 09:53:16 Holger Wirtz wrote: Ok, but I see many things that should be solved at the same time. We should create a list og topics to be done and we should try to give them priorities and perhaps name who try to solve these topics. But where to place this list? FG-Wiki? My own Wiki? I suggest FG-wiki with a link to your own wiki for now. I see the following realism problems: 1.) absence of random white noise 2.) the voice channels should be limited with a high cut (at 4 kHz) (or an band pass between 300 Hz and 4 KHz) 3.) as in real life there should be a mechanism for realising crosstalking (e.g. the sender with the maximum of output pushes other senders in the background) 4.) real com radios have an automatic noise limiter (squelch) which makes a little noise after releasing the PTT key. 5.) pilots have engine sounds in the background I think we need to go for _some_ more realism but not at the expense of too much extra complication which may gain us very little in the end. With headphones at both ends, Jester and I did a good test with his latest patched code. I need to get a better headset mic-- For now I only have headphones and an old omnidirectional mic -- not realistic at all. I think we will see very good results with Jesters latest patch and properly positioned mics and headsets Here are my ideas: 1.) A daemon in the background ca radomly place short samples of white noise and/or athmospherical noise an used channels. The problem is that crosstalking cannot be recognized from such a daemon (see 4). 2.) Perhaps an EQ in the sound chain. The best place would be iaxclient. But also ALSA would be working - but this is not real protable. 3.) That's a real problem. If this should work something like a complete new conference module for asterisk must be developed __AND___ a mechanism (schedular) for the voice clients (perhaps a simple FIFO). Not as easy as it sounds... Lets leave that to one side for the moment - sounds overly complex . I should be careful what I wish for... 4.) Why not sending a simple short noise sample after muting the mic? This could be placed inside iaxclient. 5.) Again: mixing engine sound inside the mic stream... perhaps also at iaxclient? What I see: Everything is more a sound/VoIP problem rather than a FG problem... Indeed Im with Jester on this - lets get good clean sound and then add a (possibly optional) realism layer on top which would include a bandpass filter, white noise and PTT clicks etc. Engine noise is more complex. To be right it would have to be different for each type. The background cockpit noise in a Pitts is not what we'd expect in the 777. My vote is to give this a low priority for now. Please note -- Im used to hearing ATC chatter in the UK --probably a LOT different in the rest of Europe and the US. I don't know how the ATC chatter we have sounds to the rest of you guys both in terms of content and quality. I tried to follow some web ATC streams and I udnerstand nearly nothing - especially the pilots are very difficult to understand. Its gibberish until you understand a little about what information is being tranferred and the idioms involved. Downwind for full stop, Golf Oscar Mike means little in isolation.. in context, Ive just told EGPK tower that Im about 1.5km to the SW of the end of runway 31 on an approx heading of 130 deg at 1000feet and I want to land and taxi back to the clubhouse, if thats OK with him... Its actually fairly easy once you know some background :-) How did you feel the first time you saw a 10 line shell script? Scared me silly.. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Durk, Okay, I'll write on this issue a bit before I leave here. This bug actually has occurred since 0.9.10. When I found this bug, I sent a similar report as Hans did, and the answer was almost exactly the same as you said. So I checked if rgb file for halo was properly loaded. Then I found that somehow it was not loaded properly on Mac OS X. I was trying to find the cause of this problem by tracing around SimGear's oursun.cxx, but I only found a workaround (changing the order of adding texture paths (i.e. the order of loading rgb files). This allows Mac OS X properly load rgb file for halo... I don't know why such thing happens yet, but it works anyway. This is why I changed the order of adding texture paths in the patch that I posted yesterday. I didn't post the patch since I was not sure if this patch affects other platforms. Maybe this is a proper timing to apply the patch only if it doesn't affect other platforms. By the way, I forgot to mention that there is another bug (also since 0.9.10) that shadows are not rendered on Mac OS X. At the time SGShadowVolume::setupShadows is called for the first time, OpenGL extentions and AlphaBits/StencilBits are not properly recognized on Macs, so SGShadowVolume::init() should be (re)invoked when setupShadows() is called for the first time. Enclosed is the patch for SimGear to solve this problem. This patch doesn't affect any other platform since it is in #ifdef __APPLE__ #endif closure. Please apply this patch if you still have time before the official 0.9.11-pre2 release. Otherwise, apply this on the next release. I can help on this again when I come back (about a week later). Hans, could you help on this instead of me while I'm away? Thanks in advance, Tat On Nov 25, 2007, at 5:37 PM, Durk Talsma wrote: On Saturday 24 November 2007 22:06, Hans Fugal wrote: On OSX, for some unknown reason the sun is displayed as a square (or diamond, if you like) instead of as a circle. Unknown to me, anyway; I think the MacFlightGear folks have a patch. Here's a screenshot: http://hans.fugal.net/tmp/fg/square-sun.png In your earlier mail, you mentioned that this problem showed up relatively recently. It seems like a particular type of texture blending isn't working anymore (The sun basically consists of two textures with radially increasing alpha values that blend into to the sky, thus creating an inner and an outer halo). If you have an idea around what time this problem occurred, could you try to revert to an older revision, and try to pin point the date when this problem occurred? Also, could it be related to a video driver? I'm not seeing this problem here, so I'm a afraid I'm not much use in trying to help debugging this problem. Cheers, Durk - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel SimGear-0.3.10-shadow-MacOSX.diff Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Default menus/dialog style
In Plib branch (including pre2) on Windows XP/Vista with an NVidia GeForce 6150 LE, I've noticed that when I use the default menus dialog boxes the sky graphics are distorted as illustrated in this screencap: http://www.rato.us/flightgear/fgpre2triangles.jpg When I switch (Shift-F10) to what I'm told is the Anthrax menu/dialog style, the problem goes away: http://www.rato.us/flightgear/fgpre2notriangles.jpg I brought this up in IRC and it was mentioned that this may be an NVidia. I followed AnMaster's recommendation that I enable NVidia's anti-aliasing and anisotropic filtering for all apps and that does seem to have solved the issue. The default settings for these was Application Controlled. While this worked for me, another suggestion was made that FG's default menu/dialog style should be changed to Anthrax. It appears to be the most liked style (by impromptu and totally unscientific poll on IRC ;) and seems less likely to make the average FlightGear newbie think there's a nasty graphics bug in the sim (for all I know, there is). Are there any strong opinions for or against this change? -Reagan THOMAS - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear prerelease
Hans,
one more report before I leave ;-)
Actually, I don't see the weather problems that you have. (I tested on
my MacBook Pro)
I chose Thunderstorm from the Weather Scenario dialog and closed it.
When I opened it again, it still says Thunderstorm. even with --
enable-real-weather-fetch option.
When I added --enable-real-weather-fetch option, the dialog says
none as you mentioned.
but when I choose METAR, then the weather changes to METER mode.
Plus, when I manually adjust the weather conditions in METER mode,
the numbers that I adjusted were still there when I open the weather
condition dialog again.
When I select METAR manually after I selected thunderstorm,
the weather is still thunderstorm even the dialog shows METAR.
In this case, I didn't add --enable-real-weather-fetch, so this
could be normal behavior.
This is what I got. Is this what you expect or not?
I also want to know the weather related behavior on other platforms.
If you don't see the same thing on your Mac, please try all the
patches that I have. these can be obtained from:
http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/branches/0.9.11/patches/
FlightGear-0.9.10-MacOSX.diff is the patch for the sun gets rendered
properly as I posted before.
SimGear-0.3.10-MacOSX.diff includes the patch that I posted on the
last email on the list.
This also contains the patch for missing OpenAL on Macs. so you can
apply the patch that I enclosed on my last post instead of this
if you already have your own version of OpenAL patch.
SimGear-0.3.10-MacOSX-Splash.diff is only for PPC Macs to avoid
getting broken splash screen so you don't probably need that.
This is due to (I guess) a bug in gzlib on PPC Macs since this bug
doesn't occur on Intel Macs.
I'm very happy If you give me any feedbacks on these patches.
I'll reply when I'm back.
Hope it helps,
Tat
On Nov 26, 2007, at 12:50 PM, Hans Fugal wrote:
Hi Tat, thanks. That's the same patch that I mentioned elsewhere in
this thread. I can test on linux tomorrow but not windows.
As for the weather, I haven't tested it explicitly in linux the last
day or so, but IIRC it is not OS X specific.
On Nov 25, 2007 7:09 PM, Tatsuhiro Nishioka [EMAIL PROTECTED]
wrote:
Hans,
Why don't you try this patch for the sun problem.
This is for 0.9.10 but should work on 0.9.11-pre2.
The cause of this problem is the order of adding texture path.
Thus I changed its order so the sun gets rendered properly.
Durk, (and more developers), could you test this patch so it can run
on linux and windows properly?
If so, please apply this patch. Otherwise, I'm gonna make a new patch
with #ifdef __APPLE__ #endif closure
not to affect other platforms.
About the weather problem, let me check it later.
I'm gonna be out for a while for a business trip so I'll check that
later.
Best,
Tat
--- org/FlightGear-0.9.10/src/Main/main.cxx 2006-03-21
10:52:29.0 -0800
+++ flightgear/FlightGear/src/Main/main.cxx 2006-11-20
16:06:35.0 -0800
@@ -787,13 +787,6 @@
// TODO: move to environment mgr
thesky = new SGSky;
-SGPath texture_path(globals-get_fg_root());
-texture_path.append(Textures);
-texture_path.append(Sky);
-for (int i = 0; i FGEnvironmentMgr::MAX_CLOUD_LAYERS; i+
+) {
-SGCloudLayer * layer = new
SGCloudLayer(texture_path.str());
-thesky-add_cloud_layer(layer);
-}
SGPath sky_tex_path( globals-get_fg_root() );
sky_tex_path.append( Textures );
@@ -812,6 +805,15 @@
globals-get_ephem()-getNumStars(),
globals-get_ephem()-getStars() );
+
+SGPath texture_path(globals-get_fg_root());
+texture_path.append(Textures);
+texture_path.append(Sky);
+for (int i = 0; i FGEnvironmentMgr::MAX_CLOUD_LAYERS; i+
+) {
+SGCloudLayer * layer = new
SGCloudLayer(texture_path.str());
+thesky-add_cloud_layer(layer);
+}
+
// Initialize MagVar model
SGMagVar *magvar = new SGMagVar();
globals-set_mag( magvar );
On Nov 25, 2007, at 6:06 AM, Hans Fugal wrote:
I verified that these two do still exist. Allow me to elaborate,
though they have been reported before.
On OSX, for some unknown reason the sun is displayed as a square (or
diamond, if you like) instead of as a circle. Unknown to me,
anyway; I
think the MacFlightGear folks have a patch. Here's a screenshot:
http://hans.fugal.net/tmp/fg/square-sun.png
The weather bug is in two pieces, actually. First, when you go into
the Weather Scenario dialog, None is always selected, regardless
of
what weather is actually being used. If one is using real weather
fetch as I am, it should say METAR.
When real weather fetch is enabled, no matter what Weather Scenario
(thunderstorm, none, fair) or what conditions or clouds I set
Re: [Flightgear-devel] Default menus/dialog style
* Thomas -- Monday 26 November 2007: While this worked for me, another suggestion was made that FG's default menu/dialog style should be changed to Anthrax. [...] Are there any strong opinions for or against this change? No. There are only two things to consider: - anthrax'[1] bitmap fonts are a bit slower to render than classic's texture fonts. But dialogs aren't usually open at flight. (Except maybe the frame rate counter dialog.) - plib 1.9.4 has several GUI bugs, which causes some widgets to be displayed wrongly, as you can see in the property browser on the left side in this wiki screenshot [46 kB]: http://wiki.flightgear.org/flightgear_wiki/images/0/01/Nasal_console.jpg The font should really be white in the listbox, not black. Another bug with 1.9.4 is that some text fields are pink, while all of them should be yellow. That's fixed in 1.9.5. So, at least distributors should link their binaries against 1.9.5pre. - some people miss the transparency. I don't. On the positive side: + anthrax is better for flights in the dark, where the bright classic dialog boxes destroy your dark adaptation + it makes the menu and dialog boxes smaller, thanks to the smaller font (and, yes, that's a good thing :-) m. [1] the name is a bit cheesy. The style was meant to refer to anthracite, but anthrax was the buzzword of that time, so ... ;-) I wouldn't mind to rename it. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scale6X
Hi, Flightgear at Scale this year will be either the OSG version or 0.9.11. We're trying to negotiate for a bit more space and power to set up three large scale screens. Curt posted a notice to the upcoming events regards the show. Joysticks? We don't need no stickin' joysticks ;-) The show this year will feature a full set of flight controls with control loading and fully trimmable axes . Pics are on the project page. Control inputs will be with high precision multi-turn pots that feed an analog signal to an A/D board that provides a 12 bit precision digital value with a sampling rate of 100kHz. Based on estimated control travel limits, pot precision, and scaling colum and yoke movements on the order of 0.02 degrees in pitch and roll can be sensed. This also required some large gearing ratios to achieve sufficient pot travel. (See pic on project page) For control loading we use Q and g to stiffen the controls in pitch, ailerons will be a fixed force. Making the system portable and keeping costs down was a real challenge. I'll be sending Curt some pics on the progress of the effort that we'll throw up on the 747 project page. As a side note, we'll have an internet connection for MP access. Unfortunately, the show hours, based on PST, are not the best for all of you located across the Atlantic. But if there are a few brave night owls or early risers, come and join us at LAX and or KSFO. Regards John - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP-Chat-Bug
Hi Stuart, Stuart Buchanan schrieb am 25.11.2007 23:14: I've uploaded a new version now which works fine for me. BTW: the URL above it wrong, should be: http://www.nanjika.co.uk/flightgear/multiplayer.nas -Stuart I have used your new version this evening and got no MP-Chat-Bug. Thank you and best regards, Maik - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Default menus/dialog style
On Mon, 26 Nov 2007 21:32:12 +0100 Melchior FRANZ [EMAIL PROTECTED] wrote: - some people miss the transparency. I don't. I dont either , and I think that's the cause of the problem anyway ;).Just my 2 cents -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] View questions
Hi , Just wondering if the view name will be eventually set in /sim/current-view ? It could be done with nasal , I know... It seems a safer way (and I do vaguely remember something like this being discussed before) than view-number , since that isn't reliable with added on views ... ie , I add a view 100 and 101 , which show up in the property tree as view 7 and 8 ... I've also noticed that if an extra view ISN'T defined , I get a strange sea-level view with two lines running toward and meeting at the horizon . Is this an error at my end ? I haven't recompiled in a week or two. Thanks, -- SydSandy [EMAIL PROTECTED] - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] View questions
* SydSandy -- Tuesday 27 November 2007: Just wondering if the view name will be eventually set in /sim/current-view ? Use /sim/current-view/name. It seems a safer way (and I do vaguely remember something like this being discussed before) than view-number , since that isn't reliable with added on views ... ie , I add a view 100 and 101 , which show up in the property tree as view 7 and 8 ... Use view.indexof(Foo View) to get the internal index. You can also set /sim/current-view/view-number=-101. That is, set the negative property index to automatically get view 8 in your example. I've also noticed that if an extra view ISN'T defined , I get a strange sea-level view with two lines running toward and meeting at the horizon . Extra view that isn't defined? Sounds esoteric. Either it's there or it isn't. But *if* it's there, then it will be used, even if it's just an empty /sim/view[123]. In that case fgfs will use default values. Just don't define not-defined views. ;-) m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
